Release notes mobile: apa yang dipotong batasan

Semua yang dibahas hub ini tentang menulis release notes mengasumsikan halaman yang sepenuhnya Anda kendalikan: panjang berapa pun, tautan yang berfungsi, format yang tampil. Release notes aplikasi mobile hidup di dalam kotak milik orang lain. Apple memberi sekitar 4.000 karakter tapi hanya menampilkan beberapa baris pertama sebelum “lainnya” disentuh; Google memberi ruang serupa dengan masalah pratinjau efektif yang sama, dan kedua platform tidak menampilkan tautan yang bisa diklik di dalam teks. Aturan dari cara menulis release notes yang benar-benar dibaca orang masih berlaku: katakan apa yang berubah dan apa yang harus dilakukan pembaca, tapi ruang untuk melakukannya hanya sebagian kecil dari yang diizinkan halaman changelog, dan pemotongan harus disengaja, bukan tidak sengaja.

Apa yang benar-benar muat dalam pratinjau yang terlihat?

Satu sampai dua baris pertama, sekitar 80 sampai 170 karakter tergantung perangkat dan ukuran font, sebelum pembaca harus menyentuh untuk memperluas. Itu seluruh anggaran untuk bagian release note yang menentukan apakah ada yang akan membaca sisanya, dan itu berarti kalimat paling penting harus datang lebih dulu, bukan nomor versi, bukan sapaan, bukan judul kategori. Release note yang dimulai dengan “Baru di versi ini:” sudah menghabiskan sepertiga ruang terlihatnya untuk empat kata yang tidak memberi tahu apa pun kepada pembaca.

Apakah aturan “apa yang bisa dilakukan sekarang, apa yang harus disampaikan” masih berlaku di panjang ini?

Ya, dan jadi lebih ketat, bukan berbeda. Satu kalimat per entri, kata kerja lebih dulu, tanpa basa-basi: “Ekspor data Anda sebagai CSV dari Pengaturan.” mengalahkan “Kami telah menambahkan kemampuan bagi pengguna untuk sekarang mengekspor data mereka dalam format CSV” dengan menggunakan sepertiga kata untuk mengatakan hal yang sama. Pada panjang halaman changelog, kalimat yang agak bertele-tele merugikan pembaca setengah detik. Pada panjang release note mobile, bertele-tele yang sama bisa mendorong seluruh kalimat keluar dari pratinjau yang terlihat, sehingga pembaca tidak pernah melihat kata kerja yang akan memberi tahu apa yang berubah.

Buruk, memboroskan pratinjau untuk basa-basi:
"Kami senang menghadirkan pembaruan baru penuh
peningkatan! Baca terus untuk detailnya."

Baik, semua nilai di baris pertama:
"Ekspor data sebagai CSV. Mode gelap sekarang mengikuti
pengaturan sistem. Perbaikan crash saat membuka tautan
yang dibagikan."

Apa yang harus dipotong yang biasanya dipertahankan entri changelog web?

Tautan, pertama, karena kedua toko tidak menampilkannya sebagai bisa diklik, jadi URL di dalam teks adalah beban mati yang harus diketik ulang pembaca. Jika entri butuh tujuan, katakan apa yang harus disentuh di dalam aplikasi sebagai gantinya: “Lihat filter baru di bawah Pengaturan > Pencarian” berhasil; “Baca lebih lanjut di example.com/blog/filter” tidak, di permukaan ini. Kedua, apa pun yang bersyarat atau spesifik untuk audiens tertentu: changelog web bisa bilang “jika Anda memakai API, ini memengaruhi Anda”, tapi daftar toko menjangkau setiap pengguna yang terpasang sekaligus, jadi baris bersyarat terbaca sebagai kebisingan bagi 95% yang tidak terpengaruh. Taruh detail bersyarat itu dalam pesan in-app sebagai gantinya, dipicu untuk akun yang benar-benar terkait.

Haruskah setiap rilis punya catatannya sendiri, atau boleh saja memakai ulang “perbaikan bug dan peningkatan performa”?

Pakai ulang untuk rilis yang benar-benar seperti itu, tapi audit seberapa sering itu benar-benar benar. Cara menulis release notes sudah membahas kenapa frasa itu mengkhianati catatan yang ditulis dari dalam alih-alih untuk pembaca; di mobile, ini merusak dua kali lipat, karena release notes toko adalah salah satu dari sedikit tempat sebagian pengguna melihat apa pun di antara pembaruan, dan rangkaian panjang “perbaikan bug dan peningkatan performa” terbaca seolah aplikasi tidak berubah, yang jadi kesan lebih buruk daripada tidak ada catatan sama sekali untuk periode itu.

Apakah release notes memengaruhi apakah orang memperbarui aplikasi sama sekali?

Secara tidak langsung, lewat visibilitas alih-alih persuasi. Kebanyakan pengguna memperbarui otomatis dan tidak pernah membaca catatan sebelum memperbarui; catatan paling penting bagi minoritas yang memeriksa pembaruan secara manual, dan bagi reviewer atau pers yang menyisir riwayat daftar toko. Menulis untuk audiens yang lebih kecil itu tetap terbayar, karena daftar dengan riwayat nyata entri spesifik dan bertanggal terbaca sebagai aplikasi yang aktif dirawat, dan daftar dengan setahun “perbaikan bug dan peningkatan performa” tidak, terlepas dari seberapa banyak yang sebenarnya dirilis dalam waktu itu.

Bagaimana dengan pembaruan paksa, di mana catatan harus menjelaskan kenapa pengguna tidak punya pilihan?

Nyatakan alasan dan tenggat waktu di baris pertama, sebelum yang lain, karena pembaruan paksa adalah satu kasus di mana pembaca sudah kesal sebelum mulai membaca. “Pembaruan ini diperlukan untuk terus menyinkronkan data Anda. Perbarui sebelum [tanggal] untuk menghindari gangguan.” menyampaikan apa yang harus dilakukan dan kenapa dalam satu kalimat; mengubur alasan itu di bawah tiga baris catatan fitur yang tidak terkait terbaca seolah aplikasi menyembunyikan bagian yang tidak nyaman.

FAQ

Haruskah release notes mobile cocok dengan changelog web untuk rilis yang sama? Mencakup perubahan mendasar yang sama, tapi bukan kata demi kata. Changelog web bisa memberi penjelasan lengkap; catatan mobile butuh fakta yang sama dipadatkan jadi satu kalimat dengan kata kerja lebih dulu, yang biasanya berarti itu tulisan ulang, bukan salinan.

Apakah sepadan melokalkan release notes mobile untuk setiap bahasa yang didukung? Ya, lebih daripada untuk changelog web, karena daftar toko sering jadi satu-satunya permukaan terlokalkan yang dilihat sebagian pengguna di antara sesi, dan kedua platform mendukung release notes per locale tanpa kerja rekayasa tambahan di luar terjemahan itu sendiri.

Seberapa panjang release note mobile seharusnya jika tidak ada batas yang memaksa keringkasan? Tetap pendek. Batas 4.000 karakter di iOS jarang jadi kendala sebenarnya; yang jadi kendala adalah pratinjau 2-3 baris, dan menulis melebihi apa yang ditampilkan pratinjau itu hanya berarti lebih sedikit orang membaca bagian yang penting.

Apakah release notes butuh nomor versi di teks yang terlihat? Tidak. Toko sudah menampilkan nomor versi di sebelah catatan. Mengulanginya di dalam teks menghabiskan karakter terlihat untuk informasi yang sudah ada di depan pembaca.

Klaim teknis dalam artikel ini belum ditinjau secara independen. Jika ada yang keliru, beri tahu kami dan kami akan memperbaikinya.

Terkait di changeloop: Templat catatan rilis, Contoh changelog