ブール論理を構成するための直感的なインターフェース？
私は人々がどのように持っているかを知りたい、または論理ブール条件の構築を簡素化するインターフェースを構築しますか？ （はい、それはデータベースクエリビルダーです）私の考えでは、悪いインターフェイスでは、AND、NOT IN、ORキーワードなど）をたくさん入力しています。
誰かが私からアイデアを収集できる良い例があるかどうか疑問に思っていますか？またはいくつかの提案？
現時点では、クエリを構成するためのグリッドと、条件のセットとそれらがどのようにオーバーラップするかなどを視覚的に表示するためのグリッドを備えた分割画面を検討しています。ベン図のように。これでも、グリッドのコントロールの使いやすさ/直感性に問題があります。
編集：私はあまり技術的でないユーザーのためにそれを簡素化するアイデアに非常に興味があります。ただし、上級ユーザー向けのUIバージョンのアイデアも非常に役立ちます。
ITunes 9以降も参照してください。これは、「ネストされた」AND/OR式を実行する機能を追加します。これは、プログラマーが括弧でそれを行う方法に似ています。
技術者以外のユーザーがブールロジックで抱える主な問題は、ANDとORの違いを理解することです。これは常に自然言語に対応しているわけではないためです（たとえば、「ニューヨークと新しいJersey」はほぼ確実にLocation = NY OR Location = NJ）を意味します。多くの場合、ユーザーは「or」を排他的ORと解釈する傾向があります。次に、ネストされた括弧のトラックが失われるという問題があります。
これらの問題の両方を回避する1つの解決策は、配管または電気的なメタファーを使用してロジックをグラフィカルに表すことです。このアプローチを採用する作業には、いくつかの行があります。
シュナイダーマン、B（1991）。情報探索のためのビジュアルユーザーインターフェイス。第54回米国情報科学学会年次会議の議事録、28、379-384。
Murray NS、Paton NW、Goble CA、Bryce J（2000）Kaleidoquery —フローベースの視覚言語とその評価。 Journal of Visual Languages＆Computing、11（2）、151-189。
クエリビルダーは、個別の基本モードと詳細モードを使用するのが理にかなっている数少ない場所の1つです。ユーザーのクエリの90％がいくつかのパターン（例：「Xxxxで始まる名前の顧客」、「未払いの請求について責任を負うアカウント」、「日付aとbの間の注文」 」）。まれなアドホッククエリ用にKaleidoqueryのようなものをAdvancedの下に配置するときに、これらを簡単に選択および指定できる定型クエリまたは半定型クエリとすることは理にかなっています。
これは、テクニカルユーザーと非テクニカルユーザーの両方で十分にテストされており、可能なほとんどすべてのデータベースクエリを生成できます...
利点は非常に明確であり、ユーザーはドラッグアンドドロップ（or delete）を実行できます。ツリー内の任意の式または式のグループ。
欠点は、それが消費するスペースの量です。
これを実行するQueryBuilderと呼ばれるjqueryプラグインがあり、興味深い方法でこれを実行します。 http://mistic100.github.io/jQuery-QueryBuilder/
私はAppleメールルールが機能する方法が好きです：
ここには、特にいくつかの既存のアプローチに対する、かなりの数の優れたアイデア/参照があります。いつもではありませんが、多くの場合、Appleのアプローチから始めるのが適切ですが、おそらくあなたの場合はそうではないかもしれません。多くのフィールド/変数で構成された非常に多くのデータを操作しているように感じます（実際には言っていませんが）。
あまり技術的でないユーザーがシステムを使用することを期待している限り、技術的でないユーザーのためにそれを簡素化する方法を見つけることは良い考えであることに同意します。そうでなければ、それほど複雑でないインターフェースを開発することは、ほとんど利益を得るために多くの仕事になるかもしれません。私はベン図のアイデアも気に入っています-それがどのように機能するかを見るのは興味深いでしょう。
ただし、これを簡単にする方法に関する実際の提案の観点から、別のアプローチは、自然言語と使い慣れた「Web」のルックアンドフィールを組み合わせてユーザーをプロセスに導く、ある種の「ウィザード」プロセスを作成することです。以下は、自動車データベースの例を使用して、これがどのように機能するかを示すモックアップです。
上記は、ステップ1がどのように機能するかを示しています。ユーザーは、関連するチェックボックスをオンにすることで、ユーザーが選択できるいくつかのオプションを利用できます。必要に応じて、1つ以上のチェックボックスを選択できます（または何も選択しない場合もあります！）。詳細情報が必要なオプションのチェックボックスを選択すると、関連する単語がハイパーリンクされます。ハイパーリンクされた単語をクリックすると、ユーザーに次の例のようなものが表示されます。
したがって、上記の例は、「車両は特定のメーカーによって製造されている」チェックボックスを選択し、ハイパーリンクされたテキストをクリックして検索結果に含めるメーカーを選択した場合にユーザーに表示される内容を示しています。もちろん、フリーテキストフィールドやオプションのドロップダウンリストなどを表示するかどうかによって、アプローチは異なります。
ここで、検索条件の「例外」に対処するために、基本的に最初のウィンドウを再作成しますが、次のように異なる表現を使用します。
したがって、上記の燃料例外を選択した後、ユーザーはハイパーリンクされた単語「特定の燃料」をクリックして、以下のように例外を選択します。
繰り返しになりますが、これは、条件に最適なものに応じて、ドロップダウンリスト、ラジオボタンなどになります。彼らはまた、同じプロセスを経て、車両の製造を望まない国を選択しました。
もちろん、私はこの「ウィザード」アプローチをあまり技術的でないユーザーのためのものであると考えています。また、Wizardアプローチに比べて合理化されている可能性がある、より複雑なアプローチに慣れているユーザーのために、「詳細」オプションを提供します。
[〜＃〜]補遺[〜＃〜]
さて、これは私を昨夜起き続けました。私は実際にこのWizardアプローチは非常に良い方法であると考えています。そのため、私の答えを改善するために戻ってくる価値があると思いました。
上記のモックアップ画像を更新し、分割画面を使用するという考えを拡張したいと思いました。
元々、最後の手順が完了した後、ベン図のアイデアのようなものを使用して、ユーザーが選択したものを視覚的に示すことができると思いました。しかし、その後、ユーザーが基準を修正するために行ったり来たりする方法もあるはずだという私の元の主張について考えました。だから今私はあなたの分割画面を使用してあなたが両方を達成できると考えています。以下は私が考えていることを説明するための新しい画像です：
したがって、上記は分割画面の2番目の部分に表示される可能性があるものの例です。ユーザーが基準を選択すると、これが更新され、選択内容が示されます。このアプローチでは、おなじみのWebのルックアンドフィールを使用して、ハイパーリンクで選択肢を強調表示します。必要に応じて、画面間を行き来することなく、画面内のハイパーリンクをクリックして基準を変更できます。ステップ。もちろん、new条件を選択したい場合は、関連する手順に戻る必要があります。しかし、あなたはアイデアを得ます。
私が言及したい他の唯一のことは、データの複雑さを知らずに、これを洗練する必要があるかもしれないということですWizardアプローチ。私の単純な車両データベースは2つのステップしか必要としませんが、複雑ですこのアプローチのポイントは、ステップ数ではなく、Wizardが自然言語を使用してステップを通して人々に語りかけるという事実です。可能な限り。
とにかく、これが他の回答と一緒に提供されて、考えさせてくれることを願っています。そしておそらく他のいくつか。これは良いトピックであり、多くのユーザーに関連すると思います。
幸運を！
これは、ユーザーの高度なレベルによって異なります。現在のバージョンのインターフェースに似たものがあり、グループ化が省略され、用語間の結合がORに修正されました。各項は否定できます。ほとんどのユーザーはこの種のクエリで問題なく、ほとんどのユーザーはより高度なクエリを正しく作成できません。現在、クエリの結果を使用して次のクエリの母集団を制限できる2段階のプロセスを実装しています（まだUIで明示的なグループ化を省略しています）。
このUIは、追加、削除、アクティブ化、非アクティブ化、および無効化できる制約の基本的なリストです。これは、ユーザーが作成するほとんどのクエリで十分です。データフローの概念に基づいた新しいバージョンの設計がありましたが（vistrailsから強力なインスピレーションを得ています。下記を参照）、それは実行されませんでした。 Vistrailsは、VTKパイプラインの作成に使用できる製品です。多くのUIのルートをたどる場合、データフローはクエリの作成に使用できますが、出力フォーマットの作成にも使用できます。
インスピレーションを探してください
- Yahoo Pipes
- アップルファインダー
- サンダーバード検索
- Vistrails
以前のようにピボットテーブルを再利用するのとは対照的に answered ですが、これはANDまたはORを繰り返す必要性を処理するために私が考えた実験的なUIです。
これは、ANDsが水平で、ORsが垂直であることを学習する必要がある1つの要素に依存しています。ただし、かなり複雑なブール論理を処理できます。
概観
A、B、C、D、およびEはブール式であると想定します。
ここでの概念をテストするために、標準のブール等価の2つの異なる側面をどのように描くかを示します。
(A and B) or C === (A or C) and (B or C)
これはより複雑なクエリにまで及びます：
((A and B and C) or D) and E
実際のUI
このデータテーブルの場合：
画面は2つに分かれています。
- フィルターのセット（事実上
ANDクエリ） - フィルターの組み合わせ
フィルターを設定し（これらは基本的な条件付きログで入力されるだけです）、それをドラッグして完全なクエリと「マージ」します。
新しいフィルターセットをドラッグすると、左側がフィルターされていないリストに戻り、右側に「マージされた」データセットが表示されます。
その後、右側で式をドラッグして編集できるはずですが、さらに多くの作業が必要です。
Microsoft Accessは、ビジュアルバージョンの "Query by Example" を生成することにより、単純なデータベースクエリUIで合理的な試みを行いました。
ネストされたUIの必要性を回避する（== --- ==）より自然な言語を使用しますが、行の冗長なエントリが少し増える場合があります。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
それは古い質問ですが、誰かが興味を持っている場合に備えて私は貢献したいと思いました。多くの興味深い答えが既に提供されていますが、私は私たちのアプリのために以下を設計しました：
最初は、最初のグループ式と1つのルールしかありません。 [条件の追加]をクリックすると、その上に新しい条件が追加されます。[グループの追加]をクリックすると、その下に新しいグループが追加されます。親グループからの追加グループは兄弟ですが、ネストされたグループ内から[グループの追加]ボタンを使用して無限のネストを作成できます。
モバイルデバイスでは、条件スタックと「削除」アクションボタン-テキストが「条件の削除」に変更されます。
デザインはうまく機能し、見栄えがよく、反応が良く、スペースをあまり消費しません。
追加されたボーナス：グループの上に、1本の線が最終生産状態を示します。
[XXXより後の日付（名前はNickと等しい）]
編集：技術者以外の人がより親しみやすくするために、私はこのスレッドで他の人が言ったことをフォローします-Appleのパスに従ってください。 AND/ORの代わりに、ALL/ANY +コンテキストを使用します。
ユーザーがクエリの階層を知るのに十分なレベルに達している場合、ユーザーに与えるグラフィカルインターフェイスは、邪魔にならないように十分に流動的でなければなりません。要素をドラッグアンドドロップして暗黙的な階層を作成することに基づくインターフェースが理想的だと思います。これは、ユーザーがクエリを構築する方法の注釈付きの視覚的な例です(A and B) or ((not C) or D)：
パネルにAをドロップします。 + --- + | A | + --- + Aの後に「and」をドロップします。 + --------------- ---- + | + --- + + ----- + | | | A |と| ... | | | + --- + + ----- + | + ------------------- + ドロップ「...」にB。 + ----------------- + | + --- + + --- + | | | A |と| B | | | + --- + + --- + | + ----------------- + 後に「または」をドロップ"および"。 + -------------------------------- + | + ----------------- + | | | + --- + + --- + | + ----- + | | | | A |と| B | |または| ... | | | | + --- + + --- + | + ----- + | | + ----------------- + | + ------------------------ -------- + Cを「...」にドロップします。 + ---------------- -------------- + | + ----------------- + | | | + --- + + --- + | + --- + | | | | A |と| B | |または| C | | | | + --- + + --- + | + --- + | | + ----------------- + | + ------------------------ ------ + Cに「not」をドロップします。 + -------------------- ------------------ + | + ----------------- + + ------------ + | | | + --- + + --- + | | + --- + | | | | | A |と| B | |または|ない| C | | | | | + --- + + --- + | | + --- + | | | + ----------------- + + ----------- + | + ----------- --------------------------- + 「or C」を「not C」の後にドロップします。 + ---------------------------------------------- ------- + | + -------------------------- + | | + ----------------- + | + ----------- + | | | | + --- + + --- + | | | + --- + | + ----- + | | | | | A |と| B | |または| |ない| C | |または| ... | | | | | + --- + + --- + | | | + --- + | + ----- + | | | + ----------------- + | + ----------- + | | | + -------------------------- + | + --------------- -------------------------------------- + ドロップ「...」へのD。 + ------------------------------------ --------------- + | + ------------------------ + | | + ----------------- + | + ----------- + | | | | + --- + + --- + | | | + --- + | + --- + | | | | | A |と| B | |または| |ない| C | |または| D | | | | | + --- + + --- + | | | + --- + | + --- + | | | + ----------------- + | + ----------- + | | | + ------------------------ + | + ----------------- ---------------------------------- +
個々のクエリ要素（A、Bなど）は、コンボボックスまたは必要な要素を使用して、パネルにドロップされる前に作成されます。小さなマージンと交互の色は、これを非常に読みやすくするだけでなく、たとえばorsのチェーンを単一のレベルで表示する表示ルールを作成することもできます。
+ ------------------------- + | + --- + + --- + + --- + | | | A |または| B |または| C | | | + --- + + --- + + --- + | + ------------------------- +
当然のことながら、クエリ要素は、作成パネルにドロップされた後、展開、折りたたみ、並べ替え、編集ができます。
これがこの目的のためのシステムを構築する最も簡単な方法であるとは言っていません。実際、開発の観点からすると、おそらくそれは可能な限り困難です。しかし、これは私が思いつくことができる最も効率的で直感的なものであり、とにかくそれは基本的にAppleメールルールUIのクローンですが、階層に重点を置いています。
これが正しいものの検索に役立つことを願っています。
CognitoForms には、私が遭遇した中で最も直感的なAND/ORソリューションがあります 
これがブール論理を構成するためのインターフェースです。
いくつかの考え
- インターフェースは単純に始まります
- 複雑になったら、ユーザーが段階的に作成したためです
- 編集もドラッグ/ドロップもなし-ブランチの作成と削除のみ
- この例では、条件は単純なドロップダウンですが、さらに複雑になるか、無効になる可能性があります
あいまいさ
余談ですが、ユーザーが技術的に「赤または青」を意味する可能性があるため、「赤と青を見せて」シャツのあいまいさにも関心がありました。 "シャツ。
単数形（「シャツ」）について説明してもらうと、問題は多少軽減されると思います。たとえば、「赤または青」を意味する場合、「赤と青のシャツを見せて」とは言えません。
開発した ticketing app からの例を追加します。
「AND/OR」をグループ化する代わりに、上部にある「すべて/任意/なし」ドロップダウンで解決しました。まさに上記の例のため：非技術者が「ニューヨークとニュージャージーからのギミ注文」と言うとき、Titは実際には「論理OR」を意味します。
また、人々が混乱したため、複数の複雑なAND/ORの組み合わせをグループ化しないことも決定しました。代わりに「スクリーンショットの下部にある」「別のルールをトリガーする」ことを提供する「再帰」を提供します。
私はブールを使用するWebアプリの再設計に取り組んでおり、以下の画像は現在どのように実行されているかを示しています。ユーザーは必要に応じてブラケットを削除するか、追加し直すことができます。これを行うためのより良い方法を見つけるのに苦労しているため、ユーザーが使用していると思われるこの部分を保持することになります。
ルールを作成するための私のお気に入りのUIは ATGのシナリオサーバー です。これをチェックしてください：
比較的複雑な単一テーブルクエリを作成するには、ピボットテーブルが非常に役立ちます。
いい物
SUM、AVGおよびGROUPは、比較的少ない知識で取得できます。- 列と行でフィールドを分割すると、
ANDクエリが得られます - 合計は
ORクエリを提供します - クエリを適切に「構築」できます。つまり、マスターセットをすばやく確認してから、行/列を追加し、フィルターに追加して、フィルターで除外できるデータを表示できます。
悪い質
- 複数のテーブル/データセットを組み合わせようとすると、限界に達すると思います。
AND/ORクエリをどの程度深くネストするかに応じて、問題が発生する可能性があります
しかし、少なくともコンボボックスはそれほど多くなく、持っているコンボボックスの方が直感的です。
これは私が以前に作成したもので、それに合う素敵なファンタジーサッカーの統計情報がいくつかあります。
テクニカルユーザーが従来扱ってきたもの（コマンドプロンプトよりもユーザーフレンドの方が必ずしも使いやすいとは限らない）の直感的なものを正確に特定することは困難です。コマンドラインプロンプトでクエリを明確に指定して実行できるため、この効率には特定の理由があります。また、より複雑なクエリに関しては、従来のインターフェース設計がおそらく機能しなくなることを誰も驚かないでしょう。
それにもかかわらず、ブール論理に関して言えば、最も一般的でおなじみのテーマはベン図でなければならない、と言っても安全だと思います。したがって、問題は、データベースクエリの正確なステートメントを取得し、それをインターフェースのようなベン図の単純さと組み合わせる方法でしょうか？
概念的に考えられる解決策は、実行されている操作の性質を反映する空間レイアウトとユーザーインタラクションの両方を組み合わせることです。このようにして、操作を理解するのに十分な「直感的」にしつつ、ユーザーにベン図の概念を理解させることができます。つまり、実際のデータ入力を行うために@bendytreeと@sboyeが提案したことを効果的に取り入れているだけでなく、ユーザーが正しいタイプのブール演算を実行したかどうかをすぐに確認できるように、これらの演算の結果をベン図の形式で出力しています。 。ただし、Googleの検索で見つけることができるインタラクティブなベン図のいくつかからインスピレーションを得て、表示するブール演算子とデータセット/フィールドにドラッグアンドドロップを実装することで、入力をさらに簡単にすることができます。
モバイルの場合は、テキストボックスに入力するだけの各操作用のボタンを用意します。ブール代数などに役立つリンクを提供します。それは簡単かつ柔軟です。