リスト、検索、アイテムの表示アプリケーションに最適なページフローは何ですか？
次のシナリオを検討してください。
Androidアプリケーションの3つの画面：アイテムのリスト、検索結果画面、およびアイテムの表示画面があります。すべての画面で検索バーを呼び出すことができます。検索バーは、オートコンプリートで完全一致が見つかった場合は、検索結果画面または直接アイテム画面に移動します。
さて、質問は、画面間のフローをどのように編成する必要があるかです単純なフローは簡単です：リスト>検索>結果>表示。どちらかの状態で[戻る]ボタンをクリックすると、1つのアイテムがスタックの下に移動します。
ただし、検索がショー画面から呼び出された場合？スタックはlist> search> results> show> search> resultsになります。そして、検索結果と画面の表示が非常に多くなる可能性があります。
検索バーを呼び出して検索を実行するたびに、表示画面がスタックから削除され、スタックが単純なものよりも複雑にならないようにフローを作成することを検討していますリスト>検索>結果>表示。
質問の核心は、ユーザーがショー画面から検索バーを呼び出すのが精神的に「検索に戻る」か「次の検索に移動する」か、したがって最初のショー画面がアクセス可能かどうか。
AndroidのIMDbアプリは後者のアプローチに従い、数十の画面のスタックを簡単に構築します。私は個人的にこれに興奮していません。
それは、アプリの使用状況やコンテンツの種類によって異なると思います。
電車での旅の計画に使用するアプリは、検索が開始されるとリセットされる単純なスタックを使用しています。新しい検索を開始したため、以前の検索結果が失われることがよくあります。この場合、リセットしない大きなスタックが推奨されます。
アプリが非常に単純な使用シナリオを特徴としている場合、または相互に大きな関係がないアイテムのコレクションである場合、長くて複雑なスタックがあると混乱する可能性があります。
うーん、私はこれを3画面シナリオと見なします。
- 探す
- リスト/結果
- 項目
リストは実際には単なるプリセット検索です... SELECT * from TABLE
検索>結果>アイテム
追加のダイレクトパスを使用
検索>アイテム（完全一致の場合）