アーカイブで掘り下げられる疑問を選ぶ
ここでの設計例は仮想のものです。歩くルートを決めた人が、通信の安定しない場所で使うスマートフォンを準備しているとします。事前に何をダウンロードすべきか、端末のどの前提を確認すべきか、選んだソフトウェアについて何を調べるべきか。オフライン地図をめぐる過去の議論を読みたい状況です。アーカイブは過去の議論の情報源であり、地図の提供元ではありません。
閲覧機能は、曲がる場所を逐次案内する画面ではなく、準備メモのそばに置きます。ルートの横に表示されたからといって、検索結果を確認済みの登山道情報にしてはいけません。地図のダウンロード、位置情報の許可、現在の通行止め、安全情報は、それぞれアプリ内の適切な場所で扱ってください。過去の体験談にない権威を持たせず、役立つ役割を与えるための分離です。
意図を持って小さなリクエストを1回送る
クエリをoffline maps、subredditをhikingとする案から始めます。クライアントはその選択をバックエンドへ送り、バックエンドは保存済みサービスキーを使って/v1/search?q=offline%20maps&subreddit=hiking&limit=3&page=1を呼び出せます。これはリクエストの設計であり、一致する3件のレコードが存在する証拠ではありません。キーはバックエンドに置き、利用者の入力には含めません。
最初のページを小さくすると、大きなフィードを設計する前に、何を読むかを考えられます。qはtitleとtextを対象にAND検索を行うため、この語句は完全なフレーズ一致や意味検索を指示するものではありません。利用者が語句を変えたら、新しい検索だとアプリで説明し、ページ番号を最初から始めます。黙ってクエリを広げ、新しい結果を元の疑問への結果のように表示しないでください。
レコードをおすすめではなく参照資料として見せる
アーカイブが返すのは平坦なレコードです。カードには、存在する本文、出典コミュニティ、有効な作成日、利用できる出典リンクを表示できます。コメントにはタイトルや有用な背景がない場合もあります。タイトルや日付がなければ、作り足すのではなく取得できないと示してください。親識別子があるレコードを端末内でまとめれば一部を関連付けられますが、議論全体がそろったことにはなりません。
アーカイブのレコードはドキュメント順で返され、時系列でも関連度順でもスコア順でもありません。その制約に合うよう、画面を「最良の回答」ではなく「過去の参照資料」として設計します。利用者は異なる体験を比較し、出典があればたどれます。他人の環境についての短い記述を、この端末や旅で確認済みの手順に変えてはいけません。
役立つ結果より先に、役立たない結果を設計する
正常なリクエストでも、レコードが返らない場合があります。入力を残し、別の語句を試すなど、利用者が意図して変更できる操作を用意します。結果なしの画面が説明するのはそのレスポンスであり、その話題が誰にも議論されていない証拠ではありません。正常な取得リクエストは、結果が空でも1クレジットを消費します。自動検索を有効にする前に、運用担当者がこの費用を理解する必要があります。
失敗は別の状態です。疑問を保持し、適切な場合に再試行を選べるようにします。サービスキーやクレジットの問題は運用担当者が扱い、利用者には議論の検索を使えないことを簡潔に伝えます。この閲覧の流れにアカウントの支払い操作を置いたり、遅延だけでアーカイブが停止したと判断したりしないでください。
読み終えたときに持ち帰るものも範囲を定める
pagination.has_moreが許す場合は、「さらに表示」でフィルターとlimitを保ったまま次のページを取得できます。あるいは、アプリが管理する端末内のリストに出典への参照を保存できます。どちらも、収録範囲の完全性、出典の恒久的な利用、会話全体のオフラインコピーを保証しません。参照先を保存しても、使える地図がダウンロードされるわけではありません。
役立つ到達点は、利用者が実際に使う地図ソフトウェアや最新の案内で確認するための、短い質問リストです。これは設計の意図であり、測定された効果ではありません。保存した参照先を再表示するときも、過去の資料だと分かる表示を保ってください。カードへの変換、資料の古さの表示、端末内の閲覧リストは/ja/#field-notesの各ノートを参照してください。
