web-dev-qa-db-ja.com

上級ユーザーと基本ユーザーの両方に対応できるように非常に複雑なテーブル/検索構造を設計するにはどうすればよいですか?

これは、マップアプリケーション用に設計している検索ポップアップの「テンプレート化された」ビューです。

デスクトップではフローティングポップアップ、モバイルではフルスクリーンポップアップです。

enter image description here

これがコンテキストで動作していることを示すgifです: https://i.imgur.com/iaK70U1.gif

いくつかのことについて説明してみましょう。

Table Name:データベース内の検索するテーブルを切り替えるモーダルメニュー。これを変更すると、下のフィールドが自動的に変更されます。

フィールドメニュー:フィールドの表示を有効/無効にできるモーダルメニュー。これはエクスポートに影響します。

Export Menu:データをエクスポートするタイプを選択できるモーダルメニュー。

フィールドx:以下の表の通常のフィルタリング入力。一部は選択されています。

関連フィールドx:関連フィールドの表示を切り替えるボタン。

関連フィールドx.x:サーバー側の入力。他のテーブルで検出されたリレーショナルフィールドを検索し、このフィールドでフィルタリングします。 AKA 3Dデータ。これらはより高度なオプションであるため、最初は非表示にしました。

一番左の固定列:マップ上のレコードを表示する「移動」ボタン。

すべての入力フィールドは自動的に作成されるため、レイアウトを指定できないことに注意してください。

言うまでもなく、これはモバイルフレンドリーでもあるはずです...うまく機能しますが、フレンドリーについてはわかりません。

私が受け取ったいくつかのフィードバック:

Table Nameメニューからテーブルを切り替えることができるかどうかは明らかではありません。これはユーザーにとって最初のステップですが、出発地点。

ユーザーはウィンドウに慣れており、ウィンドウにはタイトルバーの左側にアクションボタンがありません。これらは非表示になる場合があります。

このフィードバックの私の問題は、タイトルバーの下のコンテンツボックスにアクションを配置すると、操作が混乱するだけでなく、上部にこの無駄なスペースがすべてあることです

視覚的なフィードバックがないと、ポップアップがWebページを垂直方向にオーバーフローすることが多いため、テーブルの一部が非表示になり、ユーザーがいずれかのフィールドを使用してフィルターをかけたときに、キューがありません。

もう1つの問題のフィードバックがないのは関連フィールドです。これらはフィルターであるため、テーブルの列として表示されないため、ユーザーは「ルックアップ」してそれが実際に求めているものであるかどうかを確認できません。アプリケーション。


私の最大の問題は、私が最初にプログラマーであり、6か月前にフロントエンドに入り、これだけで作業するのは完璧に思え、必要なすべてを実行できることです。 。

特にかなりの量の「古い」ユーザーがいることを考えると、複雑なツールにはいくつかのトレーニングが必要だと考えることはできますか?これは、私たちのデータが非常に複雑だからです。優れたUIでできることはこれだけです。


先ほど触れたように、主にプログラマーとしてこれだけで作業すると、このレイアウトではトンネルが本当に見えてしまい、他の目にはまったく見えません。

5
Mojimi

基本的に、初心者と上級ユーザーの両方が同じプロセスを実行します。

  1. 結果を探す
  2. 必要に応じてフィルタリング
  3. フィルタリングされた結果を探索する
  4. GoToステップ2

実際には、おそらく3から5を超えるフィールドがあり、たとえば20なので、結果とフィルターは1つの画面に収まりません。

「結果の探索」と「フィルタリング」を明確に分離することをお勧めします。方法は次のとおりです。

テーブルが選択された後、ユーザーにはフィルタリングされていない結果が表示されます

enter image description here

「フィルター」をクリックすると、別の画面が表示され、何かを変更したり、変更せずに戻ることができます

enter image description here

複雑なフィールドの場合:

enter image description here

フィルターを適用した後、同じ結果リストとアイコンが表示され、フィルターがあることを示します。

enter image description here

シンプルでありながらパワフルなデザインで、携帯電話やタブレットに対応しています。

UPD:幅の広いデバイスでは、サイドバーを使用できます。フィルターリストのアイデアを再利用できます。デスクトップアプリの場合、フィルターリストはおそらくネストされたリストよりもアコーディオンのように見え、機能する必要があります。私はあなたがアイデアを理解していると思います:)

enter image description hereenter image description here

処理すべき詳細はたくさんありますが、一般的に、多くのアプリはそのように機能します。ほとんどの場合、ユーザーはこのデザインをすぐに理解できます。

5
ADOConnection

ますます多くのマップ/ GIS関連アプリケーションが毎日表示されるようになっているため、これは一般的なアプリケーション設計に関連するものでもありますが、もう少し検討する価値のある質問です。

実際、より詳細な設計フィードバックを提供することは少し難しいですが、フルスクリーンのスクリーンショットを提供できれば、より多くのコンテキストを提供し、人々がより良いアドバイスを提案できるようになります。地図にはすでに非常に複雑で豊富な詳細が含まれているため、すばやく簡単な表示/入力のみを提供するポップアップを作成すると、ユーザーは情報で過負荷になり、圧倒されます。これは、ユーザーから得たフィードバックやエクスペリエンスのようです。

問題は、シンプルで高度なユースケースに対応しようとすると、設計の目的/目標が異なるため(多くの場合、矛盾します)、次の2つの戦略のいずれかを選択することです。A)バランスを見つける真ん中、つまりすべての人のために機能するものOR B)は、さまざまなユーザーのためにさまざまなビュー/相互作用を設計します。

戦略A)を使用している場合は、両方のユーザーグループの最も重要なユースケースを見つけて、それらに最適なユーザーエクスペリエンスを作成する必要があることを意味します(少なくとも両方のグループの取り込みを促進したい場合)。

戦略B)を使用している場合は、基本ユーザーから複雑な機能を隠し、上級ユーザーが複雑な機能を発見できるようにするアダプティブインターフェイスを作成しようとすることを意味します。より複雑なアプローチは、ユーザーがより複雑な機能の使用を開始し、デフォルトのビューを切り替えてそれらの機能を表示し、ユーザーがそれらを使用しない場合、これらの機能をビューから非表示にするときに使用状況情報を追跡し、解決することです。

複雑なツールには間違いなくより多くのトレーニングが必要ですが、うまく設計されていない「新しい」機能でも、複雑なツールと同じくらいの問題を引き起こします。ユーザーが遭遇する問題の量を減らすために、ソフトウェア機能リリースの一部として常にトレーニングとオンボーディングを検討する必要があります。

発生している問題に関するいくつかの提案:-テーブル名の切り替え機能が明確ではない:持っているテーブルの数によっては、これをドロップダウンからタブ/ボタンスタイルの表示に変更して、から選択するオプションがあることをユーザー。通常、これらのタイプの機能はタイトルバーで非表示になっていないため、混乱の原因となる可能性があります。ユーザーにアクションの場所を知らずに、アクションを使用できないようにするよりも、少しスペースを無駄にした方がよいでしょう。 -視覚的なフィードバックの欠如とコンテンツの非表示:ユーザーがセクションを展開したり折りたたんだりできるようにコンテンツを構造化して、すべての情報を表示し、詳細を公開したい場合その後、他のコンテンツが非表示になる可能性があることを認識しています。

ユーザーの入力とフィードバックに適切にアクセスできるように見えるという利点があります。そのため、レイアウトとデザインのさまざまな戦略を少し試してみて、何が適切かを判断する必要があります。彼らが実行する必要があるタスク。同様のアプリケーションを確認するか、表示する情報の種類に対応するいくつかの一般的なデザインパターンを参照することをお勧めします。

1
Michael Lai