Interface intuitiva para compor lógica booleana?

O principal problema que os usuários não técnicos têm com a lógica booleana é entender a diferença entre AND e OR porque nem sempre corresponde à linguagem natural (por exemplo, “mostre-me pedidos de Nova York e Nova York Jersey "quase certamente significa Location = NY OR Location = NJ). Geralmente, os usuários tendem a interpretar" ou "como um OR exclusivo. Depois, há o problema de perder o controle dos parênteses aninhados.

Uma solução que evita esses dois problemas é representar graficamente a lógica com uma metáfora de encanamento ou elétrica. Houve algumas linhas de trabalho adotando essa abordagem:

Shneiderman, B. (1991). Interfaces visuais de usuário para exploração de informações. Anais da 54ª Reunião Anual da Sociedade Americana de Ciências da Informação, 28, 379-384.

Murray NS, Paton NW, Goble CA, Bryce J (2000) Kaleidoquery - uma linguagem visual baseada em fluxo e sua avaliação. Journal of Visual Languages ​​& Computing, 11 (2), 151-189.

Os construtores de consultas são um dos poucos lugares em que faz sentido ter modos Básico e Avançado separados. Você provavelmente descobrirá que 90% das consultas de seus usuários se encaixam apenas em alguns padrões (por exemplo, "Clientes com nome começando com Xxxx", "Contas pelas quais sou responsável por contas pendentes", "Pedidos feitos entre as datas aeb ”). Faz sentido ter essas consultas pré-enlatadas ou semi-enlatadas que podem ser selecionadas e especificadas facilmente, colocando algo como Kaleidoquery em Avançado para as consultas ad hoc mais raras.

Este testou bem com usuários técnicos e não técnicos e pode gerar praticamente qualquer consulta de banco de dados possível ...

Os benefícios são que é muito claro e um usuário pode arrastar e soltar ( ou excluir ) qualquer expressão ou grupo de expressões na árvore.

O lado negativo é quanto espaço consome.

Existe um plugin jquery para fazer isso, chamado QueryBuilder, que faz isso de uma maneira interessante: http://mistic100.github.io/jQuery-QueryBuilder/

Gosto da maneira como as regras do Apple Mail funcionam:

Há algumas boas idéias/referências aqui, especialmente para algumas abordagens existentes. Frequentemente, embora nem sempre, a abordagem da Apple seja um bom ponto de partida - mas talvez no seu caso não seja. Tenho a impressão (embora você ainda não tenha dito isso) de que você está trabalhando com muitos dados, compostos de muitos campos/variáveis.

Concordo que tentar encontrar uma maneira de simplificá-lo para usuários menos técnicos é uma boa idéia, desde que você espere ter usuários menos técnicos usando o sistema. Caso contrário, desenvolver uma interface menos complicada pode ser muito trabalhoso para pouco ganho. Eu também gosto da idéia de um diagrama de Venn - seria interessante ver como isso acontece.

No entanto, em termos de sugestões reais de como simplificar isso, outra abordagem seria apenas criar algum tipo de processo "Assistente" que orienta o usuário no processo com uma combinação de linguagem natural e uma aparência familiar da Web. Abaixo está uma maquete de como isso poderia funcionar, usando um exemplo de banco de dados de veículos a motor:

O exemplo acima mostra como a Etapa 1 poderia funcionar, oferecendo aos usuários várias opções que podem ser marcadas marcando a caixa de seleção relevante. Eles podem marcar uma ou mais caixas de seleção conforme necessário (ou talvez nenhuma ?!). Se eles marcarem uma caixa de seleção para uma opção que requer mais informações, as palavras relevantes serão vinculadas. Clicar nas palavras com hiperlink apresentaria ao usuário algo como o exemplo abaixo:

Portanto, o exemplo acima mostra o que um usuário pode ver se selecionou a caixa de seleção "O veículo é produzido por fabricantes específicos" e clicou no texto com hiperlink para selecionar o (s) fabricante (s) que deseja incluir nos resultados da pesquisa. É claro que sua abordagem pode variar dependendo se eles devem ver um campo de texto livre, uma lista suspensa de opções etc.

Agora, para lidar com quaisquer "exceções" aos critérios de pesquisa, você basicamente recriaria a primeira janela novamente, mas com palavras diferentes, como:

Portanto, depois de selecionar a exceção de combustível acima, o usuário clica nas palavras com hiperlink "combustível específico" para escolher a exceção como abaixo:

Mais uma vez, isso pode ser uma lista suspensa, botões de opção etc., dependendo do que melhor se adequar à condição. Eles também passariam pelo mesmo processo para selecionar o país em que não queriam que o veículo fosse fabricado.

Obviamente, vejo essa abordagem de "Assistente" como sendo para usuários menos técnicos. Você também ofereceria uma opção "Avançada" para usuários confortáveis ​​com uma abordagem mais complicada que pode ser simplificada em comparação com a abordagem Wizard.

Adendo [~ # ~] [~ # ~]

Ok, isso me manteve acordado ontem à noite. Na verdade, vejo essa abordagem Wizard como um bom caminho a percorrer), então achei que valeria a pena voltar para melhorar minha resposta, pois isso pode ajudar alguém, se não você.

Atualizei as imagens de maquete acima e queria expandir sua ideia de usar uma tela dividida.

Originalmente, pensei que, após a conclusão da última etapa, algo como a ideia do diagrama de Venn pudesse ser usado para indicar visualmente o que o usuário escolheu. Mas então pensei na minha afirmação original de que também deveria haver uma maneira de o usuário ir e voltar para alterar seus critérios. Então, agora estou pensando que, usando sua tela dividida, você poderá obter os dois. Abaixo está uma nova imagem para ilustrar o que estou pensando:

Portanto, o exemplo acima é um exemplo do que pode aparecer na segunda parte da tela dividida. À medida que o usuário seleciona seus critérios, isso é atualizado para indicar quais foram suas seleções. Essa abordagem também usa a aparência familiar da Web de destacar suas opções com hiperlinks e, se eles quisessem, eles poderiam alterar seus critérios clicando nos hiperlinks nesta tela, em vez de precisar ir e voltar entre as telas para refazer suas opções. passos. Obviamente, se eles quisessem selecionar uma nova nova condição, talvez precisassem voltar à etapa relevante. Mas você entendeu.

A única outra coisa que gostaria de mencionar é que, sem conhecer a complexidade dos seus dados, talvez seja necessário refinar essa abordagem Wizard. Meu banco de dados de veículos simples precisa apenas de duas etapas, mas é complicado pode ser necessário mais etapas.O ponto dessa abordagem, porém, não é tanto o número de etapas, mas o fato de que o Wizard 'conversa' as pessoas através das etapas usando a linguagem natural como tanto quanto possível.

De qualquer forma, espero que isso, juntamente com as outras respostas fornecidas, dê a você um pouco de reflexão. E talvez alguns outros. Esse é um bom tópico e acho que será relevante para muitos usuários.

Boa sorte!

Depende do nível de sofisticação de seus usuários. Temos algo semelhante na versão atual da interface que excluiu o agrupamento e corrigiu a conjunção entre termos para OR. Cada termo pode ser negado. A maioria dos usuários aceita esse tipo de consulta e a maioria deles não seria capaz de formular consultas mais avançadas corretamente. Agora estamos implementando um processo de duas etapas no qual o resultado de uma consulta pode ser usado para limitar a população em uma consulta a seguir (ainda deixando de fora o agrupamento explícito na interface do usuário).

A interface do usuário para isso é uma lista básica de restrições que podem ser adicionadas, removidas, ativadas e desativadas e negadas. Isso foi suficiente para a maioria das consultas que os usuários desejam criar. Tínhamos um design para uma nova versão baseada em um conceito de fluxo de dados (inspirando-se fortemente no vistrails, veja abaixo), mas que nunca foi executada. Vistrails é um produto que pode ser usado para criar pipelines VTK. Se você deseja seguir o caminho de muitas partes da interface do usuário, o fluxo de dados funciona para formular consultas, mas também para formular a formatação de saída.

Procure inspiração em

• Yahoo Pipes
• Localizador de Apple
• Pesquisa Thunderbird
• Vistrails

Ao contrário de reutilizar tabelas dinâmicas como eu anteriormente respondido , esta é uma interface de usuário experimental que pensei em lidar com a necessidade repetitiva de escrever AND ou OR.

Ele se baseia em um elemento: você deve aprender que ANDs são horizontais e ORs são verticais. Ele consegue lidar com uma lógica booleana bastante complexa.

Visão geral

Suponha que A, B, C, D e E sejam expressões booleanas.

Para testar o conceito, aqui é como você desenharia os dois lados diferentes de uma equivalência booleana padrão:

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

Isso se estende a consultas mais complexas:

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

UI real

Para esta tabela de dados:

A tela é dividida em duas:

1. Um conjunto de filtros (efetivamente AND consultas)
2. Uma combinação dos filtros

Você define os filtros (estes são apenas digitados com o log condicional básico) e, em seguida, arrasta-o para 'mesclá-lo' com a consulta completa.

Depois de arrastar o novo conjunto de filtros, o lado esquerdo retorna para uma lista não filtrada e o lado direito mostra o conjunto de dados 'mesclado':

Você deve poder arrastar e editar as expressões no lado direito - mas isso exige muito mais trabalho.

O Microsoft Access tentou razoavelmente uma interface do usuário de consulta de banco de dados simples, produzindo uma versão visual de "Consulta por exemplo"

Ele possui uma linguagem mais natural que evita a necessidade de interface do usuário aninhada , às custas de entradas ocasionalmente um pouco mais redundantes nas linhas.

^{baixar fonte bmml - Wireframes criados com Balsamiq Mockups}

É uma pergunta antiga, mas pensei em contribuir caso alguém esteja interessado. Embora muitas respostas interessantes já tenham sido fornecidas, eu projetei para o nosso aplicativo o seguinte:

Inicialmente, há apenas a primeira expressão de grupo e uma regra. Clicar em 'Adicionar condição' adiciona uma nova condição acima dela, enquanto o 'Adicionar grupo' adiciona um novo grupo diretamente abaixo; grupos adicionais do grupo pai são irmãos, enquanto você pode criar aninhamento infinito usando o botão 'Adicionar grupo' de dentro de um grupo aninhado.

Em dispositivos móveis, as condições são empilhadas, juntamente com o botão de ação 'remover' - que agora altera seu texto para 'Remover condição'.

O design funciona bem, tem boa aparência, é responsivo e também não consome muito espaço.

Bônus adicionado: Acima do grupo, uma única linha mostra a condição final produzida, por exemplo

[Data maior que XXX AND (nome igual a Nick)]

edit: Para torná-lo mais acessível por pessoas não técnicas, eu seguiria o que foi dito por outras pessoas neste segmento - siga o caminho da Apple. Em vez de AND/OR, eu usaria o contexto ALL/ANY +.

Se seus usuários forem avançados o suficiente para conhecer a hierarquia de uma consulta, qualquer interface gráfica que você fornecer deverá ser fluida o suficiente para não atrapalhar. Eu acho que uma interface baseada em arrastar e soltar elementos para criar uma hierarquia implícita é ideal. Aqui está um exemplo visual anotado estendido de como um usuário pode construir a consulta (A and B) or ((not C) or D):

 Solte A no painel. 
 + --- + 
 | A | 
 + --- + 
 
 Solte "e" depois de A. 
 + --------------- ---- + 
 | + --- + + ----- + | 
 | | A e | ... | 
 | + --- + + ----- + | 
 + ------------------- + 
 
 Soltar B para "...". 
 + ----------------- + 
 | + --- + + --- + | 
 | | A e | B | 
 | + --- + + --- + | 
 + ----------------- + 
 
 Solte "ou" depois "e". 
 + -------------------------------- + 
 | + ----------------- + | 
 | | + --- + + --- + | + ----- + | 
 | | | A e | B | ou | ... | 
 | | + --- + + --- + | + ----- + | 
 | + ----------------- + | 
 + ------------------------ -------- + 
 
 Solte C em "...". 
 + ---------------- -------------- + 
 | + ----------------- + | 
 | | + --- + + --- + | + --- + | 
 | | | A e | B | ou | C | 
 | | + --- + + --- + | + --- + | 
 | + ----------------- + | 
 + ------------------------ ------ + 
 
 Solte "não" em C. 
 + -------------------- ------------------ + 
 | + ----------------- + + ----------- + | 
 | | + --- + + --- + | | + --- + | | 
 | | | A e | B | ou | não | C | | 
 | | + --- + + --- + | | + --- + | | 
 | + ----------------- + + ----------- + | 
 + ----------- --------------------------- + 
 
 Solte "ou" depois de "não C". 
 + ---------------------------------------------- ------- + 
 | + -------------------------- + | 
 | + ----------------- + | + ----------- + | | 
 | | + --- + + --- + | | | + --- + | + ----- + | | 
 | | | A e | B | ou | | não | C | ou | ... | | 
 | | + --- + + --- + | | | + --- + | + ----- + | | 
 | + ----------------- + | + ----------- + | | 
 | + -------------------------- + | 
 + --------------- -------------------------------------- + 
 
 Soltar D para "...". 
 + ------------------------------------ --------------- + 
 | + ------------------------ + | 
 | + ----------------- + | + ----------- + | | 
 | | + --- + + --- + | | | + --- + | + --- + | | 
 | | | A e | B | ou | | não | C | ou | D | | 
 | | + --- + + --- + | | | + --- + | + --- + | | 
 | + ----------------- + | + ----------- + | | 
 | + ------------------------ + | 
 + ----------------- ---------------------------------- + 

Elementos de consulta individuais (A, B, etc.) são construídos antes de serem descartados no painel, usando caixas de combinação ou quaisquer elementos necessários. Margens pequenas e cores alternadas podem tornar isso muito legível, bem como exibir regras que tornam, por exemplo, uma cadeia de ors exibida em um único nível:

 + ------------------------- + 
 | + --- + + --- + + --- + | 
 | | A ou | B ou | C | 
 | + --- + + --- + + --- + | 
 + ------------------------- + 

Naturalmente, os elementos de consulta podem ser expandidos, recolhidos, reordenados e editados após serem soltos no painel de composição.

Não estou dizendo que essa é a maneira mais fácil de construir um sistema para esse fim. De fato, do ponto de vista do desenvolvimento, provavelmente é tão difícil quanto possível. Mas é a coisa mais eficiente e intuitiva que eu posso criar, e de qualquer maneira é basicamente apenas um clone da interface do usuário da regra de email Apple Mail, mas com mais ênfase na hierarquia.

Espero que isso seja útil na sua busca pelo que é certo.

CognitoForms tem a solução de E/OU mais intuitiva que eu já encontrei

Aqui está uma interface para compor a lógica booleana.

Alguns pensamentos

• A interface começa simples
• Se fica complicado, é porque o usuário construiu passo a passo
• Sem edição ou arrastar/soltar - apenas criando e excluindo ramificações
• As condições são uma lista suspensa simples neste exemplo, mas podem ser mais complicadas ou possivelmente negadas

Ambiguidade

Além disso, eu também me preocupo com a ambiguidade das camisas "mostre-me vermelho e azul", já que o usuário tecnicamente pode significar "vermelho ou azul "camisas.

Eu acho que se você perguntar a eles para descrever a versão singular (uma "camisa"), o problema será um pouco reduzido. Por exemplo, eles não diriam "Mostre-me uma camisa vermelha e azul" se eles significam "vermelho ou azul".

Adicionando exemplo do aplicativo de emissão de bilhetes que desenvolvemos.

Em vez de agrupar "AND/OR", optamos pelo menu suspenso "all/any/none" no topo. Exatamente por causa do exemplo acima mencionado: quando pessoas não técnicas dizem "ordens de me dê de Nova York e Nova Jersey" tit realmente significa "OR lógico".

Também decidimos não agrupar várias combinações complexas de AND/OR, pois as pessoas ficavam confusas. Em vez disso, oferecemos a eles uma "recursão", oferecendo "acionar outra regra" (na parte inferior da captura de tela).

Estou trabalhando na reformulação de um aplicativo Web que usa Boolean e a imagem abaixo mostra como ele está sendo feito no momento. O usuário pode excluir os colchetes quando necessário ou adicioná-los novamente. Estou tendo dificuldades para encontrar uma maneira melhor de fazer isso, por isso pode acabar mantendo essa parte que os usuários parecem estar usando muito bem.

Minha interface de usuário favorita para criação de regras é servidor de cenário da ATG . Veja isso:

Para criar relativamente complexas tabela única consultas, tabelas dinâmicas são muito úteis.

Coisa boa

1. Você pode obter SUM, AVG e GROUP com relativamente pouco conhecimento.
2. Ao dividir campos entre colunas e linhas, você recebe AND consultas
3. Os totais fornecem OR consultas
4. Você pode 'criar' consultas adequadamente - ou seja, é possível ver rapidamente um conjunto mestre, adicionar linhas/colunas e adicionar filtros que mostram quais dados estão disponíveis para filtrar

Coisas ruins

1. Acho que você atingirá os limites se tentar combinar mais de uma tabela/conjunto de dados.
2. Dependendo de quão profundamente aninhado você deseja suas consultas AND/OR, pode haver problemas

Mas pelo menos você não tem uma tonelada de caixas de combinação, e as caixas de combinação que você possui são mais intuitivas.

Aqui está um que eu fiz anteriormente com algumas estatísticas adoráveis ​​de futebol de fantasia para acompanhar.

É difícil definir exatamente o que é intuitivo para algo que tradicionalmente é tratado por usuários técnicos (que não necessariamente encontrará interfaces mais amigáveis ​​do que as solicitações de comando). Há uma razão específica para essa eficiência, pois as consultas podem ser especificadas e executadas de maneira inequívoca em um prompt da linha de comando. Além disso, provavelmente não surpreenderá ninguém que o design de interface tradicional provavelmente seja interrompido quando se trata de consultas mais complexas.

No entanto, acho que é seguro dizer que, quando se trata de lógica booleana, o tema mais comum/familiar deve ser o diagrama de Venn. Portanto, a questão pode ser como pegar as instruções precisas das consultas ao banco de dados e combiná-las com a simplicidade de um diagrama de Venn como interface?

Penso que, conceitualmente, uma solução possível seria combinar o layout espacial com as interações do usuário que refletem a natureza das operações que estão sendo executadas. Dessa forma, você transmitirá o conceito do diagrama de Venn aos usuários, tornando as operações 'intuitivas' o suficiente para entender. Portanto, isso está efetivamente tomando o que @bendytree e @sboye sugeriram para fazer a entrada de dados real, mas também produzindo o resultado dessas operações na forma de um diagrama de Venn, para que o usuário possa ver imediatamente se executou o tipo certo de operação booleana . Mas você pode facilitar ainda mais a entrada, implementando alguns drag'n'drop para os operadores booleanos e conjuntos de dados/campos que deseja exibir, inspirando-se em alguns dos diagramas interativos de Venn que você pode encontrar nas pesquisas do Google.

Se for móvel, tenha um botão para cada operação que simplesmente o insira em uma caixa de texto. Forneça um link para ajudar na álgebra booleana e similares. Isso seria fácil e flexível.