Release notes dla aplikacji mobilnych: co ucina limit

Wszystko w tym hubie o pisaniu release notes zakłada stronę, którą w pełni kontrolujesz: dowolną długość, działające linki, formatowanie, które się renderuje. Release notes aplikacji mobilnej żyją w cudzym pudełku. Apple daje około 4000 znaków, ale pokazuje tylko pierwsze linijki, zanim dotknie się “więcej”; Google daje podobną przestrzeń z tym samym efektywnym problemem podglądu, a żadna z platform nie renderuje klikalnego linku w tekście. Zasady z jak pisać release notes, które ludzie naprawdę czytają wciąż obowiązują: powiedz, co się zmieniło i co musi zrobić czytelniczka, ale miejsce, by to zrobić, to ułamek tego, na co pozwala strona changeloga, a cięcia muszą być świadome, nie przypadkowe.

Co naprawdę mieści się w widocznym podglądzie?

Pierwsze jedna do dwóch linijek, mniej więcej 80 do 170 znaków w zależności od urządzenia i rozmiaru czcionki, zanim czytelniczka musi dotknąć, by rozwinąć. To cały budżet dla części release note, która decyduje, czy ktokolwiek przeczyta resztę, i oznacza to, że najważniejsze zdanie musi przyjść pierwsze, nie numer wersji, nie powitanie, nie nagłówek kategorii. Release note, która zaczyna się od “Nowości w tej wersji:”, już wydała jedną trzecią widocznej przestrzeni na cztery słowa, które nic nie mówią czytelniczce.

Czy zasada “co możesz zrobić teraz, co ci się należy” wciąż działa przy tej długości?

Tak, i staje się surowsza, nie inna. Jedno zdanie na wpis, czasownik pierwszy, bez wstępu: “Eksportuj dane jako CSV z Ustawień.” wygrywa z “Dodaliśmy możliwość, aby użytkownicy mogli teraz eksportować swoje dane w formacie CSV”, używając jednej trzeciej słów, by powiedzieć to samo. Przy długości strony changeloga, nieco rozwlekłe zdanie kosztuje czytelniczkę pół sekundy. Przy długości mobilnej release note, ta sama rozwlekłość może wypchnąć całe zdanie poza widoczny podgląd, więc czytelniczka nigdy nie widzi czasownika, który powiedziałby jej, co się zmieniło.

Źle, marnuje podgląd na oprawę:
"Z radością przedstawiamy nową aktualizację pełną
ulepszeń! Czytaj dalej, by poznać szczegóły."

Dobrze, cała wartość w pierwszej linii:
"Eksportuj dane jako CSV. Tryb ciemny respektuje teraz
ustawienie systemowe. Naprawiono awarię przy otwieraniu
udostępnionych linków."

Co musi zostać ucięte, co web-owy wpis changeloga zwykle by zachował?

Linki, po pierwsze, bo żaden z dwóch sklepów nie renderuje ich jako klikalne, więc URL w tekście to martwa waga, którą czytelniczka musiałaby przepisać. Jeśli wpis potrzebuje celu, powiedz zamiast tego, co dotknąć w aplikacji: “Zobacz nowe filtry pod Ustawienia > Wyszukiwanie” działa; “Czytaj więcej na example.com/blog/filtry” nie działa na tej powierzchni. Po drugie, wszystko warunkowe albo specyficzne dla odbiorców: web-owy changelog może powiedzieć “jeśli używasz API, to cię dotyczy”, ale wpis w sklepie dociera do każdej zainstalowanej użytkowniczki jednocześnie, więc warunkowa linijka czyta się jak szum dla 95%, których to nie dotyczy. Umieść warunkowy szczegół zamiast tego w wiadomości w aplikacji, wyzwalanej dla kont, których to naprawdę dotyczy.

Czy każde wydanie powinno mieć własne notatki, czy w porządku jest powtórne użycie “poprawek błędów i usprawnień wydajności”?

Użyj tego ponownie dla wydań, które naprawdę są tym, ale sprawdzaj, jak często to naprawdę prawda. Jak pisać release notes już opisuje, dlaczego to sformułowanie zdradza notatkę napisaną od środka zamiast dla czytelniczki; na mobile robi podwójną szkodę, bo release notes sklepu to jedno z niewielu miejsc, gdzie niektóre użytkowniczki w ogóle coś widzą między aktualizacjami, a długa seria “poprawek błędów i usprawnień wydajności” czyta się, jakby aplikacja się nie zmieniała, co robi gorsze wrażenie niż brak notatek w ogóle przez ten okres.

Czy release notes wpływają na to, czy ludzie w ogóle aktualizują aplikację?

Pośrednio, przez widoczność, nie perswazję. Większość użytkowniczek aktualizuje automatycznie i nigdy nie czyta notatek przed aktualizacją; notatki liczą się najbardziej dla mniejszości, która sprawdza aktualizacje ręcznie, oraz dla recenzentek albo prasy, które przeglądają historię wpisu w sklepie. Pisanie dla tej mniejszej grupy i tak się opłaca, bo wpis z prawdziwą historią konkretnych, datowanych wpisów czyta się jak aktywnie utrzymywana aplikacja, a wpis z rokiem “poprawek błędów i usprawnień wydajności” nie, bez względu na to, ile naprawdę wydano w tym czasie.

A co z wymuszoną aktualizacją, gdzie notatka musi wyjaśnić, dlaczego użytkowniczka nie ma wyboru?

Podaj powód i termin w pierwszej linii, przed wszystkim innym, bo wymuszona aktualizacja to jedyny przypadek, w którym czytelniczka jest już zirytowana, zanim zacznie czytać. “Ta aktualizacja jest wymagana, by dalej synchronizować twoje dane. Zaktualizuj przed [datą], by uniknąć przerwy.” mówi, co zrobić i dlaczego, w jednym zdaniu; zakopanie tego powodu pod trzema liniami niepowiązanych notatek o funkcjach czyta się, jakby aplikacja ukrywała niewygodną część.

FAQ

Czy mobilne release notes powinny odpowiadać web-owemu changelogowi tego samego wydania? Obejmować te same podstawowe zmiany, ale nie słowo w słowo. Web-owy changelog może pozwolić sobie na pełne wyjaśnienie; mobilna notatka potrzebuje tych samych faktów skompresowanych do zdania z czasownikiem pierwszym, co zwykle oznacza, że to przepisanie, nie kopia.

Czy warto lokalizować mobilne release notes dla każdego wspieranego języka? Tak, bardziej niż dla web-owego changeloga, bo wpis w sklepie jest często jedyną zlokalizowaną powierzchnią, którą niektóre użytkowniczki widzą między sesjami, a obie platformy wspierają release notes per lokalizacja bez dodatkowej pracy inżynieryjnej poza samym tłumaczeniem.

Jak długa powinna być mobilna release note, jeśli nie ma limitu wymuszającego zwięzłość? I tak krótka. Sufit 4000 znaków na iOS rzadko jest prawdziwym ograniczeniem; jest nim podgląd 2-3 linijek, a pisanie poza to, co pokazuje ten podgląd, oznacza tylko, że mniej osób czyta część, która się liczyła.

Czy release notes potrzebują numeru wersji w widocznym tekście? Nie. Sklep już pokazuje numer wersji obok notatek. Powtarzanie go w tekście wydaje widoczne znaki na informację, którą czytelniczka już ma przed sobą.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Szablon notatek wydania, Przykłady changeloga