私はAndroid用の10tracksアプリケーションの再設計に携わっており、Facebookなどの兄たちの美しいインターフェイスの動きを借りることにしました。 このテーマに関する良い記事がありましたが、その翻訳を急いで共有します。 一方、この記事は、不可侵の確立されたルールよりも議論のプラットフォームです。





過去1年間、Androidインターフェースは驚異的な速度で改善されています（Google+で気に入っているアプリケーションの小さなギャラリーを見つけました）。 多くの変更は表面的なものに過ぎません（ICSのホロテーマ、Robotoフォントなど）。 インターフェイス設計の原則に大きな質的変化は見られませんでした。 しかし、たぶんそのようなことの1つが今起こっています。



ほぼ同時に、いくつかのアプリケーションは、Facebookアプリケーションのように、それ自体に横方向のナビゲーションを導入しました。 まず、Spotifyの新しいデザインでどのように使用されるかを確認し、その後すぐに決定がEvernoteに採用されました。 1年も経たないうちに、Google +アプリケーションの新しいデザインが同様のパターンを導入しました。



これらのアプリケーションのそれぞれに異なる方法で横方向のナビゲーションを実装しました。 基本的には同じアプローチですが、見た目は異なり、使用する感覚は異なります。 アイデアは、現在の画面を離れることなく、アプリケーションの最も重要な領域に到達する最速の方法をユーザーに提供することです。



実装の視覚的な違いは明らかです。 たとえば、Google +アプリケーションではメニューが現在の画面上をスクロールしますが、他のアプリケーションでは現在の画面が横に移動します。 Google+は「上へ」アイコンを使用しますが、メニューが開いていてもアクションバーはそのままですが、他のアプリケーションではそうではありません。



このパターンについて少し前に行われた興味深い議論は、Google +の著者のブログで読むことができます。 ディスカッションへのリンク （英語）

ダッシュボードが死んだ

サイドナビゲーションは、アプリケーションで非常に批判されているダッシュボードパターンを置き換えます。 ダッシュボードを批判する際の主な論点は、アプリケーション自体のコンテンツへの途中でユーザーのアクションを遅くすることでした。 アプリケーションを起動するたびに、最初にアイコンをクリックして、移動先を選択する必要があります 。



ダッシュボードでは、アプリケーションの別の部分に切り替える場合は、メイン画面に戻る必要もあります。 これは、標準のAndroidアプリケーションの抽象的なスケッチです。ダッシュボードと、アプリケーションの1つのセクションがあります。これは、要素のリストです。 リストの要素をクリックすると、この要素の詳細画面が表示されます（モバイルアプリケーションの一般的な構造）。 この例では、ユーザーは最初にダッシュボードからアイテムを選択し、次にリストからアイテムを1つ選択してアイテム自体に移動し、次のアイテムに移動します。



この例は、アプリケーションがダッシュボードの固有の原理で構築されている場合、アプリケーションのセクション間を移動することの難しさを示しています。







横方向のナビゲーションは両方の問題を解決します。 ユーザーは、最初にホーム画面に戻ることなく、アプリケーションの任意のセクションに直接移動できます。 同時に、アプリケーションが起動すると、メイン画面の1つが開き、コンテンツがすぐに利用可能になります。



次のスケッチは同じアプリケーションの例ですが、サイドナビゲーションの原理に基づいています。 まず、アプリケーションの最初の画面にコンテンツが表示され、次にユーザーはどの画面からでもアプリケーションの他の部分に直接アクセスできます。







サイドナビゲーションの概念は、古いダッシュボードの原則を超えると確信しています。 ダッシュボードを適用できる場合もありますが、そのような状況ははるかに少なくなります。 まれに、コンテンツ画面をすぐに表示できない場合があります。 ダッシュボードは引き続き優れたソリューションです。 また、非常に複雑なアプリケーションでは、一度にすべてをダンプしないように、初めてユーザーに無害なシンプルなダッシュボードを表示できます。



おそらく、デザインパターンに別れを告げる時が来たのかもしれません。デザインパターンは、それほど昔ではない認識可能なAndroidシンボルでした。

休憩後もう少し......

サイドナビゲーションの問題

残念ながら、横方向のナビゲーションを正しく実装することは、いくつかの困難のためにダッシュボードの概念よりもはるかに困難です。

上？

Androidのアップボタンコンセプトのファンになったことはありません。 ユーザーは、アップトランジションとバックトランジションの違いを理解できないと思います。 さらに、Googleは、「アップ」アクションが左矢印で示されるという事実により、これを「支援」することを決定しました。 私が話をした各ユーザーは、このアップボタンを戻るボタンと呼びます。



私の意見では、サイドナビゲーションを使用すると、[上へ]ボタンは廃止され不要になります。 アプリケーションの構造が適切な場合、どこからでも横方向のナビゲーションを使用して、アプリケーションのメイン画面に簡単にアクセスできます。ユーザーは、画面から数回クリックするだけで自分を見つけることができません。 スマートフォンの戻るボタンは、他のほとんどのナビゲーションニーズを処理します。



ここでGoogle+アプリケーションとサイドナビゲーションの仕組みを見ると、サイドナビゲーションにアクセスするには、まずカテゴリ画面の1つに移動する必要があることがわかります。 これはその意味を消すと思います。 たとえば、あるニュースを読んでいて、突然ビデオ会議を開始したい場合、ハングアウトにアクセスするためにニュースフィードから出る必要があるのはなぜですか？



代わりに、 どの画面を表示していても 、アクションバーの左上のボタンがサイドナビゲーションを開いているのを見ると、もっと嬉しいです 。



サイドナビゲーションと一緒に上ボタンを使用することにした場合、サイドナビゲーションを開くホームボタンが、上矢印として機能するホームボタンと同じに見えないことを確認する必要があります。 同じ外観のボタンを使用すると、インターフェース設計の基本原則に違反します。インターフェースでボタンが実行するアクションを常に明確にする必要があります。 上ボタン（何をしているのかが必ずしも明確ではない）が突然2つの異なる機能を実行し、ユーザーはボタンを押さずに特定の瞬間にどちらを実行するかを言うことができません。



オペレーティングシステムの一部としてサイドナビゲーション用の別のアイコンが必要だと思います。これにより、コンセプトに一貫性が追加されます。 ここに私が意味することの大まかなスケッチがあります。 最初の画像は、上方向の機能がある場合のホームボタンの外観を示しています（これが現在の外観です）。 2番目の図は、サイドメニューを開く機能がある場合の外観のスケッチです。 これにより、ユーザーはアップナビゲーションとサイドナビゲーションの両方を使用するアプリケーションで混乱することがなくなります。

バックスタックの問題

リターンスタックを適切に管理することは非常に重要です。 横方向のナビゲーションは、逆スタックを複雑にする可能性があります。 アレクサンダー・ブロムはこれについていくつかの良い投稿を書いた。 ご覧になることをお勧めします：

AndroidナビゲーションとSpotify（友達と）

スライドアウトナビゲーションの改善

（英語）

サイドナビゲーションを開くものは何ですか？

ユーザーはどのようにしてサイドナビゲーションを開くことができますか？ 使用するジェスチャとボタンは何ですか？



横方向のナビゲーションは、おそらく、それを使用することを決定したアプリケーションで最も重要なコンポーネントです。 ユーザーは、アプリケーションを開く方法を知らない限り、アプリケーションのどこにも移動できません。



このパターンを使用するすべてのアプリケーションを試してみたところ、どれも完全に実装していないことに気付きました。 みんなに近づくと、 Prix​​ingアプリが理想的になりました。 このアプリケーションは、トランジションの概念を投げかけ、アプリケーションのホームボタンがサイドナビゲーションのみを開くようにしました。



このアプリは、このメニューを開くためのジェスチャー認識も追加しました。 ユーザーは「画面の端からスワイプ」（ベゼルスワイプ）してメニューを開くことができます。 ユーザーは、このジェスチャがサイドメニューを開くことに必ずしも気付かないが、それを開くホームボタンがあるため、これは問題ではありません。 （ ベゼルスワイプに関する英語の著者の記事）。



このアプリケーションの改善点は1つだけです。アイコンはホームボタンとして使用されますが、ボタンにサイドナビゲーションを開く機能があることを示す追加の指定を追加する価値があるかもしれません。



他のアプリケーションは、サイドメニューを開くために異なる方法を使用します。 たとえば、Evernoteはインターフェイスで通常のスワイプを使用します。 これにより、タブ間を移動するときにスワイプが既に使用されているため、インターフェイスシーケンスの問題が発生します。 EvernoteはUIの一部の場所でタブを使用しているため、左端のタブを使用しない限り、横方向のナビゲーションはスワイプで開くことができません。



サイドナビゲーションを開くための私の推奨事項は、常にホームボタンから開き、端からスワイプすることです。 トランジションを使用する場合-機能がアップしているボタンとメニューを開いているボタンのアイコンが異なることを確認してください。

サイドナビゲーションのアクション

その前に、私はナビゲーションについて話していましたが、パターンの多くの用途はナビゲーションだけの境界を超えています。 私には理にかなっているようです。 アクションバーは、画面上のコンテキストアクションが配置されている場所です。 しかし、アプリケーションに、どの画面からでもアクセスできるほど重要なアクションがある場合はどうでしょうか？



Evernoteは、サイドメニューにアクションを配置することでこの問題を解決しました。 彼らの解決策は素晴らしいと思います。 初めての使用では少し過負荷に見えるかもしれませんが、ナビゲーション要素とアクションを明確に視覚的に分離することで、ユーザーは、ナビゲーションの場所とアクションの場所のモデルを頭の中で簡単に作成できます。

あなたはそれを何と呼びますか？

パターンに記述的かつ連続的に名前を付けることが非常に重要です。 パターンの利点の1つは、名前で参照するだけで、ディスカッションで簡単に使用できることです。 確立されたパターンの場合、これ以上の説明は不要です。 「インターフェイスでアクションバーを使用する必要がありますか？」または「クイックアクションのリストはどうですか？」



それでは、このパターンの名前は何ですか？ この投稿では「サイドナビゲーション」と呼びましたが、他にも多くのオプションがあります。

• サイドナビゲーション
• フライインアプリメニュー
• ナビゲーションのスライドアウト
• スライドナビゲーションバー
• スライドメニュー
• ...

Googleがパターンに名前を付けるのを待ってから、名前の1つが落ち着きます。 ここでは民主主義は役に立たないでしょう。 今のところ、私はこれをラテラルナビゲーションと呼びますが、他の名前を受け入れる準備ができています。

技術的解決策

横方向のナビゲーション（現時点では）は、Android SDKには含まれていません。 githubをすばやく検索すると、このパターンを適用した1つのプロジェクトが生成されます。

githubでのandroid-fb-like-slideout-navigation

これが彼の作品を示すビデオです。



別のプロジェクトを次に示します。

https://github.com/darvds/RibbonMenu



そして、さらに2つあります。

https://bitbucket.org/jfeinstein10/slidingmenu/overview

https://github.com/Gregadeaux/android-fly-in-app-navigation



Cyril Mottierは、このパターンの紹介についても彼のブログ（英語）で書いています。 これらの投稿は読む価値があります：

Prix​​ingの作成＃1：フライインアプリメニュー

Prix​​ingの作成＃2：フライインアプリメニューのスワイプ

Prix​​ingの作成＃3：スライドアプリメニューの洗練

未来

これは、Androidインターフェースの設計における大きな前進だと思います。 同じように見えるさまざまな実装方法の制御されていない動物園を作成しないように、しかし、ユーザーを混乱させるために異なる動作をするように、非常に注意する必要があります。



Google I | Oはもうすぐです（2012年6月にこの記事を書いている時点ではもうすぐです） 。 彼らがAndroidの次のバージョンをどのように発表するか見るかもしれません。 Googleが（ICS / Honeycombのアクションバーで行ったように）OSのより複雑なコンポーネントを引き続き宣伝してくれることを願っています。 また、サイドナビゲーションコンポーネントが新しいリリースの一部として表示され、このパターンの適用に一貫性がもたらされることを期待しています。

おわりに

私はラテラルナビゲーションコンセプトのファンです。 ただし、誤ってアプローチするのは非常に簡単です。 アプリケーションに含める場合は、起こりうる問題に注意してください。 バックスタック、ジェスチャ、アップトランジションとの相互作用、およびその外観を慎重に設計します。