Во втором случае текста намного больше, что как бы нехорошо. Но есть как минимум два аргумента в пользу такого варианта: в нём говорится о конкретных ошибках и он приглашает пользователей к диалогу, сообщает им о том, что разработчики тоже живые люди и понимают человеческую речь. А ещё второй вариант обещает пользователям не больше того, что действительно сделали разработчики. Он сообщает о конкретной правке и ещё нескольких менее значимых. А если осталось что-то ещё – пишите, вот почта.
Идём дальше. Если в приложении появилось что-то полезное, не только исчезли ошибки, то при первом запуске сразу после обновления вы можете показать пользователям экран с рассказом о новинках. Или два, три экрана – насколько у вас хватит фантазии, а у пользователей – терпения:
Ладно, вот вы рассказали обо всех нововведениях. Или люди нажали на крестик в углу первого же сообщения и поспешили перейти к обычным сценариям использования приложения. Но вдруг что-то пошло не по сценарию и в приложении появилось сообщение об ошибке. Допустим, вы в любом случае увидите код ошибки в логах и поймёте её суть. А пользователю решили ничего не объяснять, для него написали максимально коротко и по делу:
Вроде ясно, что что-то пошло не так. Но непонятно, что именно, как исправить ситуацию, чтобы не увидеть это сообщение в следующий раз. Снова появляется работа для писателя. Он может пообщаться с командой, выяснить, допустим, что ошибка происходит из-за добавления слишком большого числа людей в получатели, и сообщить пользователю об ошибке примерно так:
Уже лучше. Человек понимает, как он может всё исправить прямо сейчас – хотя бы попытаться уменьшить число получателей. Но снова он остаётся отчасти в неведении. Пользователь не знает, что именно надо делать, чтобы больше не попадать в такие ситуации. Вынужден гадать с числами. И опять имеет лишь унылую кнопку тихого согласия с происходящим – «окей». Часто подобные ситуации можно улучшить, подсказав, что именно можно сделать сейчас и как поступать вообще. Писатель снова идёт общаться с разработчиками и выясняет новые подробности. Так у него получается лучшее сообщение, какое продукт может показать в этой ситуации:
Вот теперь наверняка ясно, что именно произошло и что делать, чтобы подобные сообщения больше не показывались.
Ещё раз взглянем на варианты. Первый, самый короткий, часто даже не пишут, а накидывают из-за отсутствия времени «на такие мелочи». Это скорее дежурная заглушка, которую иногда забывают заменить на что-то осмысленное, – так и уходит в релиз. Без обид и претензий – вариант разработчиков.
Второй вариант может написать копирайтер, которому как-то формулируют задачу – просят рассказать о том, что произошло. Такой текст пишется перед выпуском продукта, когда кто-то внезапно вспоминает: «Ой, у нас же там заглушка!»
Третий