私は、Windowsの「モダン」デザイン言語(néeMetro)を使用するアプリケーションに取り組んでいます。アプリには多くのデータ入力と操作が含まれます。 MS Accessで行うのと同じようなことを考えてみてください-マスター詳細、フォーム、クエリ/フィルターなど。Microsoftのモダンアプリに関するデザインガイドラインドキュメントは、コンシューマースペースに焦点を当てています。つまり、ビューには通常、大量のデータが含まれていません。
Microsoftには サンプルのWindows 8アプリの大規模なライブラリ がありますが、実際には密なUIを示すものはありません。密なUIとは、次のようなものです。
それで、私が探しているのは、モダンスタイルの高密度データスクリーンの例です(Microsoftまたは他の場所から)。または、そのようなアプリの作成方法に関するガイドライン。
@MichaelZuschlagは頭に釘を打ちます:メトロのための一致するガイドラインはありません、そして少なくとも私はどのプラットフォームでも(プラットフォーム全体で)何も見たことがありません。
一見すると、以前はMetroと呼ばれていたUIの目的は、UIが密集していることとは対照的です。 「高密度」画面は、詳細ページに分割する必要があります( ナビゲーションガイドライン を参照)。
最初の画面は、(大まかに)次のページに分割する必要があります。
(これらを追加/編集するためのページ)
基本的に、ページはタスク指向(誰かを見つけ、旅行を追加し、住所を修正する)ですが、「密」はデータ中心です。
実装でこの移行を行うことは非常に困難です。そして、移行を行うためにユーザーに「密な」インターフェースに慣れるのは簡単ではありません。 FKAMetroが良い選択になるかどうかは当然のことです。
ただし、Metroの側面をモダンに統合して、ユーザーの親しみをFKAMetroの概念に取り入れ、その背後にある「UXの進歩」を利用することができます。
いくつかの努力で持ち越すことができるもの:
ページあたりのデータが少なくなります。最初の例では、旅行リスト(住所の編集)を別のページに移動します。
理由:ユーザーは、主にインターネットを通じて「戻る」ボタンを使用することを学びました。ブレッドクラムは非常に一般的であり、コンテキストと拡張ナビゲーションの両方を提供できます。 Flyouts は、特に2次ナビゲーション、編集、および確認を統合するために使用できます
プレゼンテーション用にフォーマットし、オンデマンドで編集します。読み取るデータをフォーマットし、オンデマンドで編集できるようにします。例えばマウスオーバー、選択など。
編集可能なもの(薄いアイコン、背景色など)の一貫したインジケータが必要ですが、実際のフィールドを視覚的に支配しているため、アクティブなフィールド以外のすべての周りの従来の「ボックス」を削除します。環境。
理論的根拠:これは、モダンUIの「シンプルさ」に対する私の理解です。コンテンツがスポットライトを浴びるように、ウィンドウ装飾とアプリの「技術的側面」をトーンダウンします。
タスク指向のナビゲーション。最も一般的なユーザーアクティビティを前面に表示し、あまり一般的でない操作を後退させます。多くの場合、「高密度」では明示的なコマンドはほとんどありませんが、データを別のページに移動すると、UIが十分に解放されます。適合するものを見つけたら、 コマンドパターン を確認してください。
外観と詳細FKAMetroにインスパイアされた Style Elements と Layout を使用します。
一般的に、ユーザビリティ、エラー率などの点で、潜在的にほとんどリターンを返さないようにかなりの努力をしていると思います。「密な」アプリを取り、それをメトロっぽいものに変換し、ユーザーがどのように反応するかを見るのは興味深いでしょう。ユーザーはそれを嫌うかもしれませんし、おそらく最悪の場合はそれを "嫌"にするかもしれません。
「高密度」アプリケーションは、多くの場合、データベースにバインドされたフォーム要素と、テーブルまたはビューにバインドされたデータグリッドに過ぎません。 「美しい」アプリケーションのフロントエンド開発は、おそらくもっと高くなります。同様の一般的なメカニズムとコントロールの開発は、おそらく別の課題です。
カジュアルvsビジネス。「価値があるか?」にある程度関連しています。質問: 私はここで議論しました カジュアルとビジネスの使用にはいくつかの矛盾があります-非常に大まかに:カジュアルは「間違っていない、最悪の場合元に戻す」に依存しますが、ビジネスはしばしば変更の責任を取る必要があります。それぞれのスタイルが異なる場合があります。
すべての文字をごめんなさい:)
それらのコオロギを聞きますか?これは、any設計言語の高密度データプレゼンテーションのガイドラインがないようです。 GUIが最初に登場して以来、そのようなガイドラインが必要でしたが、私が知るものはありません。
それだけの価値があるので、私は何年にもわたって Coded、Compacted、Contrasting Controls で説明した、高密度英数字GUIプレゼンテーションのための独自のアプローチを開発してきました。偶然にも、それはたまたまMetroと美的に互換性があります(たとえば、フラットです)。上記の例は次のようになります。
私は、ユーザー数が少ないいくつかのアプリにのみデプロイしたので、完全にテストされたとは思いません。必要に応じて、それをインスピレーションとしてください。
一般的に、密なデータの提示にはタフテ風のミニマリストスタイルが必要だと主張します。データが多すぎて、色、線、陰影、グラデーション、3D、アニメーションを使用したり、スペースを浪費したりする余地がありません。重要な情報(コントロールの種類、有効化、編集可能性など)をグラフィカルに伝えながら、「インク」を最小限に抑える必要があります。内部で一貫性を保ち、既存のスタイルで可能な限り一貫性を持たせてから、ユーザーでテストして、少なくとも混乱しないことを確認してください。
私の答えは、まず第一にそのようなデータ負荷の高いアプリケーションを避けることです。関数をフローに分離できますか?または、これらすべてのインタラクティブな要素を同時に提示する必要がありますか?管理UIとプレゼンティブUIを分離できますか?ページあたりのアイテム数を減らすことに集中します。その量の情報とやり取りでできることは非常に限られているためです。
とはいえ、フォームをデザインするための第一人者はLuke Wroblewskiです。このプレゼンテーションを確認してください。これらのガイドラインに従うことで、次のものを大幅に改善できます。
Windows 8 PCのPC設定を参照して、そこで何が行われたかを確認する必要があると思います。すぐにはわかりませんが、Windows 7の多くの設定が隠されており、ほとんどの使用設定に焦点が当てられています。画像を変更するワークフローを例に取り、そこから作業を進めます。
これらのナビゲーション要素は出発点です!