Mobil Uyumlu Tasarımda Cihaz Listesi Yerine Kısıtlara Bakmak
Mobil uyum tartışması hâlâ cihaz listeleriyle yapılıyor: şu telefon, bu tablet, şu ekran boyu. Oysa tasarımı zorlayan şey cihazın adı değil, aynı anda gelen üç kısıt: dar bir görüntü alanı, parmakla yapılan hedefleme ve ne zaman kopacağı belli olmayan bir bağlantı. Kararları bu üçünün üzerine kurduğunuzda cihaz tablosuna ihtiyaç kalmıyor.
Cihaz Kategorisi Yerine Kısıt Listesi
Eski kaynaklar cihazları üçe ayırır: özellikli telefon, akıllı telefon, tam ekran dokunmatik. Bu ayrım bugün hiçbir tasarım kararını belirlemiyor. Aynı ekran boyunda tamamen farklı ağ koşulları, aynı cihazda hem parmak hem klavye hem ekran okuyucu kullanımı var.
Yerine üç değişkeni yazın ve tasarımı onlara bağlayın: görüntü alanı genişliği, girdi yöntemi, bağlantı kalitesi. Fark pratikte şurada görünüyor: cihaza göre tasarlarsanız piyasaya çıkan her yeni ekran boyu için yeni bir kural eklemek zorunda kalırsınız, kısıta göre tasarlarsanız kural sayısı sabit kalır.
Ayrı Mobil Site mi, Tek Kod mu
Kaynakların çoğu bu iki seçeneği aynı listede yan yana öneriyor ve bu tavsiye kendi içinde tutarsız. Ayrı bir mobil site ikinci bir kod tabanı, ikinci bir içerik akışı, cihaz algılamaya dayalı yönlendirme ve canonical etiket bakımı demek. Her yeni özellik iki yerde yazılıyor, hata iki yerde düzeltiliyor.
Tek kod tabanı neredeyse her durumda doğru cevap. Ayrı bir arayüz yalnızca görev gerçekten farklıysa mantıklı: sahadaki ekibin kullandığı, masaüstünde karşılığı olmayan bir akış gibi. "Aynı içeriği küçük ekranda göstermek" bu kapsama girmiyor.
Dokunma Hedefleri ve Aralıkları
Parmakla hedefleme, imleçten daha kaba ve geri bildirimi daha zayıf. WCAG 2.2'nin 2.5.8 ölçütü asgari hedef boyutunu 24x24 CSS pikseli olarak tanımlıyor, 2.5.5 ise daha yüksek seviyede 44x44 istiyor. Metin bağlantıları gibi satır içi hedefler bu kuralın dışında tutuluyor.
Asıl hatalar boyutta değil aralıkta çıkıyor. Yan yana duran ve sonucu geri alınamaz iki eylem, örneğin sil ile kaydet, yeterince ayrılmadığında hedef boyutu kurala uysa bile yanlış dokunma oranı yüksek kalıyor. Yıkıcı eylemi ya uzağa koyun ya da geri alınabilir hale getirin.
Bir de başparmak erişimi var. Tek elle tutulan telefonda ekranın üst köşeleri en zor bölge; birincil eylemi oraya yerleştirmeyin.
Hız: Neyi Ölçtüğünüz
"Site hızlı olsun" ölçülebilir bir hedef değil. Ölçülebilir olanlar şunlar: ilk ekranın ne zaman çizildiği, en büyük içerik öğesinin ne zaman yerleştiği, dokunmadan sonra arayüzün ne kadar sürede cevap verdiği. Üçü farklı sebeplerden bozulur, dolayısıyla ayrı ayrı takip edilmeleri gerekiyor.
Görsel tarafında en çok kazandıran iki müdahale basit. Görselin tek bir küçük kopyasını üretmek yerine srcset ile birkaç boy verin, seçimi tarayıcıya bırakın; bu üç satırlık iş için eklentiye ihtiyacınız yok. Ekranın altında kalan görsellere lazy yükleme ekleyin, ama ilk ekranda görünene eklemeyin, orada tam tersi etki yapıyor.
Genişlik ve yükseklik niteliklerini yazmak da ayrı bir konu gibi görünür, değildir: tarayıcı yeri baştan ayıramadığında görsel yüklenirken metin aşağı kayar ve kullanıcı okuduğu satırı kaybeder. Üçüncü taraf betikleri ise ayrı bir hesap; her biri için "bu ne kadar yavaşlatıyor" sorusunun sayısal bir cevabı olsun.
Testi Emülatörde Bırakmayın
Tarayıcının cihaz simülasyonu düzeni gösterir, deneyimi göstermez. Dokunma isabetini, kaydırma akıcılığını, klavye açıldığında formun ne olduğunu ancak gerçek cihazda görürsünüz.
- Ağı yavaşlatarak en az bir tur atın; ekibin ofis bağlantısı kullanıcıların ortalaması değil.
- Telefonu tek elle tutarak deneyin, iki elle test edilen arayüz kolay geçer.
- Ekran okuyucuyla ana akışı bir kez baştan sona geçin; başlık sırası ve odak yönetimi çoğu hatayı burada gösterir.
Bu üç turun her biri yarım saat sürüyor ve genelde tasarım incelemesinden daha fazla iş çıkarıyor.