Release notes per app mobile: cosa taglia il limite

Tutto in questo hub su come scrivere release notes presuppone una pagina che controlli completamente: qualsiasi lunghezza, link che funzionano, formattazione che si renderizza. Le release notes di un’app mobile vivono dentro la scatola di qualcun altro. Apple concede circa 4.000 caratteri ma mostra solo le prime righe prima che venga toccato “altro”; Google concede uno spazio simile con lo stesso problema effettivo di anteprima, e nessuna delle due piattaforme renderizza un link cliccabile dentro il testo. Le regole di come scrivere release notes che le persone leggono davvero valgono ancora: dire cosa è cambiato e cosa deve fare chi legge, ma lo spazio per farlo è una frazione di quello che consente una pagina di changelog, e i tagli devono essere deliberati, non accidentali.

Cosa entra davvero nell’anteprima visibile?

Le prime una o due righe, circa 80-170 caratteri a seconda del dispositivo e della dimensione del font, prima che chi legge debba toccare per espandere. Questo è l’intero budget per la parte della release note che decide se qualcuno leggerà il resto, e significa che la frase più importante deve venire per prima, non il numero di versione, non un saluto, non un’intestazione di categoria. Una release note che inizia con “Novità di questa versione:” ha già speso un terzo del suo spazio visibile in quattro parole che non dicono nulla a chi legge.

La regola “cosa puoi fare ora, cosa ti si deve” funziona ancora a questa lunghezza?

Sì, e diventa più rigida, non diversa. Una frase per voce, verbo per primo, senza premessa: “Esporta i tuoi dati come CSV da Impostazioni.” batte “Abbiamo aggiunto la possibilità per gli utenti di ora esportare i propri dati in formato CSV” usando un terzo delle parole per dire la stessa cosa. Alla lunghezza di una pagina di changelog, una frase un po’ prolissa costa a chi legge mezzo secondo. Alla lunghezza di una release note mobile, la stessa prolissità può spingere la frase interamente fuori dall’anteprima visibile, così chi legge non vede mai il verbo che avrebbe detto cosa è cambiato.

Male, spreca l'anteprima sulla cornice:
"Siamo entusiasti di portarti un nuovo aggiornamento
pieno di miglioramenti! Continua a leggere per i dettagli."

Bene, tutto il valore nella prima riga:
"Esporta i dati come CSV. La modalità scura ora rispetta
l'impostazione di sistema. Corretto un crash all'apertura
dei link condivisi."

Cosa deve essere tagliato che una voce di changelog web normalmente terrebbe?

I link, per primi, perché nessuno dei due store li renderizza cliccabili, quindi un URL nel testo è peso morto che chi legge dovrebbe ridigitare. Se la voce ha bisogno di una destinazione, di’ invece cosa toccare nell’app: “Vedi i nuovi filtri sotto Impostazioni > Ricerca” funziona; “Leggi di più su example.com/blog/filtri” no, su questa superficie. Secondo, qualsiasi cosa condizionale o specifica per un pubblico: un changelog web può dire “se usi l’API, questo ti riguarda”, ma un elenco di store raggiunge ogni utente installato contemporaneamente, quindi una riga condizionale si legge come rumore per il 95% a cui non si applica. Metti il dettaglio condizionale in un messaggio in-app invece, attivato per gli account che riguarda davvero.

Ogni rilascio dovrebbe avere le proprie note, o va bene riutilizzare “correzioni di bug e miglioramenti delle prestazioni”?

Riutilizzalo per i rilasci che sono genuinamente questo, ma verifica quanto spesso è davvero vero. Come scrivere release notes copre già perché quella frase tradisce una nota scritta dall’interno invece che per chi legge; su mobile fa un danno doppio, perché le release notes dello store sono uno dei pochi posti dove alcuni utenti vedono qualcosa tra un aggiornamento e l’altro, e una lunga serie di “correzioni di bug e miglioramenti delle prestazioni” si legge come se l’app non cambiasse, il che è un’impressione peggiore di nessuna nota per quel periodo.

Le release notes influenzano se le persone aggiornano l’app?

Indirettamente, tramite la visibilità più che la persuasione. La maggior parte degli utenti aggiorna automaticamente e non legge mai le note prima di aggiornare; le note contano di più per la minoranza che controlla gli aggiornamenti manualmente, e per chi recensisce o fa stampa e scorre lo storico di un elenco di store. Scrivere per quel pubblico più piccolo comunque ripaga, perché un elenco con uno storico reale di voci specifiche e datate si legge come un’app mantenuta attivamente, e un elenco con un anno di “correzioni di bug e miglioramenti delle prestazioni” no, indipendentemente da quanto sia stato davvero rilasciato in quel periodo.

E un aggiornamento forzato, dove la nota deve spiegare perché l’utente non ha scelta?

Indica il motivo e la scadenza nella prima riga, prima di qualsiasi altra cosa, perché un aggiornamento forzato è l’unico caso in cui chi legge è già infastidito prima di iniziare a leggere. “Questo aggiornamento è necessario per continuare a sincronizzare i tuoi dati. Aggiorna entro il [data] per evitare interruzioni.” dice cosa fare e perché in una sola frase; seppellire quella motivazione sotto tre righe di note su funzionalità non correlate si legge come se l’app stesse nascondendo la parte scomoda.

FAQ

Le release notes mobile dovrebbero corrispondere al changelog web dello stesso rilascio? Coprire gli stessi cambiamenti sottostanti, ma non parola per parola. Il changelog web può permettersi la spiegazione completa; la nota mobile ha bisogno degli stessi fatti compressi in una frase con il verbo per primo, il che di solito significa che è una riscrittura, non una copia.

Vale la pena localizzare le release notes mobile per ogni lingua supportata? Sì, più che per un changelog web, perché l’elenco dello store è spesso l’unica superficie localizzata che alcuni utenti vedono tra una sessione e l’altra, ed entrambe le piattaforme supportano release notes per locale senza lavoro ingegneristico aggiuntivo oltre alla traduzione stessa.

Quanto dovrebbe essere lunga una release note mobile se non c’è un limite che forza la brevità? Corta comunque. Il tetto di 4.000 caratteri su iOS è raramente il vincolo reale; lo è l’anteprima di 2-3 righe, e scrivere oltre quello che quell’anteprima mostra significa solo che meno persone leggono la parte che contava.

Le release notes hanno bisogno del numero di versione nel testo visibile? No. Lo store mostra già il numero di versione accanto alle note. Ripeterlo dentro il testo spende caratteri visibili per informazioni che chi legge ha già davanti.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Modello di release notes, Esempi di changelog