Enhancement: Ekstra Özellik ile Gizli Ön Koşul Arasındaki Sınır

Enhancement'ın tanımı kolay: temel işlev herkeste çalışır, cihaz destekliyorsa üstüne hızlandırıcı bir katman gelir. Zor olan, elinizdeki özelliğin gerçekten o katmanda mı durduğunu yoksa sessizce ön koşula mı dönüştüğünü görmek. Çoğu arayüzde sınırın yanlış tarafına düşen bir iki özellik vardır ve bunlar tasarım dosyasında değil, gerçek cihazlarda ortaya çıkar.

Tek soruluk test

Bir özelliğin enhancement olup olmadığını anlamak için özelliği kapatın ve şunu sorun: kullanıcı aynı işi, biraz daha yavaş da olsa bitirebiliyor mu? Cevap evetse enhancement. Hayırsa, adı ne olursa olsun o özellik ön koşuldur ve kapsam dışında kalan herkes ekranın önünde takılı kalır.

Kamerayla barkod okuma bu testten geçer, çünkü aynı kutuya elle yazmak da mümkündür. Konum izni isteyip "yakınımdakiler" listesi getiren bir arama, izin verilmediğinde şehir seçtiriyorsa geçer, boş liste gösteriyorsa geçmez. Aradaki fark tek satırlık bir yedek yoldur ve genelde onu yazmak unutulur.

Hover bu testten geçemiyor

Hover efektleri neredeyse her listede güvenli bir enhancement örneği olarak sayılır. Pratikte durum daha karışık. Silme ikonunu yalnızca fareyle üzerine gelince gösteren bir satır, dokunmatik ekranda o işlevi tamamen kaybeder. Bir bağlantının nereye gittiğini yalnızca hover ipucuyla söyleyen arayüz de aynı hataya düşer.

Buradaki asıl mesele hover'ın süs mü bilgi mi taşıdığı. Rengin bir tık koyulaşması süstür, kaybı kimseyi durdurmaz. İçeriğin ya da eylemin kendisi hover'ın arkasındaysa, o artık bir giriş yöntemi zorunluluğudur. Ölçüt basit: hover'la ortaya çıkan şey ekranın başka bir yerinde de duruyor mu?

JavaScript kapalı değil, başarısız

Progressive enhancement genelde "JavaScript'i kapatan kullanıcılar" üzerinden savunulur. Bu savunma zayıf, çünkü bilerek kapatan kitle gerçekten küçük. Asıl mesele niyet değil, başarısızlık: betik dosyası eksik yüklenir, üçüncü parti bir kaynak zaman aşımına düşer, tünelde kopan bağlantı paketi yarıda bırakır, eski bir tarayıcıda tek bir sözdizimi hatası tüm paketi devre dışı bırakır.

Bu durumların hepsinde kullanıcı JavaScript'i açık sanır ve boş bir ekrana bakar. Formun sunucuya normal bir POST ile de gidebiliyor olması, tam da bu anlarda işe yarar. Aynı mantık gezinme için de geçerli: bağlantılar gerçek href taşıdığında, betik gelmese bile site dolaşılabilir kalır.

Cihaz ve yetenek ayrımını da genelde user agent kontrolü yerine doğrudan özellik testiyle çözerim. navigator.mediaDevices var mı diye bakmak, tarayıcı adına göre liste tutmaktan hem kısa hem de gelecek sürümlerde kendiliğinden doğru kalıyor.

Aynı işe kaç yol açılmalı

Yaygın tavsiye, bir işlevi olabildiğince çok yoldan erişilir kılmaktır. Buna katılmıyorum. Aynı eylemin üç ayrı kısayolu, kullanıcıya esneklik yerine hatırlama yükü bırakır; hangisinin hangi ekranda çalıştığını kimse akılda tutmaz ve sonuçta hepsi yerine en yavaş yol kullanılır.

Daha iyisi, klasik yolu her yerde bırakıp yanına tek bir hızlandırıcı koymak ve o hızlandırıcıyı arayüzün tamamında aynı biçimde uygulamak. Listede sola kaydırınca siliniyorsa, ayarlar ekranında da öyle silinsin. Tutarlılık burada estetik bir tercih değil, kısayolun öğrenilebilmesinin tek koşulu.

Enhancement zamanla standarda dönüşür

Fare tekerleğiyle kaydırma da, klavye kısayolları da bir zamanlar ekstraydı; bugün ikisi de temel etkileşimin parçası. Bu geçiş kendiliğinden olur ve tasarımcının işi geçişi zorlamak değil, ne zaman gerçekleştiğini fark etmek. Ölçüm burada devreye girer: kısayolu kullananların oranı klasik yolun önüne geçtiyse, artık klasik yol yedek konumundadır. Geçmeden önce kaldırırsanız, kullanıcının yarısını kendi arayüzünüzde yolsuz bırakırsınız.