iOSアプリでタブバーナビゲーションとハンバーガーメニューを組み合わせるのは良い習慣ですか？
Googleの一部のiOSアプリと他のアプリ（StackExchange for iOSなど）は、タブバーとナビゲーションドロワー（別名ハンバーガーメニュー）の両方に基づく複合ナビゲーションモデルを使用しています。通常、タブバーはアプリの主要セクションへのナビゲーションを提供しますが、アクセス頻度の低い宛先（ヘルプや設定など）はナビゲーションドロワーからアクセスできます。
このアプローチについてどう思いますか？それは良い習慣ですか、それとも奇妙なハイブリッドですか？
このようなほとんどの質問と同様に、tl; drは依存します。
正しいナビゲーションパターンは、主に次の3つに依存します。
- アプリの構造（IA）
- リーフページ機能（IxD）
- 製品チームによる優先順位付けを実施したい（組織）
アプリの構造
アプリが5つ未満の第1層のリーフページをサポートできるように構造化されている場合は、タブ付きアプローチが最適です。コアユーザーフローに含まれていない追加のページがある場合、additionalメニューに追加の機能を含めることは理にかなっています。これらには以下が含まれます：
- アカウント情報（例：サインイン/ログアウト、ユーザーの追加など）
- アウトバウンドリンク（ヘルプ、フィードバック、バグレポートなど）
- 設定
- フォルダーとラベル
リーフページ機能
リーフページが互いに十分に区別されているが、階層と優先度が等しい場合、タブはナビゲーションのためのかなり確かなメカニズムです。この例は次のとおりです。
- ストリームタイプ（例：YouTubeのホーム、トレンド、定期購入、アカウント）
- ナビゲーションパターン（例：例ごとの参照）
- コンテンツタイプとインタラクションパターン（例：Googleマップの方向タイプ）
製品チームによる優先順位付けを強制したい
これはデザインの規律についてではなく、その実践についてです。製品チームには常に進化する要件があり、その結果、製品/サービスが肥大化し、焦点が合わなくなる可能性があります。固定数のコアユーザータスクを選択してタブに配置することで、設計チームは製品に抵抗し、 ジャンクドロワー ロングテール機能でいっぱいになり、チーム全体でより多くの設計と開発に費やすことができます。コア機能の時間。
その他の考慮事項
ソートまたはフィルタリングのメカニズムとしてユーザータブを使用しないようにしてください。 G +の例では：
ユーザーが上部と下部のタブを持っている状態があり、上部のタブは「コレクション」のコンテンツのフィルターとして機能します。 [おすすめ]、[フォロー中]、[あなたの]タブ内のコンテンツは同質です。これはタブの強力なアンチパターンです。はるかに優れたフィルタリングメカニズムがあります。
その他のリソース
ハンバーガーメニューの更新 -ハンバーガーメニューの使用法の進化
ハンバーガーアイコンをデザインした人 -アイコンの歴史
ハンバーガーメニューを避ける理由と方法 -実用的なガイド
お役に立てば幸いです。
タブナビゲーションとオフキャンバスメニューの中核機能をすでに強調しています。私がそのようなデザインで考えることができる唯一の欠点は、実際のコンテンツに利用できる画面領域です。ただ、携帯電話がどんどん大きくなっているので、これからは問題にならないと思います。
キャンバス外またはタブナビゲーションのどちらを実装するか、あるいはその両方を実装するかは、サイトのアーキテクチャと、達成したい目標に大きく依存します。より多くのユーザーを特定のページに誘導すること、または特定のアクションを実行することが目標である場合は、ユーザーが簡単にアクセスできる場所にリンクを配置することをお勧めします。タブバーは片手でナビゲートしてクリックできるので、当然そこにリンクを配置したいと思うでしょう。