モバイルアプリのリリースノート：文字数制限が何を削るのか

このハブでリリースノートの書き方について語られてきたことはすべて、完全にコントロールできるページを前提としている。任意の長さ、機能するリンク、レンダリングされる書式だ。モバイルアプリのリリースノートは他人の箱の中で生きている。Appleは約4,000文字を与えるが、「もっと見る」がタップされる前には最初の数行しか表示しない。Googleも同様のプレビュー問題を抱えた似た余白を与え、どちらのプラットフォームもテキスト内にクリック可能なリンクをレンダリングしない。実際に読まれるリリースノートの書き方にあるルール、何が変わったか、読者は何をすべきかを伝えるというルールは依然として当てはまるが、それをするための空間はchangelogのページが許すものの一部に過ぎず、削減は偶然ではなく意図的でなければならない。

目に見えるプレビューには実際に何が収まるのか

デバイスとフォントサイズによって異なるが、およそ80から170文字ほどの最初の1、2行だ。それは読者が展開のためにタップするより前の話だ。それがリリースノートの中で誰かが残りを読むかどうかを決める部分の全予算であり、つまり最も重要な一文が最初に来なければならないということだ。バージョン番号でも、挨拶でも、カテゴリの見出しでもない。「このバージョンの新機能:」で始まるリリースノートは、読者に何も伝えない四つの単語に、目に見える空間の三分の一をすでに使ってしまっている。

「今何ができるか、何が約束されているか」というルールはこの長さでもまだ機能するのか

機能する。そして異なる形にではなく、より厳格になる。項目ごとに一文、動詞を先に、前置きなしで。「設定からCSVとしてデータをエクスポートできます。」は、「ユーザーが今後CSV形式でデータをエクスポートできる機能を追加しました」に、単語数の三分の一を使って同じことを言うことで勝つ。changelogページの長さでは、少し冗長な一文は読者に半秒のコストを課す。モバイルのリリースノートの長さでは、その同じ冗長さが一文全体を目に見えるプレビューの外に押し出してしまい、読者は何が変わったかを伝える動詞を一度も目にしないことになる。

悪い例、前置きにプレビューを浪費している:
「改善が詰まった新しいアップデートをお届けできて
嬉しいです！詳細は続きをお読みください。」

良い例、最初の行にすべての価値がある:
「データをCSVとしてエクスポートできます。ダーク
モードは今やシステム設定に従います。共有リンクを
開く際のクラッシュを修正しました。」

Webのchangelogの項目なら普通は残すものの、何を削らなければならないのか

まずリンクだ。どちらのストアもそれをクリック可能にはレンダリングしないので、テキスト内のURLは読者が打ち直さなければならない死重になる。項目に行き先が必要なら、代わりにアプリ内で何をタップすべきかを伝えよう。「設定 > 検索の下にある新しいフィルターを確認」は機能するが、「詳しくはexample.com/blog/filtersをご覧ください」はこの面では機能しない。次に、条件付きや特定の読者にしか関係のないものすべて。Webのchangelogなら「APIを使っているなら、これはあなたに関係します」と言えるが、ストアの掲載情報はインストール済みの全ユーザーに同時に届くので、条件付きの一行はそれが当てはまらない95%にとって雑音として読まれる。条件付きの詳細は代わりにアプリ内メッセージに入れ、実際に関係するアカウントに対してのみトリガーしよう。

すべてのリリースが独自のノートを持つべきか、それとも「バグ修正とパフォーマンスの改善」を使い回してよいのか

本当にそうであるリリースについては使い回してよいが、それが本当にどれだけ頻繁に真実かを監査しよう。リリースノートの書き方は、その言い回しが読者のためではなく内側から書かれたノートを露呈させる理由をすでに扱っている。モバイルでは二重の害を及ぼす。ストアのリリースノートは、一部のユーザーがアップデート間で何かを目にする数少ない場所の一つだからだ。長く続く「バグ修正とパフォーマンスの改善」の連なりは、アプリが変わっていないかのように読め、その期間まったくノートがないことよりも悪い印象を与える。

リリースノートは人々がアプリを更新するかどうかに影響するのか

説得というより可視性を通じて、間接的に影響する。ほとんどのユーザーは自動的に更新し、更新前にノートを読むことは決してない。ノートが最も重要なのは、手動でアップデートを確認する少数派、そしてストアの掲載履歴を見るレビュアーやプレスにとってだ。その小さな読者層のために書くことはそれでも報われる。具体的で日付の入った項目の本物の履歴を持つ掲載情報は、活発にメンテナンスされているアプリのように読める。一方、「バグ修正とパフォーマンスの改善」が一年続く掲載情報はそうは読めない。その期間に実際にどれだけ多くのものが出荷されたとしてもだ。

ユーザーに選択肢がない理由をノートが説明しなければならない強制アップデートはどうなのか

理由と期限を、他の何よりも先に最初の行に述べよう。強制アップデートは、読者が読み始める前からすでに苛立っている唯一のケースだからだ。「データの同期を続けるにはこのアップデートが必要です。中断を避けるために[日付]までに更新してください。」は、何をすべきか、なぜなのかを一文で伝える。その理由を関係のない機能ノート三行の下に埋めてしまうと、アプリが不都合な部分を隠しているかのように読める。

FAQ

モバイルのリリースノートは同じリリースのWebのchangelogと一致すべきか? 同じ根本的な変更をカバーすべきだが、一言一句同じである必要はない。Webのchangelogは完全な説明を許容できるが、モバイルのノートは動詞を先にした一文に圧縮された同じ事実を必要とする。それは通常、コピーではなく書き直しを意味する。

サポートしている言語ごとにモバイルのリリースノートをローカライズする価値はあるか? ある。Webのchangelogよりもさらにだ。ストアの掲載情報は、一部のユーザーがセッションの間に見る唯一のローカライズされた面であることが多く、両プラットフォームとも翻訳自体を超える追加のエンジニアリング作業なしにロケールごとのリリースノートをサポートしている。

簡潔さを強制する上限がない場合、モバイルのリリースノートはどれくらいの長さにすべきか? それでも短くすべきだ。iOSの4,000文字の上限が実際の制約になることはめったにない。制約になるのは2-3行のプレビューであり、そのプレビューが示すものを超えて書くことは、単に重要な部分を読む人が減ることを意味するだけだ。

リリースノートは目に見えるテキストにバージョン番号を必要とするか? 必要ない。ストアはすでにノートの隣にバージョン番号を表示している。それをテキスト内で繰り返すことは、読者がすでに目の前にしている情報のために目に見える文字を浪費することになる。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： リリースノートのテンプレート, changelogの例