Release notes для мобильных приложений: что режет лимит

Всё в этом хабе о написании release notes предполагает страницу, которую вы полностью контролируете: любая длина, работающие ссылки, отображаемое форматирование. Release notes мобильного приложения живут в чужой коробке. Apple даёт примерно 4000 символов, но показывает только первые строки, пока не нажато «ещё»; Google даёт похожий объём с той же эффективной проблемой предпросмотра, и ни одна из платформ не отображает кликабельную ссылку в тексте. Правила из как писать release notes, которые люди реально читают всё ещё действуют: сказать, что изменилось, и что должен сделать читатель, но места для этого — доля того, что позволяет страница changelog, и урезания должны быть намеренными, а не случайными.

Что реально помещается в видимый предпросмотр?

Первые одна-две строки, примерно 80-170 символов в зависимости от устройства и размера шрифта, прежде чем читателю придётся нажать, чтобы развернуть. Это весь бюджет для той части release note, которая решает, будет ли кто-то читать остальное, и это значит, что самое важное предложение должно идти первым — не номер версии, не приветствие, не заголовок категории. Release note, начинающаяся с «Новое в этой версии:», уже потратила треть видимого пространства на четыре слова, которые ничего не говорят читателю.

Работает ли правило «что можно сделать сейчас, что вам обязаны» на этой длине?

Да, и оно становится строже, а не иным. Одно предложение на запись, глагол первым, без вступления: «Экспортируйте данные как CSV из Настроек.» побеждает «Мы добавили возможность для пользователей теперь экспортировать свои данные в формате CSV», используя треть слов, чтобы сказать то же самое. На длине страницы changelog чуть многословное предложение стоит читателю полсекунды. На длине мобильной release note та же многословность может вытолкнуть предложение целиком за пределы видимого предпросмотра, так что читатель никогда не увидит глагол, который сказал бы, что изменилось.

Плохо, тратит предпросмотр на обрамление:
«Мы рады представить вам новое обновление, полное
улучшений! Читайте дальше для подробностей».

Хорошо, вся ценность в первой строке:
«Экспортируйте данные как CSV. Тёмная тема теперь
следует системной настройке. Исправлен сбой при
открытии общих ссылок».

Что нужно урезать из того, что обычно сохранила бы запись веб-changelog?

Ссылки, во-первых, потому что ни один из двух магазинов не делает их кликабельными, так что URL в тексте — мёртвый груз, который читателю пришлось бы перепечатывать. Если записи нужен пункт назначения, скажите вместо этого, что нажать в приложении: «Смотрите новые фильтры в Настройках > Поиск» работает; «Подробнее на example.com/blog/filters» — нет, на этой поверхности. Во-вторых, всё условное или специфичное для аудитории: веб-changelog может сказать «если вы используете API, это вас касается», но листинг магазина достигает каждого установившего приложение пользователя одновременно, так что условная строка читается как шум для тех 95%, к кому она не относится. Поместите условную деталь вместо этого во внутриприложенческое сообщение, срабатывающее для аккаунтов, которых это реально касается.

Должен ли каждый релиз получать свои заметки, или нормально переиспользовать «исправления ошибок и улучшения производительности»?

Переиспользуйте это для релизов, которые действительно таковы, но проверяйте, насколько часто это на самом деле правда. Как писать release notes уже разбирает, почему эта фраза выдаёт заметку, написанную изнутри, а не для читателя; на мобильных устройствах это наносит двойной вред, потому что release notes магазина — одно из немногих мест, где некоторые пользователи вообще что-то видят между обновлениями, и длинная серия «исправлений ошибок и улучшений производительности» читается так, будто приложение не меняется, что производит худшее впечатление, чем отсутствие заметок вовсе за этот период.

Влияют ли release notes на то, обновляют ли люди приложение вообще?

Косвенно, через видимость, а не убеждение. Большинство пользователей обновляются автоматически и никогда не читают заметки перед обновлением; заметки важнее всего для меньшинства, которое проверяет обновления вручную, и для рецензентов или прессы, просматривающих историю листинга магазина. Писать для этой меньшей аудитории всё равно окупается, потому что листинг с реальной историей конкретных, датированных записей читается как активно поддерживаемое приложение, а листинг с годом «исправлений ошибок и улучшений производительности» — нет, независимо от того, сколько реально было выпущено за это время.

А как насчёт принудительного обновления, где заметка должна объяснить, почему у пользователя нет выбора?

Укажите причину и срок в первой строке, прежде всего остального, потому что принудительное обновление — единственный случай, когда читатель уже раздражён до того, как начал читать. «Это обновление необходимо для продолжения синхронизации ваших данных. Обновите до [дата], чтобы избежать перебоев» говорит, что делать и почему, в одном предложении; похоронить эту причину под тремя строками несвязанных заметок о функциях читается так, будто приложение прячет неудобную часть.

FAQ

Должны ли мобильные release notes совпадать с веб-changelog того же релиза? Покрывать те же лежащие в основе изменения, но не слово в слово. Веб-changelog может позволить себе полное объяснение; мобильной заметке нужны те же факты, сжатые в предложение с глаголом первым, что обычно означает переписывание, а не копирование.

Стоит ли локализовать мобильные release notes для каждого поддерживаемого языка? Да, больше, чем для веб-changelog, потому что листинг магазина часто единственная локализованная поверхность, которую некоторые пользователи видят между сессиями, и обе платформы поддерживают release notes по локали без дополнительной инженерной работы сверх самого перевода.

Какой длины должна быть мобильная release note, если нет лимита, вынуждающего к краткости? Всё равно короткой. Потолок в 4000 символов на iOS редко бывает реальным ограничением; им является предпросмотр в 2-3 строки, и писать дальше того, что показывает этот предпросмотр, просто значит, что меньше людей прочитают ту часть, которая имела значение.

Нужен ли release notes номер версии в видимом тексте? Нет. Магазин уже показывает номер версии рядом с заметками. Повторение его в тексте тратит видимые символы на информацию, которая у читателя уже перед глазами.

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Шаблон релиз-нот, Примеры changelog