Mobil uygulamalar için release notes: sınır neyi keser

Bu hub’da release notes yazmakla ilgili her şey tamamen kontrol ettiğin bir sayfayı varsayıyor: istediğin uzunluk, çalışan linkler, render edilen biçimlendirme. Mobil bir uygulamanın release notes’u başka birinin kutusunda yaşar. Apple yaklaşık 4.000 karakter verir ama “devamı”na dokunulmadan önce sadece ilk birkaç satırı gösterir; Google benzer bir alan verir, aynı etkili önizleme sorunuyla, ve her iki platform da metin içinde tıklanabilir bir link render etmez. Gerçekten okunan release notes nasıl yazılır yazısındaki kurallar hâlâ geçerli: neyin değiştiğini ve okuyucunun ne yapması gerektiğini söylemek, ama bunu yapacak alan bir changelog sayfasının izin verdiğinin küçük bir kısmıdır, ve kesintiler yanlışlıkla değil bilinçli yapılmalıdır.

Görünür önizlemeye gerçekte ne sığar?

Cihaza ve yazı tipi boyutuna bağlı olarak yaklaşık 80 ila 170 karakter olan ilk bir veya iki satır, okuyucunun genişletmek için dokunması gerekmeden önce. Bu, release note’un geri kalanını kimsenin okuyup okumayacağına karar veren kısmının tüm bütçesidir, ve bu, en önemli cümlenin ilk gelmesi gerektiği anlamına gelir, versiyon numarası değil, bir selamlama değil, bir kategori başlığı değil. “Bu sürümdeki yenilikler:” ile başlayan bir release note, okuyucuya hiçbir şey söylemeyen dört kelimeye görünür alanının üçte birini şimdiden harcamıştır.

“Şimdi ne yapabilirsin, ne borçlusun” kuralı bu uzunlukta hâlâ işe yarıyor mu?

Evet, ve daha katı hale gelir, farklı değil. Girdi başına bir cümle, önce fiil, giriş yok: “Verilerini Ayarlar’dan CSV olarak dışa aktar.” “Kullanıcıların artık verilerini CSV formatında dışa aktarabilmesi özelliğini ekledik” cümlesini kelimelerin üçte birini kullanarak aynı şeyi söyleyerek yener. Changelog sayfası uzunluğunda, biraz gevezelik eden bir cümle okuyucuya yarım saniyeye mal olur. Mobil release note uzunluğunda, aynı geveze anlatım cümleyi tamamen görünür önizlemenin dışına itebilir, böylece okuyucu neyin değiştiğini söyleyecek fiili hiç görmez.

Kötü, önizlemeyi çerçeveye harcıyor:
"İyileştirmelerle dolu yeni bir güncelleme sunmaktan
heyecan duyuyoruz! Detaylar için okumaya devam edin."

İyi, tüm değer ilk satırda:
"Verilerini CSV olarak dışa aktar. Karanlık mod artık
sistem ayarına uyuyor. Paylaşılan linkleri açarken
oluşan çökme düzeltildi."

Bir web changelog girişinin normalde tutacağı ne kesilmeli?

Önce linkler, çünkü iki mağazadan hiçbiri onları tıklanabilir hale getirmiyor, bu yüzden metindeki bir URL okuyucunun yeniden yazması gereken ölü ağırlıktır. Girişin bir hedefe ihtiyacı varsa, bunun yerine uygulamada nereye dokunulacağını söyle: “Yeni filtreleri Ayarlar > Arama altında gör” işe yarar; “example.com/blog/filtreler adresinde devamını oku” bu yüzeyde işe yaramaz. İkincisi, koşullu veya belirli bir kitleye özgü her şey: bir web changelog’u “API kullanıyorsan, bu seni etkiler” diyebilir, ama bir mağaza girdisi her kurulu kullanıcıya aynı anda ulaşır, bu yüzden koşullu bir satır bunun uygulanmadığı %95 için gürültü gibi okunur. Koşullu detayı bunun yerine gerçekten ilgilendirdiği hesaplar için tetiklenen bir uygulama içi mesaja koy.

Her sürümün kendi notları mı olmalı, yoksa “hata düzeltmeleri ve performans iyileştirmeleri”ni yeniden kullanmak sorun değil mi?

Bunu gerçekten öyle olan sürümler için yeniden kullan, ama bunun ne sıklıkla gerçekten doğru olduğunu denetle. Release notes nasıl yazılır bu ifadenin neden okuyucu için değil içeriden yazılmış bir notu ele verdiğini zaten ele alıyor; mobilde çift zarar veriyor, çünkü mağaza release notes’u bazı kullanıcıların güncellemeler arasında bir şey gördüğü nadir yerlerden biridir, ve uzun bir “hata düzeltmeleri ve performans iyileştirmeleri” dizisi uygulamanın değişmediği gibi okunur, ki bu o dönem için hiç not olmamasından daha kötü bir izlenimdir.

Release notes insanların uygulamayı güncelleyip güncellemeyeceğini etkiler mi?

Dolaylı olarak, ikna yerine görünürlük yoluyla. Çoğu kullanıcı otomatik olarak günceller ve güncellemeden önce notları hiç okumaz; notlar en çok güncellemeleri elle kontrol eden azınlık için, ve bir mağaza girdisinin geçmişini tarayan eleştirmenler veya basın için önemlidir. O daha küçük kitle için yazmak yine de karşılığını verir, çünkü belirli, tarihli girişlerin gerçek bir geçmişine sahip bir girdi aktif olarak sürdürülen bir uygulama gibi okunur, ve bir yıl boyunca “hata düzeltmeleri ve performans iyileştirmeleri” olan bir girdi okunmaz, o sürede gerçekte ne kadar şey yayınlanmış olursa olsun.

Ya kullanıcının seçeneği olmadığını notun açıklaması gereken zorunlu bir güncelleme?

Nedeni ve son tarihi her şeyden önce ilk satırda belirt, çünkü zorunlu güncelleme okuyucunun okumaya başlamadan önce bile rahatsız olduğu tek durumdur. “Bu güncelleme verilerinin senkronize olmaya devam etmesi için gerekli. Kesintiyi önlemek için [tarih]‘e kadar güncelle.” tek cümlede ne yapılacağını ve nedenini söyler; bu nedeni üç satır ilgisiz özellik notunun altına gömmek, uygulamanın rahatsız edici kısmı sakladığı gibi okunur.

FAQ

Mobil release notes aynı sürümün web changelog’uyla eşleşmeli mi? Aynı temel değişiklikleri kapsamalı, ama kelimesi kelimesine değil. Web changelog’u tam açıklamayı karşılayabilir; mobil not aynı gerçekleri önce fiil olacak şekilde bir cümleye sıkıştırılmış olarak ister, ki bu genelde kopyala-yapıştır değil yeniden yazım olduğu anlamına gelir.

Desteklenen her dil için mobil release notes’u yerelleştirmeye değer mi? Evet, bir web changelog’undan daha fazla, çünkü mağaza girdisi bazı kullanıcıların oturumlar arasında gördüğü tek yerelleştirilmiş yüzey olabilir, ve her iki platform da çeviri dışında ek mühendislik işi olmadan yerel başına release notes’u destekler.

Kısalığı zorlayan bir sınır yoksa mobil bir release note ne kadar uzun olmalı? Yine de kısa. iOS’taki 4.000 karakter tavanı nadiren gerçek kısıtlamadır; gerçek kısıtlama 2-3 satırlık önizlemedir, ve o önizlemenin gösterdiğinin ötesine yazmak sadece daha az insanın önemli olan kısmı okuduğu anlamına gelir.

Release notes’un görünür metinde bir versiyon numarasına ihtiyacı var mı? Hayır. Mağaza notların yanında versiyon numarasını zaten gösterir. Onu metin içinde tekrarlamak okuyucunun zaten önünde olan bilgi için görünür karakter harcar.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Release notu şablonu, Changelog örnekleri