Release notes para apps mobile: o que o limite corta

Tudo neste hub sobre escrever release notes assume uma página que você controla totalmente: qualquer tamanho, links que funcionam, formatação que renderiza. As release notes de um app mobile vivem dentro da caixa de outra empresa. A Apple dá cerca de 4.000 caracteres mas só mostra as primeiras linhas antes de “mais” ser tocado; o Google dá um espaço parecido com o mesmo problema efetivo de prévia, e nenhuma das duas plataformas renderiza um link clicável dentro do texto. As regras de como escrever release notes que as pessoas realmente leem ainda valem: diga o que mudou e o que a leitora precisa fazer, mas o espaço para isso é uma fração do que uma página de changelog permite, e os cortes precisam ser feitos de propósito, não por acidente.

O que realmente cabe na prévia visível?

As primeiras uma ou duas linhas, algo entre 80 e 170 caracteres dependendo do aparelho e do tamanho da fonte, antes de a leitora precisar tocar para expandir. Esse é todo o orçamento para a parte da release note que decide se alguém vai ler o resto, e isso significa que a frase mais importante precisa vir primeiro, não o número da versão, não uma saudação, não um título de categoria. Uma release note que começa com “Novidades desta versão:” já gastou um terço do seu espaço visível em quatro palavras que não dizem nada para a leitora.

A regra “o que você pode fazer agora, o que se deve a você” ainda funciona nesse tamanho?

Funciona, e fica mais rígida, não diferente. Uma frase por entrada, verbo primeiro, sem introdução: “Exporte seus dados como CSV em Configurações.” vence “Adicionamos a capacidade de os usuários agora poderem exportar seus dados em formato CSV” usando um terço das palavras para dizer a mesma coisa. No tamanho de uma página de changelog, uma frase um pouco mais prolixa custa meio segundo à leitora. No tamanho de uma release note mobile, essa mesma prolixidade pode empurrar a frase inteira para fora da prévia visível, então a leitora nunca vê o verbo que diria a ela o que mudou.

Ruim, desperdiça a prévia com enquadramento:
"Estamos animados em trazer uma nova atualização
cheia de melhorias! Continue lendo para os detalhes."

Bom, todo o valor na primeira linha:
"Exporte seus dados como CSV. O modo escuro agora
respeita a configuração do sistema. Corrigido um
travamento ao abrir links compartilhados."

O que precisa ser cortado do que uma entrada de changelog web normalmente manteria?

Links, primeiro, porque nenhuma das duas lojas os renderiza como clicáveis, então uma URL no texto é peso morto que a leitora teria que digitar de novo. Se a entrada precisa de um destino, diga em vez disso o que tocar no app: “Veja os novos filtros em Configurações > Busca” funciona; “Leia mais em example.com/blog/filtros” não funciona nessa superfície. Segundo, qualquer coisa condicional ou específica de um público: um changelog web pode dizer “se você usa a API, isso te afeta”, mas uma listagem de loja alcança cada usuária instalada ao mesmo tempo, então uma linha condicional soa como ruído para os 95% a quem não se aplica. Coloque o detalhe condicional em uma mensagem dentro do app em vez disso, disparada para as contas que ele realmente diz respeito.

Cada lançamento deveria ter suas próprias notas, ou tudo bem reutilizar “correções de bugs e melhorias de performance”?

Reutilize para lançamentos que genuinamente são isso, mas audite com que frequência isso é realmente verdade. Como escrever release notes já cobre por que essa frase entrega uma nota escrita de dentro em vez de para a leitora; no mobile isso faz um dano duplo, porque as release notes da loja são um dos poucos lugares onde algumas usuárias veem qualquer coisa entre atualizações, e uma longa sequência de “correções de bugs e melhorias de performance” soa como se o app não estivesse mudando, o que causa uma impressão pior do que nenhuma nota naquele período.

As release notes influenciam se as pessoas atualizam o app?

Indiretamente, através de visibilidade em vez de persuasão. A maioria das usuárias atualiza automaticamente e nunca lê as notas antes de atualizar; as notas importam mais para a minoria que confere atualizações manualmente, e para quem faz resenhas ou imprensa que percorre o histórico de uma listagem de loja. Escrever para esse público menor ainda vale a pena, porque uma listagem com um histórico real de entradas específicas e datadas se lê como um app mantido ativamente, e uma listagem com um ano de “correções de bugs e melhorias de performance” não, não importa quanto tenha sido realmente lançado naquele período.

E uma atualização forçada, onde a nota precisa explicar por que a usuária não tem escolha?

Indique o motivo e o prazo na primeira linha, antes de qualquer outra coisa, porque uma atualização forçada é o único caso em que a leitora já está incomodada antes mesmo de começar a ler. “Esta atualização é necessária para continuar sincronizando seus dados. Atualize até [data] para evitar interrupção.” diz o que fazer e por quê em uma frase; enterrar esse motivo sob três linhas de notas de funcionalidades sem relação soa como se o app estivesse escondendo a parte inconveniente.

FAQ

As release notes mobile deveriam corresponder ao changelog web do mesmo lançamento? Cobrir as mesmas mudanças subjacentes, mas não palavra por palavra. O changelog web pode se dar ao luxo da explicação completa; a nota mobile precisa dos mesmos fatos comprimidos em uma frase com o verbo primeiro, o que geralmente significa que é uma reescrita, não uma cópia.

Vale a pena localizar as release notes mobile para cada idioma suportado? Vale, mais até do que para um changelog web, porque a listagem da loja é muitas vezes a única superfície localizada que algumas usuárias veem entre sessões, e as duas plataformas suportam release notes por idioma sem trabalho de engenharia adicional além da tradução em si.

Quanto tempo uma release note mobile deveria ter se não houver um limite forçando a brevidade? Curta de qualquer jeito. O teto de 4.000 caracteres no iOS raramente é a restrição real; a restrição é a prévia de 2-3 linhas, e escrever além do que essa prévia mostra só significa que menos pessoas leem a parte que importava.

As release notes precisam do número da versão no texto visível? Não. A loja já mostra o número da versão ao lado das notas. Repeti-lo dentro do texto gasta caracteres visíveis em informação que a leitora já tem na frente dela.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Modelo de notas de versão, Exemplos de changelog