通常、人々はデータ/インターフェースが多すぎて画面の領域が足りないことに関心を持っていますが、私は反対の状況にあります。
私が取り組んでいるデスクトップアプリケーションには、データを入力してオプションを選択するためのいくつかのタブがあり、最後のタブには、いくつかの計算を行った後のデータの概要が表示されます。
私のタブの1つはかなり複雑なので、必要なGUI要素をすべて収めるために、アプリケーションウィンドウのサイズを1024x768に設定しました。問題は、他のいくつかのタブが非常に単純であり、余白が多すぎます。これまでに2つの方法を試しました。
右側にも大きなスペースがあります。中央揃えを検討しましたが、デスクトップアプリケーションの場合は少し奇妙に見えると思います。
ここに私が現在持っているもののスクリーンショットがあります:
私の他のタブの1つに本質的に同じ問題があります。
だから私の質問です:余白が多すぎて要素を埋めるのに十分な要素がない場合、どうすればGUIレイアウトにアプローチできますか?
スクリーンショットが正しいことを理解できれば、複数の建物や複数の部屋を持つ場所があります。しかし、場所は最も上のレベルです。
左側にツリービューナビゲーションがあり、建物や部屋などの下位レベルのノードがあると思いますか。
右側には、特定のデータとコマンドボタンのプロパティビューがあります。
そのマスター/ディテールパターン。しかし、リストビューのように、すべてのプロパティデータが1つのビューにあるわけではありません(今のところはそうです)。それでも空白スペースはありますが、左側と右側を分割するための垂直中心線は、ボタンに目を向けます。
タブが多すぎる可能性があります。 2つのまばらなタブを1つに結合するか、残りの2つのタブのそれぞれに1つのまばらなタブを配置するか、またはおそらく最も単純な残りのタブに両方のまばらなタブを配置します。ユーザーにとって意味のあるタブラベルが付けられます。)タブの数が少ないほど、ナビゲーションが少なくなるので、より良い方法です。
もう1つの可能性は、複雑なタブが複雑すぎることです。ユーザーがそのような複雑さをほとんど必要としない場合(つまり、通常、ほとんどの設定でデフォルトを使用する場合)、使用頻度の低いコントロールの一部を複雑なタブから1つ以上のダイアログボックスに移動し、設定の概要のみを表示します。メインウィンドウで。このアプローチを使用すると、タブがなくなる可能性があります。 1つのペインで、2つのスパースタブのすべてのコントロールと、複雑なタブのサマリーコントロールを使用でき、サマリータブを削除できます。
さらに別の可能性として、すべてが1つのウィンドウに属しているわけではありません。複雑なタブがユーザーの最初または2番目の作業である場合、おそらくそれがフルサイズのプライマリウィンドウである必要があります。そこから、ユーザーは小さなタブ付きダイアログ(またはウィザード)を起動して、残りのステップを完了します。潜在的に、ユーザーは、最初に別の小さなダイアログ(「開く」ダイアログを使用するなど)でプライマリウィンドウを「初期化」できます。プライマリウィンドウのデザインは、プライマリウィンドウでの作業中にユーザーが作業内容を(おそらく「ドラフト」として)保存できるようにする可能性も開きます。複雑な作業が行われている場合は常に良いアイデアです。
コンテンツの下にスペースを残しても問題はありません。多くのアプリケーション/エディター、特にEclipseがそれを行い、静的サイズのウィンドウにこのスペースがあることは、選択されているタブに応じてウィンドウのサイズを変更するよりも間違いなく優れています。画面上を移動するボタンを使用してウィンドウのサイズを変更すると、ユーザーを混乱させ、おそらくユーザーを苛立たせるだけです。どちらの場合でも、ウィンドウスペースを効率的に使用していることへの感謝の気持ちが失われます。
ただし、他にも考慮すべき点があります。 右下隅にあるボタンバーの慣例に従ってお会いしたいと思います。これはWindowsアプリケーションの標準であり、従う必要があります。
さらに、私の想定から、「リセット」ボタンはウィンドウを閉じ、ユーザーがそのビューで行ったすべてのアクションを無視すると思いますか?その仮定は正しいですか?私が正しいと思ったなら、あなたは本当にそれを変えるべきです。 「リセット」ボタンが「キャンセル」ボタンと同じかどうかを尋ねる必要性を感じている単純な表示は、アフォーダンスの欠如を示しています。この場合、ボタンのテキストを「キャンセル」に切り替える必要があります。ただし、それがキャンセルボタンではなく、それが何か他のことを行う場合(構成ファイルから以前の設定を読み込む?IDK)、実際に移動することを検討する必要があります。これは、[OK]/[保存]/[確認]ボタンの右側にあるキャンセルボタンの従来のマッピングがあるためです。
インスピレーションを得るためにモックアップを作成しました。私のアイディアを表示するためだけに、多分あなたはそれから何かを取ることができます。幸運を!
TreeViewナビゲーションのアイデアは気に入っていますが、使い勝手が悪いと思います。私の考えをよりよく理解できるように、ワイヤーフレームを描きました。これは一種のTreeViewに似ていますが、多くのサイト、建物、部屋の間をナビゲートするのが簡単で、気になる空のスペースをカバーします。これを「3層アーキテクチャ」と呼び、OSXフォルダビューに従います。
ワイヤーフレームはかなり理解できると思います。
パンくずリスト
下部にパンくずビューを追加しました。これにより、ユーザーはどこに何をナビゲートしているのかがよくわかるようになります。
右クリック
各レベルには、対応する右クリックがあります。 「サイト」レベルの場合、「サイトの追加」または「サイトの削除」が表示され、建物や部屋の追加、削除は表示されないとしましょう。
このソリューションが気に入っていただければ幸いです。ナビゲートと表示が簡単で、クリック数を減らすことができます。キーボードとマウスのショートカットを追加して、使い心地を良くすることができます。
画面のアーキテクチャを正しく解釈した場合は、それらのグループをすべて削除して、それらをTreeViewコントロールで置き換える方がよいでしょう。つまり、「部屋」は「サイト」に属する「建物」に属しているように見えます。少なくとも、「部屋」と「建物」は関係を共有しているように見えます。
ToolStripバーがあります。
サイトを追加|建物を追加|部屋を追加|編集|削除する
そして、あなたのTreeView:
サイト:
|-サイト#1
|-サイト#2
.... |-建物#1
....... |-部屋#1
.... |-建物#2
|-サイト#3
.... |-建物#3
強調表示されている「ノード」は、編集または削除されるアイテムです。
これは、右側のスペースを埋めるという反対の問題を引き起こす可能性があります。その場合、選択したノードの「プロパティ」情報を、PropertyGridのように右側に移動できる場合があります。
ほとんどのOS Xアプリケーションは、設定ウィンドウのサイズを変更するだけでこれを処理するため、各タブに最適なサイズになります。 「設定」ウィンドウがアプリケーションから分離している場合、ユーザーはウィンドウのサイズを変更しても問題ありません。モーションは明らかに滑らかでなければなりませんが、適切に行われると、この種の動作は私にとって不快ではありませんでした。例:
縦のスペースが問題だと思います。選択したタブに基づいてウィンドウの高さを調整する方法はありますか?
サイト、建物、部屋を表示するためのボタンが2つあるドロップダウン以外のメカニズムを選択できますか?多分一連のグリッド-ユーザーがグリッドを直接編集/削除/追加できるようにします。
また、タブとそのコンテンツを組み合わせるか、別の方法で再編成することを検討する必要があるというマイケルのコメントも2番目に示します。
4つの入力領域すべてにドロップダウンがあるので、現在のようにすべてを1つ下に配置するのではなく、水平に配置するのが自然です。
そうすれば、UI要素を再配置して、より適切に分散させることができます。下半分にはまだ空白スペースがありますが、ドロップダウンの準備のように見えます。
おそらく、3つの「構成」セクションすべてをタブの上3分の1に並べて配置し、下3分の2を埋めるグラフィックで、選択内容に従って更新することができます。または、グラフィックではなく、これまでに行ったすべてのテキストによる要約。