Kademeli Bozulma mı, Aşamalı Zenginleştirme mi?

Kademeli bozulma, tam donanımlı sürümü önce yazıp zayıf ortamlar için geri düşüş yolları eklemek demek. Aşamalı zenginleştirme ise tersini yapar: çalışan bir taban kurar, üzerine katman ekler. İkisi kağıt üzerinde aynı sonucu vaat eder, pratikte farklı yerlerde kırılır ve fark hangi sürümün önce yazıldığından çıkar.

Hangisini seçeceksiniz

Yeni bir arayüze başlıyorsanız tabandan kurun. Sebep felsefi değil, sıralamayla ilgili: önce yazdığınız sürüm her gün açtığınız, her sprintte elinize aldığınız sürüm olur. Kademeli bozulmada bu sürüm en zengin olanıdır, geri düşüş yolu ise aylarca kimsenin bakmadığı bir dal olarak kalır.

Kademeli bozulmanın savunulabilir olduğu tek durum, elinizde zaten çalışan ağır bir uygulamanın olması. Var olan bir ürünü tabandan yeniden yazmak yerine düşüş yolları eklemek makul bir karardır, yeter ki o yolların da bir sahibi ve testi olsun.

HTML ile CSS zaten bozuluyor, JavaScript bozulmuyor

Tarayıcı tanımadığı bir CSS özelliğini sessizce atlar, tanımadığı bir HTML özniteliğini yok sayar. input type="date" desteklenmiyorsa metin kutusuna döner. Yani bu iki katmanda kademeli bozulma kendiliğinden çalışır, sizin yapmanız gereken engel olmamaktır.

JavaScript öyle değil. Bir sözdizimi hatası ya da desteklenmeyen tek bir metot, o dosyanın tamamını çalıştırılamaz hale getirir; ekranda kalan şey yarısı çalışan bir arayüz değil, hiç çalışmayan bir arayüzdür. Pratik sonuç şu: kritik yolu betiğin arkasına koymayın.

• Formun action ve method özniteliklerini doldurun, gönderim JavaScript olmadan da sunucuya ulaşsın.
• Bağlantıyı gerçek href ile yazın; tıklama olayına bağlanan div betik düşünce ölür, üstelik klavyeyle de gezilmez.
• İçeriği istemcide üretmeden önce sorun: bu metnin sunucudan hazır gelmemesi için gerçek bir sebep var mı?

Her katman ayrı bir bakım kalemi

Ayrı mobil uygulama, ayrı web sürümü, bir de sadeleştirilmiş sürüm derken üç ayrı arayüz çıkar ortaya. Bunların üçü aynı veriyi göstermek zorunda, dolayısıyla her yeni alan üç yerde ele alınır ve her fiyat değişikliği üç yerde doğrulanır.

Asıl sorun sayının kendisi değil, trafiğin dağılımı. Düşük sürüme kullanıcıların küçük bir kısmı gelir; o kısım hata bildirimlerinin de küçük bir kısmını üretir. Sonuçta en az test edilen yol, en kırılgan cihazlarda çalışan yol olur. Bir projede sadeleştirilmiş sürümün aylardır bozuk olduğunu, hata kayıtlarına eski bir tarayıcının user-agent'ı düştüğünde fark ettim.

Çözüm katmanı kaldırmak değilse, düşük sürümü izlemeye almak. Sürüm başına ayrı hata etiketi ve ayrı dönüşüm ölçümü tutun; yoksa bozulduğunu ancak kullanıcı kaybederek öğrenirsiniz.

Neyin düşeceğine görev karar verir

Katmanları cihaz sınıfına göre değil, kullanıcının o an tamamlamaya çalıştığı göreve göre ayırın. Rapor grafiğini küçük ekranda tabloya indirmek makul bir düşüştür, çünkü veri duruyor. Satın alma adımını masaüstüne ertelemek düşüş değil, görevi iptal etmektir.

Buradan çıkan sınır net: içerik ve ana işlem her sürümde kalır, süsleme ve ikincil işlevler düşer. "Bu sayfayı görüntülemek için masaüstünü kullanın" yazan bir arayüz kademeli bozulma uygulamıyor, kullanıcıyı geri çeviriyor.

Aynı ölçüt erişilebilirlik için de işler. Ekran okuyucu, klavye ve düşük bant genişliği aslında aynı sorunun üç görünümü: zengin katman yokken arayüzden geriye ne kalıyor? Bunu test etmenin en ucuz yolu tarayıcıda JavaScript'i kapatıp kendi kritik akışınızı baştan sona denemek. Yarım saat sürer ve genellikle bir tasarım kararınızı değiştirir.