複雑なUIのすべてのインタラクションを単一の入力フィールドに置き換える：成功する実装はありますか？

Question

主な質問

以下の提案されたソリューションを実装する実装の例を提供できますか？
はいの場合、メリットと欠点、特にユーザーから報告されたとは何か ）？

SEガイドラインの状態として、事実についての意見をバックアップしてください。

バックグラウンド

基本的に非常に複雑なフォームである既存のインターフェースを持つ複数のクライアントがあります。毎日これらのインターフェースを使用しない人々は、それらに脅かされています。これらのクライアントは、インターフェースをブラウザーに移行する過程にあり、私たちはその機会を利用して、一般的にインターフェースを再考しています。

Google.comに強く触発されて、以下の解決策を提案しました。これは基本的に"フレンドリーな検索ダイアログとして表示されるコマンドライン"です。ただし、この概念は既存のGUIからの大きな逸脱です。 "oh my god、my jaw hiting floor"のようなフレーズを含め、他のクライアントとの内部テストが非常にポジティブであるにもかかわらず、一部のクライアントはリスクが高すぎると認識しています。したがって、先に進むには、それが他の場所で正常に実装されていることを示す必要があります。したがって、実装例の私の要求。

エンドユーザーは、ソフトウェアトレーニングを受ける弁護士、経済学者、エンジニア、事務員などです。ただし、一部のアプリケーションには何百ものフィールドがあり、日常のユーザーにとってアプリケーションが不安になります。

推奨される解決策

以下の図も参照してください。

インターフェイスを読み取り専用にします（テキストの選択をサポートします）。
上部に、大きくて親しみやすいGoogleスタイルの入力フィールドを導入します。
key-value pairs（主な使用例）に入力する場合、ユーザーがvaluefirst。
- 値の内容（正規表現と辞書を使用）や想定される現在の使用例など、いくつかの要因に基づいて、可能なkeysを自動的に導出します。オートコンプリートオプションとしてkeysを提示します。
コマンドを送信するときは、オートコンプリートとシノニムを使用して、入力フィールドでもこれを許可します。
- オプション：コマンドを選択すると、入力ビューが簡略化された「コマンドウィザード」に変換され、コマンドパラメータの入力が容易になります。詳細は以下。
このボックスを使用して、パワーユーザーにall変更を加えるオプションを提供します。
- 初心者に個々のフィールドを直接編集するオプションを提供します（たとえば、鉛筆アイコンがロールオーバーに表示されます）。同時に、この入力がメイン入力フィールドによってどのように完了できるかを目立たずに同時に通知します。

意図された利点

親しみやすさ：インターフェイスは、Google.comにできるだけ似ています。
読みやすさの向上、脅迫の軽減：既存のインターフェイスには、テンプレートごとに最大70のフォーム要素があります。私のクライアントの1つに対応する読み取り専用ビューがあり、カジュアルなユーザーほどこのビューを好む傾向があります。インタビューを受けたとき、彼らはフォームベースのテンプレートが威圧的であると率直に述べています。
より効率的で負担が少ない：ユーザーはマウスを使用する必要はありません。
コンテンツに焦点を合わせる：値を入力するとき、ユーザーは属性を指定する必要がないことがよくあります。
- バッチエントリ：ユーザーは一度に複数行のテキストをフォームに貼り付けることができ、各行/段落はkey-value pairsのためにマイニングされます（アクティブ化専用ダイアログ）。
登録ワークフローの改善：既存のテンプレートの一部は、複数の登録シナリオをサポートしています。専用の登録テンプレートは、開発と保守の面でコストがかかりすぎると考えられてきました。このインターフェイスは、これらの利益相反シナリオのタブオーダーなどの問題を解決する必要があります。
自然言語：同義語を使用すると、ユーザーは自分の語彙を使用してコマンドを開始することができ、ビジネスの好ましい命名法について通知されます。
- ガイド付きプロセス：オプションの「コマンドウィザード」は、辞書駆動のオートコンプリートをサポートし、パラメーターを入力するときにユーザーをガイドします。下の図を参照してください。さらに、ウィザードはバッチアクションをさらに簡素化します。
Embeddable： Fantastical's Mini Windowのように、非常に小さな入力フィールドを他の製品に統合できます。 Outlookは私のクライアントの1つの候補でした（ただし、技術的な負債のためにOfficeとのいかなる種類の統合も行いたくありません）。

シンプルな使用例

値の母集団

使用例：ユーザーがNumber plateフィールドに値「DD12345」を入力したいと考えています。
ソリューション：
- キーボードフォーカスは既に入力フィールドにあります。
- ユーザーは「DD12345」と入力（または貼り付け）します。
- Googleスタイルのいくつかの「オートコンプリート」行が入力フィールドの下に表示されます。トップアイテムはpopulate Number plate with DD12345です。
- ユーザーはarrow downとEnterを押して、オートコンプリートを選択します。
- 値は読み取り専用ビューに正しく入力されます。ハイライトが表示され、消えます。

コマンドの送信

使用例：ユーザーがナンバープレートの承認を希望しています。
ソリューション：
- キーボードフォーカスは既に入力フィールドにあります。
- ユーザーは「アプリ」と入力します。
- Googleスタイルのいくつかの「オートコンプリート」行が入力フィールドの下に表示されます。トップアイテムはApprove vehicle DD12345です。
- ユーザーはarrow downとEnterを押して、オートコンプリートを選択します。
- システムは、専用のフィードバックフィールド（ポップアップではない）で確認を提供します。車両のステータスは読み取り専用ビューで正しく更新されます。ハイライトが表示され、消えます。

スクリーンショット

既存のインターフェース–1^st 大量のテンプレートのうち、いくつかは同様に複雑です：

提案されたインターフェース–ユーザーが入力フィールドでコマンドを発行します（p、次にarrow downを押します）：

提案されたインターフェース–コマンドを発行するとき、オプションの「コマンドウィザード」がパラメーターの入力に役立ちます。

Kristiyan Lukanov · Answer

あなたのアイデアはうまくいかないと思います。主な理由は、最初にフォームに入力して検索バーが表示されることを期待するインターフェイスに到達した場合、最初に考えたのは間違った場所にいると思うので、データを入力できるフォームフィールドを期待するためです。ユーザーは、あなたのアプローチを使用してデータを送信する方法を知りません。それらは指示またはガイドされる必要がありますが、これは使い勝手の点でいいえです。別の言い方をすれば、このアプローチは、一貫性の sability heuristic に違反しています。他の同様のインターフェースとの整合性に違反すると、ユーザーは次のような質問をし始めます。X値を入力できる単一の検索フィールドからすべてのデータを入力できますか、データをどこに入力すればよいかなど。

あなたはあなたがコンソールのようなインターフェースとやり取りするのは簡単なので、他の誰にとっても簡単であると思います。それは、UIを開発しているときの典型的なプログラマーの間違いです。 ユーザーは操作しない方法で操作する方法を知っています。これが大きな違いです。 UIは開発者ではなくユーザーによって使用されます。それ以外の場合は、開発者インターフェイス（DI）という名前になります。

ユーザーが検索バーの使い方をすでに知っている場合は、おそらく操作が簡単です。しかし、問題は彼らがそれを使い始める方法を知らないということです。

複雑な検索バーを作成する代わりに、標準の入力フォームフィールドを使用して、それらを最適化する必要があります（不要なフィールドの削除、デフォルト値の活用、オートコンプリートなど）。