Note de lansare pentru aplicații mobile: ce taie limita

Tot ce spune acest hub despre scrierea notelor de lansare presupune o pagină pe care o controlezi complet: orice lungime, linkuri care funcționează, formatare care se randează. Notele de lansare ale unei aplicații mobile trăiesc în cutia altcuiva. Apple dă aproximativ 4.000 de caractere dar arată doar primele rânduri înainte de a fi atins “mai mult”; Google dă un spațiu similar cu aceeași problemă efectivă de previzualizare, și niciuna dintre platforme nu randează un link pe care se poate da clic în text. Regulile din cum se scriu note de lansare pe care oamenii chiar le citesc tot se aplică: spune ce s-a schimbat și ce trebuie să facă cititoarea, dar spațiul pentru asta e o fracțiune din ce permite o pagină de changelog, iar tăierile trebuie să fie deliberate, nu accidentale.

Ce încape de fapt în previzualizarea vizibilă?

Primele unul până la două rânduri, aproximativ 80 până la 170 de caractere în funcție de dispozitiv și dimensiunea fontului, înainte ca cititoarea să trebuiască să atingă pentru a extinde. Acesta e tot bugetul pentru partea din nota de lansare care decide dacă cineva va citi restul, și înseamnă că cea mai importantă propoziție trebuie să vină prima, nu numărul versiunii, nu un salut, nu un titlu de categorie. O notă de lansare care începe cu “Noutăți în această versiune:” a cheltuit deja o treime din spațiul ei vizibil pe patru cuvinte care nu-i spun nimic cititoarei.

Regula “ce poți face acum, ce ți se datorează” tot funcționează la această lungime?

Da, și devine mai strictă, nu diferită. O propoziție pe intrare, verbul primul, fără introducere: “Exportă-ți datele ca CSV din Setări.” bate “Am adăugat posibilitatea ca utilizatorii să poată acum exporta datele lor în format CSV” folosind o treime din cuvinte pentru a spune același lucru. La lungimea unei pagini de changelog, o propoziție ceva mai vorbăreață o costă pe cititoare jumătate de secundă. La lungimea unei note de lansare mobile, aceeași vorbărie poate împinge propoziția întreagă în afara previzualizării vizibile, așa că cititoarea nu vede niciodată verbul care i-ar fi spus ce s-a schimbat.

Rău, irosește previzualizarea pe încadrare:
"Suntem încântați să-ți aducem o actualizare nouă
plină de îmbunătățiri! Continuă să citești pentru
detalii."

Bine, toată valoarea în primul rând:
"Exportă-ți datele ca CSV. Modul întunecat respectă
acum setarea sistemului. Am reparat o blocare la
deschiderea linkurilor partajate."

Ce trebuie tăiat din ce o intrare de changelog web ar păstra în mod normal?

Linkurile, mai întâi, pentru că niciunul dintre cele două magazine nu le randează ca fiind pe care se poate da clic, așa că un URL în text e greutate moartă pe care cititoarea ar trebui s-o retranscrie. Dacă intrarea are nevoie de o destinație, spune în schimb ce trebuie atins în aplicație: “Vezi noile filtre sub Setări > Căutare” funcționează; “Citește mai mult pe example.com/blog/filtre” nu funcționează pe această suprafață. În al doilea rând, orice e condiționat sau specific unui anumit public: un changelog web poate spune “dacă folosești API-ul, asta te privește”, dar o listare de magazin ajunge la fiecare utilizatoare instalată deodată, așa că un rând condiționat se citește ca zgomot pentru cele 95% cărora nu li se aplică. Pune detaliul condiționat într-un mesaj în aplicație în schimb, declanșat pentru conturile pe care le privește cu adevărat.

Fiecare lansare ar trebui să aibă propriile note, sau e în regulă să refolosești “corecții de erori și îmbunătățiri de performanță”?

Refolosește-l pentru lansările care sunt cu adevărat asta, dar auditează cât de des e chiar adevărat. Cum se scriu note de lansare acoperă deja de ce acea frază trădează o notă scrisă din interior în loc de pentru cititoare; pe mobil face un prejudiciu dublu, pentru că notele de lansare din magazin sunt unul dintre puținele locuri unde unele utilizatoare văd ceva între actualizări, iar un șir lung de “corecții de erori și îmbunătățiri de performanță” se citește de parcă aplicația nu s-ar schimba, ceea ce lasă o impresie mai proastă decât deloc note pentru acea perioadă.

Notele de lansare influențează dacă oamenii actualizează aplicația?

Indirect, prin vizibilitate mai degrabă decât prin persuasiune. Majoritatea utilizatoarelor actualizează automat și nu citesc niciodată notele înainte de a actualiza; notele contează cel mai mult pentru minoritatea care verifică actualizările manual, și pentru cele care recenzează sau pentru presă, care parcurg istoricul unei listări de magazin. Scrierea pentru acel public mai mic tot merită, pentru că o listare cu un istoric real de intrări specifice și datate se citește ca o aplicație întreținută activ, iar o listare cu un an de “corecții de erori și îmbunătățiri de performanță” nu, indiferent cât de mult s-a lansat cu adevărat în acea perioadă.

Dar o actualizare forțată, unde nota trebuie să explice de ce utilizatoarea n-are de ales?

Indică motivul și termenul limită în primul rând, înainte de orice altceva, pentru că o actualizare forțată e singurul caz în care cititoarea e deja deranjată înainte să înceapă să citească. “Această actualizare e necesară pentru a continua sincronizarea datelor tale. Actualizează până la [dată] pentru a evita o întrerupere.” spune ce trebuie făcut și de ce într-o singură propoziție; îngroparea acelui motiv sub trei rânduri de note despre funcționalități fără legătură se citește de parcă aplicația ar ascunde partea incomodă.

FAQ

Notele de lansare mobile ar trebui să corespundă changelog-ului web al aceleiași lansări? Să acopere aceleași schimbări de bază, dar nu cuvânt cu cuvânt. Changelog-ul web își poate permite explicația completă; nota mobilă are nevoie de aceleași fapte comprimate într-o propoziție cu verbul primul, ceea ce de obicei înseamnă că e o rescriere, nu o copie.

Merită să localizezi notele de lansare mobile pentru fiecare limbă suportată? Da, mai mult decât pentru un changelog web, pentru că listarea din magazin e adesea singura suprafață localizată pe care o văd unele utilizatoare între sesiuni, iar ambele platforme suportă note de lansare per limbă fără muncă de inginerie suplimentară dincolo de traducerea în sine.

Cât de lungă ar trebui să fie o notă de lansare mobilă dacă nu există o limită care să forțeze concizia? Scurtă oricum. Plafonul de 4.000 de caractere pe iOS e rareori constrângerea reală; previzualizarea de 2-3 rânduri e constrângerea, iar a scrie dincolo de ce arată acea previzualizare înseamnă doar că mai puțini oameni citesc partea care conta.

Notele de lansare au nevoie de numărul versiunii în textul vizibil? Nu. Magazinul arată deja numărul versiunii lângă note. Repetarea lui în text cheltuiește caractere vizibile pe informații pe care cititoarea le are deja în față.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Șablon note de lansare, Exemple de changelog