Release notes pro mobilní aplikace: co usekne limit

Všechno v tomto hubu o psaní release notes předpokládá stránku, kterou plně kontrolujete: jakoukoli délku, fungující odkazy, formátování, které se vykreslí. Release notes mobilní aplikace žijí v cizí krabici. Apple dává zhruba 4 000 znaků, ale zobrazí jen první řádky, než se ťukne na „více”; Google dává podobný prostor se stejným efektivním problémem náhledu, a ani jedna platforma nevykresluje klikatelný odkaz v textu. Pravidla z jak psát release notes, které lidé skutečně čtou pořád platí: řekni, co se změnilo a co má čtenářka udělat, ale prostor na to je zlomek toho, co dovoluje stránka changelogu, a škrty musí být záměrné, ne nechtěné.

Co se do viditelného náhledu skutečně vejde?

První jeden až dva řádky, zhruba 80 až 170 znaků podle zařízení a velikosti písma, než čtenářka musí ťuknout, aby rozbalila víc. To je celý rozpočet pro tu část release note, která rozhoduje, jestli si někdo přečte zbytek, a znamená to, že nejdůležitější věta musí přijít první, ne číslo verze, ne pozdrav, ne nadpis kategorie. Release note, která začíná „Novinky v této verzi:”, už utratila třetinu svého viditelného prostoru za čtyři slova, která čtenářce nic neříkají.

Funguje pravidlo „co teď můžete dělat, co se vám dluží” na této délce pořád?

Ano, a stává se přísnějším, ne jiným. Jedna věta na záznam, sloveso první, bez úvodu: „Exportujte data jako CSV z Nastavení.” poráží „Přidali jsme možnost, aby uživatelky nyní mohly exportovat svá data ve formátu CSV” použitím třetiny slov k vyjádření stejné věci. Na délce stránky changelogu stojí trochu upovídaná věta čtenářku půl sekundy. Na délce mobilní release note může stejná upovídanost vytlačit celou větu mimo viditelný náhled, takže čtenářka nikdy neuvidí sloveso, které by jí řeklo, co se změnilo.

Špatně, plýtvá náhledem na rámování:
"Jsme nadšeni, že vám přinášíme novou aktualizaci
plnou vylepšení! Čtěte dál pro podrobnosti."

Dobře, celá hodnota v první řádce:
"Exportujte data jako CSV. Tmavý režim teď respektuje
systémové nastavení. Opravena chyba při otevírání
sdílených odkazů."

Co musí být useknuto, co by webový záznam changelogu normálně zachoval?

Odkazy, nejdřív, protože žádný ze dvou obchodů je nevykresluje jako klikatelné, takže URL v textu je mrtvá váha, kterou by čtenářka musela přepsat. Pokud záznam potřebuje cíl, řekni místo toho, na co ťuknout v aplikaci: „Podívejte se na nové filtry pod Nastavení > Hledání” funguje; „Přečtěte si víc na example.com/blog/filtry” ne, na tomto povrchu. Za druhé, cokoli podmíněné nebo specifické pro publikum: webový changelog může říct „pokud používáte API, tohle se vás týká”, ale výpis v obchodě zasáhne každou nainstalovanou uživatelku najednou, takže podmíněný řádek se čte jako šum pro 95 %, na které se nevztahuje. Podmíněný detail dej místo toho do zprávy v aplikaci, spuštěné pro účty, kterých se to skutečně týká.

Mělo by mít každé vydání vlastní poznámky, nebo je v pořádku znovu použít „opravy chyb a vylepšení výkonu”?

Znovu použij pro vydání, která tím opravdu jsou, ale audituj, jak často to je opravdu pravda. Jak psát release notes už rozebírá, proč tahle fráze prozrazuje poznámku napsanou zevnitř místo pro čtenářku; na mobilu to napáchá dvojí škodu, protože release notes obchodu jsou jedno z mála míst, kde některé uživatelky vůbec něco vidí mezi aktualizacemi, a dlouhá řada „oprav chyb a vylepšení výkonu” se čte, jako by se aplikace neměnila, což dělá horší dojem než žádné poznámky vůbec za to období.

Ovlivňují release notes vůbec, jestli lidé aplikaci aktualizují?

Nepřímo, přes viditelnost spíš než přesvědčování. Většina uživatelek aktualizuje automaticky a nikdy si poznámky před aktualizací nepřečte; poznámky nejvíc záleží menšině, která aktualizace kontroluje ručně, a recenzentkám nebo tisku, kteří procházejí historii výpisu obchodu. Psát pro to menší publikum se přesto vyplatí, protože výpis se skutečnou historií konkrétních, datovaných záznamů se čte jako aktivně udržovaná aplikace, a výpis s rokem „oprav chyb a vylepšení výkonu” ne, bez ohledu na to, kolik toho bylo skutečně vydáno za tu dobu.

A co vynucená aktualizace, kde poznámka musí vysvětlit, proč uživatelka nemá na výběr?

Uveď důvod a termín v první řádce, přede vším ostatním, protože vynucená aktualizace je jediný případ, kdy je čtenářka naštvaná ještě předtím, než začne číst. „Tato aktualizace je nutná pro další synchronizaci vašich dat. Aktualizujte do [datum], abyste se vyhnuli přerušení.” říká, co udělat a proč, v jedné větě; zahrabat ten důvod pod tři řádky nesouvisejících poznámek o funkcích se čte, jako by aplikace schovávala tu nepříjemnou část.

FAQ

Měly by mobilní release notes odpovídat webovému changelogu stejného vydání? Pokrývat stejné základní změny, ale ne slovo od slova. Webový changelog si může dovolit úplné vysvětlení; mobilní poznámka potřebuje stejná fakta stlačená do věty se slovesem první, což obvykle znamená, že je to přepis, ne kopie.

Vyplatí se lokalizovat mobilní release notes pro každý podporovaný jazyk? Ano, víc než u webového changelogu, protože výpis obchodu je často jediný lokalizovaný povrch, který některé uživatelky vidí mezi sezeními, a obě platformy podporují release notes podle lokalizace bez další inženýrské práce nad rámec samotného překladu.

Jak dlouhá by měla být mobilní release note, když neexistuje limit vynucující stručnost? Krátká stejně. Strop 4 000 znaků na iOS je zřídkakdy skutečné omezení; tím je náhled 2-3 řádků, a psát za to, co ten náhled ukazuje, jen znamená, že méně lidí si přečte tu část, na které záleželo.

Potřebují release notes číslo verze ve viditelném textu? Ne. Obchod už zobrazuje číslo verze vedle poznámek. Opakovat ho v textu utrácí viditelné znaky za informaci, kterou čtenářka už má před sebou.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Šablona poznámek k vydání, Příklady changelogu