Responsive Tasarımda Kullanıcı Deneyimi Nerede Çatlıyor
Responsive tasarım artık bir tercih değil, varsayılan. Asıl mesele, aynı kod tabanı üç farklı ekranda çalışırken kullanıcı deneyiminin nerelerde çatladığı. Çatlaklar genelde aynı birkaç yerde çıkıyor ve çoğu, tasarım dosyasında değil ilk gerçek cihazda görünür oluyor.
Satır uzunluğu masaüstünde bozulur, mobilde değil
Mobilde endişe edilen şey genelde metnin sığmaması. Pratikte problem ters yönde çalışır: geniş ekranda tam genişliğe yayılan bir paragraf 120 karakteri aşan satırlar üretir, göz satır sonundan satır başına dönerken yerini kaybeder. Matbaadan gelen kabul satır başına 45-75 karakter civarında. Bunu her kırılma noktası için yeniden hesaplamana gerek yok, metin bloğuna max-width: 65ch vermen yeterli, ch birimi zaten kullanılan yazı tipinin karakter genişliğine bağlı.
100vh mobilde tam ekran demek değil
Yükseklik verirken en sık düşülen yer burası. Mobil tarayıcılarda adres çubuğu kaydırma sırasında gizlenip geri geliyor, yani görünür alan sabit değil. 100vh çoğu tarayıcıda bu iki halin büyüğüne göre hesaplanır: sayfa ilk açıldığında bölümün alt kısmı adres çubuğunun altında kalır. Çağrı düğmesini oraya koyduysan kullanıcı düğmeyi görmez.
Karşılığı CSS'te var: svh küçük görünümü, lvh büyük görünümü, dvh ise kaydırmayla birlikte değişen anlık yüksekliği verir. Tam ekran bir açılış bölümünde 100svh güvenli taraftır, çünkü en dar durumu baz alır. Eski tarayıcılar için height: 100vh satırını üstte bırak, altına 100svh yaz, desteklemeyen tarayıcı ikinciyi yok sayar.
Aynı görseli üç ekrana göndermek
Responsive düzen görselin ekranda küçülmesini sağlar, indirilen dosyayı küçültmez. 2000 piksel genişliğindeki bir kapak görseli telefona da 2000 piksel olarak iner, sonra 380 piksele sıkıştırılıp gösterilir. srcset ve sizes ile tarayıcıya seçenekleri bildirmek bunu çözer. Arka plan görsellerinde sorun ölçek değil kırpmadır: background-size: cover dar ekranda görselin kenarlarını keser, önemli olan şey merkezde değilse kadraj dışında kalır. Odak noktasını object-position ya da eşdeğeriyle sabitlemek gerekir.
Dokunma ve fare aynı anda
Hover ile açılan menü, dokunmatik ekranda ya hiç açılmaz ya da ilk dokunuşu yutar. Ayrımı cihaz sınıfına göre değil girdi biçimine göre yap: @media (hover: hover) hover davranışını yalnızca gerçekten hover destekleyen cihazlara verir. Klavyeyle gezinme de aynı bileşenin ikinci hali, sonradan eklenen bir özellik değil. Hover ile açılan her şeyin odakla da açılması gerekir.
Tek kod tabanı bakımı ucuzlatır, testi değil
Responsive tasarımın klasik gerekçesi maliyet: ayrı mobil sürüm yerine tek kod tabanı, tek dağıtım. Yazma tarafında doğru. Test tarafında yüzey küçülmez, çarpım kuralına girer: üç kırılma noktası ve sekiz kritik sayfa 24 kontrol demek, yatay ve dikey çevrim de sayılırsa 48. Ayrı bir mobil sürümde de aynı sayfaları iki kez gezerdin. Yani kazanç geliştirme ve dağıtım aşamasında gerçek, kalite kontrolde değil.
Bunun pratik sonucu şu: kırılma noktası sayısını içerik gerektirdiği için artır, cihaz adları listesine uymak için değil. Her yeni kırılma noktası bütün kritik akışlara bir sütun ekler.
Hangi ekranı önceliklendireceğine veri karar verir
Mobil öncelikli çalışmak iyi bir varsayılan, çünkü dar ekran seni içeriği sıraya dizmeye zorlar. Ama varsayılan, kural değil. Trafiğin ağırlıklı olarak mesai saatlerinde masaüstünden geliyorsa, ki kurumsal panellerde ve B2B araçlarında sık görülür, mobil öncelikli bir düzen masaüstü kullanıcısını seyrek bilgili bir ekrana mahkum eder. Analitikte cihaz dağılımına değil, dönüşümün hangi cihazda tamamlandığına bak. İkisi çoğu zaman farklı çıkar.
Ekran boyutuna göre farklı içerik göstermek ayrı bir tartışma (bu yaklaşımı çoğu durumda gereksiz buluyorum): mobilde gizlemeye karar verdiğin bölüm genelde masaüstünde de gerekli değildir.
Kaynaklar