サービスの画面が変わったとき、利用者はどこで理由を確認すればよいだろうか。例えば見慣れた一覧の形が変わっても、新しい設定なのか一時的な不具合なのかはすぐには分からない。機能を公開した後も、その目的や使える範囲を説明する場所が必要になる。

9月2日に公開したMusecat Betaでは、検索、地域フィルター、一覧の表示設定を変更した。この内容をサービス内の更新文書へまとめ、ホームから開けるようにした。

サービスの変更を説明する投稿

外部コミュニティへ告知すれば、そのコミュニティを読む人には伝えられる。しかし店舗を探すためにサイトを訪れた人が、同じ投稿を見るとは限らない。ホームの短い案内だけでは、適用範囲や準備中の内容まで説明しにくい。

そこで一回の発表を、独立したアドレスを持つ投稿として扱うことにした。最初は要約を読み、必要なときに本文を開いたり、同じアドレスを他の人へ送ったりできる形である。

投稿の要約と本文

投稿にはタイトル、短い説明、本文、画像をまとめ、お知らせか更新案内かという種類も保存する。タイトルと説明は一覧で読む記事を選ぶために使い、本文で背景と変更内容を詳しく説明する。

ホームと詳細へ別々に説明を書くと、修正時に片方だけが古くなることがある。同じ投稿から要約と本文を取得すれば、その重複を減らせる。店舗情報の編集とは別の閲覧機能として用意した。

flowchart TD
    accTitle: 公式投稿と二つの閲覧画面
    accDescr: 運営者が発行した投稿のタイトルと説明は要約に、本文と画像は同じ投稿の詳細画面に使う。
    A[運営者の投稿] --> B[タイトルと短い説明]
    A --> C[本文と画像]
    B --> D[ホームのお知らせ要約]
    C --> E[投稿の詳細]
    D -->|投稿IDで移動| E

ホームから詳細文書への取得

ホームは最近の投稿のID、種類、タイトル、説明、作成時刻を取得し、作成時刻順で表示する。IDは一つの投稿を識別する値で、要約から同じ詳細文書を開くときに使う。一覧で全本文をダウンロードせずに、読む記事を選べる。

詳細画面はアドレスのIDで一件を取得し、本文と画像を表示する。画像は保存したファイルか指定したアドレスから読み込む。タイトルと説明はブラウザーのタイトルや共有メタデータにも利用する。リンクを受け取った人も、何の変更に関する案内か確認して同じ内容を読める。

2023-12-25のBetaコードによる再現と、合成のサンプル告知。当時の文書コンポーネントと同梱の表紙画像を使用した。 韓国語の原画面。当時のBetaは韓国語のみ対応。

sequenceDiagram
    accTitle: 要約から公式案内の本文へ
    accDescr: ホームは投稿の要約を取得する。利用者が選ぶと、そのIDで本文を読み、タイトル・説明・内容を表示する。
    participant U as 利用者
    participant W as Web画面
    participant D as 投稿ストレージ
    W->>D: お知らせと更新の要約を取得
    D-->>W: ID・タイトル・説明・作成日時
    U->>W: 投稿を選択
    W->>D: 選択したIDの投稿を取得
    D-->>W: 本文と画像
    W-->>U: 公式案内の文書

更新文書の活用と管理

Betaの発表には検索、フィルター、一覧設定の変更と、今後の改善予定を一緒に書いた。利用者には現在使える機能と準備中の内容を区別して伝える必要があるため、文書を書く際にもその違いを明確にする。

ホームの要約は全発表を表示したり、利用者の既読を確認したりする機能ではない。共有アドレスとともに同じ詳細へつなぎ、必要なときに案内へ戻れる経路を用意した。公開した本文、画像、リンクを維持する仕事は残る。

同じBeta原本の本文画面。タイトル・要約・HTML本文を分けて表示しており、告知内容は撮影用サンプルである。 韓国語の原画面。当時のBetaは韓国語のみ対応。

flowchart LR
    accTitle: 一つの発表を複数の経路から読む
    accDescr: ホームの要約と共有URLが同じ投稿の本文につながり、説明を複製せず再利用する。
    H[ホームの要約] --> P[同じ投稿の本文]
    L[共有したURL] --> P
    P --> R[変更内容と準備中の内容を確認]

関連発表：Musecat Betaアップデート

関連アップデート

• Musecat δ6 アップデート