web-dev-qa-db-ja.com

大画面の不動産の設計の課題をどのように克服しますか?

この質問はもう少し主観的ですが、私はいくつかの新しい視点を得ることを望んでいます。私は特定の画面サイズ(通常は1024x768)の設計に慣れているので、そのサイズは問題にはなりません。サイズを1280x1024に拡大しても、かなりの違いを生み出すのに十分な画面領域は購入できませんが、少し余裕ができます。基本的には、「グリッドサイズ」を拡張するだけで、わずかに小さい画面でも同じ基本設計が機能します。

ただし、最後の2つのプロジェクトでは、私のクライアントはすべて1080p(1920x1080)画面を使用しており、可能な限り多くの不動産を使用するソリューションを求めていました。幅1920ピクセルの幅は、私が慣れている幅の2倍弱です。ワイドスクリーンを使用すると、昔の設計の一部がうまく機能しなくなります。私が遭遇している問題は、非常に多くのスペースが提示されると、いくつかの大きな問題に直面することです。

  • いくつの列を使用する必要がありますか?ワイドフォーマットは、2:1:1の分割(つまり、コンテンツ列が他の2つよりも大きい)の3列の分割に適しています。ただし、3つの列を使用する場合、その追加の列はどうすればよいですか?
  • 画面の領域を効率的に使用するにはどうすればよいですか?すべてを一度に画面に表示したいという誘惑はありますが、情報が多すぎると、実際にはアプリケーションが使いにくくなります。空白は、複雑な情報を理解するために重要ですが、多すぎると、関連する概念の分離が強すぎます。
  • 私は通常、複雑なデータを持つWebアプリケーションを使用しています。生データを理解するには、視覚化とプレゼンテーションが重要です。ユーザーも大画面(少なくとも24インチ)を使用している場合、一部の情報が視界から外れているため、ポインターを遠くに移動する必要があります。
  • ブログのような単純なサイトは、幅が制限されていると実際にパフォーマンスが向上し、その結果、多くの無駄な不動産が発生します。テキストボックスとテキストプレビューを並べて表示することは、そのタイプの画面の管理者側にとって大きなメリットになるのでしょうか。 (1:1 2列分割)。

あなたの答えのために、私はデザインのほとんどすべてが「依存する」ことを知っています。私が探しているのは:

  • 使用する一般原則
  • デザインへのアプローチの変化

この異なる形式での作業方法を自分自身に再訓練する必要があることに気づきました。私がこれまで取り組んできた解像度のすべてのバンプは、約25%です。640〜800(25%増加)、800〜1024(28%増加)、1024〜1280(25%増加)。ただし、1280から1920へのジャンプは、スペースの50%の増加に相当します。640から1024へのジャンプに相当します。レッスンを徐々に学習するために一般的に使用される中間サイズはありませんでした。


質問に少し集中するのを助けるために、私は問題管理システムであるAtlassian JIRAにいくらか似たプロジェクトを持っていました。クライアントが保持したいレコードには約6種類あり、それらはすべて互いに関連している可能性があります。データ収集は重要な問題ではありませんが、中心的な問題ではありませんでした。

問題のより重要な側面は、レコード間の潜在的な関係を示唆し、アナリストが報告されたインシデントのパターンを認識できるようにするシステムを作成することでした。

さまざまな問題領域に焦点を当てたさまざまなタイプのアナリストがいて、彼らの探索的なタイプの仕事の性質上、彼らは自分たちが何を望んでいるかを知りませんでした。彼らは、多くのデータを理解し、相関関係を描き、問題のクラスを特徴付ける必要があることを知っていました。


(もともとここで尋ねられました: https://softwareengineering.stackexchange.com/questions/45864/how-do-you-conquer-the-challenge-of-designing-for-large-screen-real-estate =、しかしこれはより適切かもしれないと言われました)


賞金のために:少し心を伸ばしてください。 「すべてを大きくする」というパットの答えは、答えの有用性に限界があります。多くのデータを理解し、レコード間の関係を見つける必要のあるユーザーについて話しています。すべてのサイズを単純に大きくすると、特に垂直方向が非常に制約されているため、画面上での表示が非常に制限されます。

18
Berin Loritsch

最も重要なことは、複数の詳細レベルのビューを一度に許可し、ビュー間の関係を説明することです。画面領域が実際に機能するのは、何かをクリックするのではなく、画面の別の部分を見るだけで、あるレベルから別のレベルに切り替えられるときです。

したがって、最初に行うべきことは、1つの画面に複数のレベルを取得し、パーツの関連付けと分離の両方に画面領域を使用することです(そして、それらを過度に込み合ったり圧倒したりしないでください)。リストのアイテムをハイライト表示し、画像にボックスを描画することで、関係を表示して、詳細を確認できます。

列の数は、その時点で画面にどのビューを表示するかによります。より視覚的な設定(画像編集、マップビュー)では、サムネイルビューやツールの詳細(フォトショップを考える)などの窮屈さを減らすために、それを1つのメインエリアとして、他の列を通常よりも少し広くすることを想像できました。課題追跡システムでは、3列のレイアウトの「詳細」セクションをさらに(垂直または水平に)分割して、顧客の詳細、返信、または関連する問題などを含めることを想像できます。

また、考慮すべきことは、スペースが広いことです。これは「大きくする」のプロモーションですが、実際に活用できるものです。幅の広い画面では、(たとえば)他の詳細を邪魔にならないように認識可能なサムネイルを表示したり、より多くの情報を並べて表示したりできます。 (小さな画面では、メールアプリの列リストに必要なものを収めることができなかったため、件名の半分だけ、または名前の最初の部分しか表示されませんでした。)

また、画面サイズが大きいほど、グラフやイラストを多く使用できます。クリックして情報にアクセスする必要があり、人々は写真よりもデータを好みます(私の経験です)。しかし、両方を持っている場合...

もう1つの提案は、データの視覚化とダッシュボードの設計に関するトピックを調べることです。

12
Inca

「すべてを広くすることはテキストのブロックである-主な問題は、行の終わりから右端の次の行の左端へのジャンプは、視覚的に支援されていない場合、苦痛です。

問題管理では、3列の表示は実際には自然に見えます(申し訳ありませんが、fogbugz)。

enter image description here? No I won't.

ユーザーが構成したクイックリンク(一般的なフィルターなど)を含むナビゲーション列、列でオーバーロードされていない、リスト/ツリー/すべての問題の列、および選択した問題または選択した問題の詳細。

それは1:2:2レイアウトを必要とし、そのため1920はまだ少しきついようです。
==>ここで、問題リストと問題の詳細の間で不動産を再配布する簡単な切り替えが役立つ場合があります。

一般に、このレイアウトはワイドスクリーンでonlyで機能します。他の解像度をサポートするには、いくつかのレイアウトの選択肢を提供する必要がある場合があります。

ok ok, layout choices

その可能性のために準備中をお勧めします。たとえクライアントが「いいえ、私たちはすべて大きなモニターを持っている」と言ったとしてもです。ときどき、小さなラップトップ、または画面の半分だけを使用する必要があります。

6
peterchen

設計

1つの長い(垂直)ページの考えを手放す必要があると思います。代わりに、ブラウザをブロックのコンテナまたはキャンバスと考えてください。ワイド画面では、ブロックはほとんど水平方向に整列します。それほど大きくない画面では、より多くスクロールする必要があります。大画面のみのデザインに陥らないことが重要だと思います。また、小さな画面がますます使用されるようになっています。代わりに、それをすべての画面で機能させ、情報を流し、独自の方法を見つけます。

私は例えば TaskRabbit が説明ビデオを配置する方法が好きです。彼らはそれを折りたたみの上に置きます。ここでは、ブラウザをページではなくキャンバスとして理解しています。

情報管理

matrixminority reportother multi-touch インターフェースなど、いくつかの映画にも触発されます。たとえば、マイノリティレポートを参照してください。その画面は1920x1080よりも大きくなっています:-)。彼らがしていることは、ズームを使用し、ユーザーがアイテムを交換できるようにし、物理的な距離です。ただし、後者はデスクトップでの使用には困難です。しかし、他の2つは興味深いものです。 特に人々が多くの情報を管理および分析しなければならないインターフェースを設計している場合。

ですから、あなたが言うように、計算能力が彼らの分析で彼らをあまり助けることができないとき、私はユーザーがそれを自分で管理できるようにするツールがより重要になると思います。また、ズームや置換などのツールは、多くのスペースを必要とします。 (そして空白を残してください!)

これらのアイデアを使ったいくつかの大まかなスケッチ。あなたはあなたがもっと多くのことを考えることができ、あなたのアプリケーションにもっと関連していると確信しています。

コンテナとしてのブラウザ、ユーザーのための情報コントロール: Browser as container, with information controls for the user

または、情報の種類をグループ化します。 Group types of information together

5
Lode

大きな画面の不動産は両刃の剣です。利点は、ユーザーにより多くの情報を表示するためのスペースが増えることです。ただし、デメリットは、より多くの情報をユーザーに表示することです。これは、ユーザーに表示する情報がタスクに関連せず、代わりにスペースを埋める場合にユーザーの効率を損なう可能性があります。

原則1:3つの列すべての情報が互いに直接関連していることを確認します。つまり、3つの列すべてのナビゲーションパスは相互に接続する必要があります。情報は、別の列のアクションの直接の結果として列に表示されます。

原則2:当然、ナビゲーションパスの開始は左の列から開始する必要があります。これは、左側の列がメインメニューまたはユーザーがタスクを開始してメインアイテムを選択するためのホーム画面になることを意味します。それが起こると、中央と右の列が開くはずです。中央の列がより深くなり、左側の列から選択した項目の詳細が表示されます。最後の右側の列には、最も多くの情報が表示され、ユーザーがタスクを実行する主要な作業領域です。

原則3:列の順序とサイズは、この情報構造を反映するように設計する必要があります。したがって、左側の列は最も細く、中央の列は少し太く、3番目の列は肥満になっているはずです。

原則4:右側の列は、ユーザーがほとんどのタスクを実行するための列です。これは、スペースが最も多く、情報が最も多く、ナビゲーションパスの最後の列だからです。中央の列は、ユーザーが実行しているタスクのプレビューまたはステータスを表示する場所です。左側の列にもステータスの手がかりが表示されますが、最も広いレベルにあるはずです。

これをわかりやすく説明するためにワイヤーフレームを作成しました(ここでは画像を投稿できなかったため、投稿できませんでした): http://imgur.com/YbVbj?full

1
user3794

SmugMug をチェックして、いくつかのアイデアを見つけてください。彼らのサイトは、画面の水平解像度と垂直解像度に適応する優れた仕事をしています。 1ページあたりのサムネイルの数と、写真のサイズを調整します。

また、ウィンドウのサイズを変更すると、左側のサムネイルと右側の中間サイズの写真の間で50/50に近い分割が維持される傾向があることに気付くでしょう。明らかに、あなたはオンラインフォトギャラリーをデザインしていませんが、おそらく同様のレイアウトを使用できます。

1
Steve Wortham

Googleの "Designing for(Google)TV" Webページ— 720pまたは1080p画面を対象としたWebページの一般的なルールセットを確認することをお勧めします。

これには、「ナビゲーションに矢印を使用できることを確認する」などの一般的な問題がすべて含まれていますが、関連するポイントは、「1080p画面では18px未満のフォントサイズを使用しない」などです。

本質的には、まったく同じ方法で設計する必要があると言っているのですが、より大きな要素とフォントサイズを使用しています。画面上の情報が多すぎるとばかげているように見え、HD /高解像度画面では常に大きなフォントが必要になります。

0
tonyhb

ここで、1996年の調査の原則を示します。

  1. ユーザーが1画面での作業から2画面での作業に切り替えると、生産性は40%向上します(コーダー)。したがって、それはより多くのピクセルに対する強力な議論です。では、なぜ生産性が飛躍的に向上するのでしょうか。タブやアプリ間を移動するメモリと時間の無駄が少ないためです(少ないコンテキストの切り替え)。コンテキストの切り替えは高価です。したがって、新しい「土地」をuseしたい場合は、与えられた新しいピクセル領域を使用して、「コンテキスト」の頻度/リスク/確率を減らします。スイッチング」。つまり、アプリウィンドウを小さくして、通常アプリが機能する他のアプリを同じ画面に快適に合わせて、直感に反することを意味する場合があります。この例をGMAILで見ることができます。GMAILは、数年前にgmail作成メールエディタが小さくなり、サイズが小さくなったものです。

  2. アプリを他のアプリに親しみやすくします(これは1から派生しています)。アプリがアプリだけでなく全体をどのように最適化できるか見てください

  3. お役に立てば幸いです。

PIC:画面サイズが拡大したため、Gmail composerウィンドウが縮小されました... GMAIL COMPOSER DOWNSIZED SINCE 2015

0

Jira(私も使用しています)は、すべての要素を大きくすることでこの問題を解決します。2つの列がある場合、列の要素は異なる画面解像度で単に広くなります。これは最良の解決策ではないと思います。なぜなら、本当に広い画面では、かなり奇妙に見えるからです...

だから私があなただったら、中央揃えで、左側と右側にいくつかの空白があるインターフェースを作ろうとするでしょう:

このようにして、空白で遊ぶことができます:

  • 1680:画面の75%(1260)がコンテンツ、25%が両側の空白
  • 1920:(1440)同じスケールを適用できます-75%から25%

enter image description here

このソリューションを使用すると、コンテンツは約14%しか増加せず、両側に空白ができます。中央のすべてのコンテンツ要素は、可視性の要件に準拠するために(14%で)大きくなる必要がありますが、余白と中央揃えはuxを大幅に強化します。

  • あなたのUIは混雑しすぎないでしょう
  • 異なる画面解像度に合わせてUI全体を設計する必要はありません
  • x1.14乗数を適用する必要があります

私は1680 * 1050を使用していますが、慣れていないため、ブラウザアプリケーションを除いて画面全体に表示されません。すべてのWebサイトで、ほとんどすべてが低解像度用に最適化されています。そして、私は本当に空白が必要です。

Jiraには実際の空白はありません。1680年には、すべての要素が大きくなりすぎて、コンテンツがわずかしかありません。空白を適用すると、インターフェイス全体が使いやすくなります。

0

使用する一般原則

  • 情報のチャンク化、グループ化、セカンダリ要素のデザインでの目立たない例:このページの上部のメニュー行の背景が暗い。別の例は このサイト 両側にパネルを備えたフルスクリーンを使用して、二次情報とナビゲーションを保存します。

  • 情報の構造をフラット化して、一般的なタスクにアクセスするためのクリック数を減らす方法を探します。


画面の領域を効率的に使用するにはどうすればよいですか?

分析用のツールでドッキング可能なツールバーを使用できます。データ/分析のセットアップ中に選択して非表示にすることができる1つ以上の鉱石を持つことができます。


どのようにして、必要なものがすべて視覚的なホットポイント内にあることを確認しますか?

非常に大きなディスプレイを用意して、ユーザーがナビゲートできるセクションをビューポートに表示できます。例:google maps

0
Leah