Mobil Kullanıcı Deneyiminde Kalıcı Değişimler ve Geçici Modalar

Mobil arayüzlerde son on yılda değişen şeylerin bir kısmı yerleşti, bir kısmı moda gibi gelip geçti. Kalıcı olanların ortak yanı şu: ekran alanı, ağ gecikmesi ve parmağın büyüklüğü fiziksel sınırlar koyuyor, bu sınırlardan doğan çözümler kaldı. Aşağıda her alışkanlığın hangi sınırdan doğduğunu ve nerede ters teptiğini tek tek ayırıyorum.

İçerik paritesi: mobil sürüm ayrı bir site değil

Erken dönemde mobil, ayrı bir alan adı altında duran kırpılmış bir kopyaydı. Masaüstündeki tablo mobilde yoktu, ürün açıklaması yarıya iniyordu, formun üç alanı kayboluyordu. Bunun bitmesi dönemin en kalıcı kazancı. Arama motorları sayfayı mobil sürümü üzerinden değerlendirmeye başlayınca eksik içerik doğrudan görünürlük kaybına dönüştü, kullanıcı tarafında ise beklenti zaten netti: aynı bilgi, hangi cihazdan bakarsam bakayım.

Burada sık yapılan bir karıştırma var. "Mobilde sadeleştir" tavsiyesi genelde içeriği silmek diye okunuyor, oysa sadeleşmesi gereken düzendir. İki farklı şeyden bahsediyoruz: bilgi paritesi ile düzen paritesi. Bilgi aynı kalır, sunum sırası değişir. Masaüstünde yan yana duran üç sütun mobilde alt alta gelir, ikincil ayrıntı bir katman aşağı iner, sık kullanılan eylem yukarı çıkar. Aynı metinde hem "mobilde içeriği azaltın" hem "içerik paritesi şart" yazıyorsa biri yanlış, ve yanlış olan birincisi.

Sabit menülerin piksel faturası

Sabit üst başlık, alta yapışan gezinme çubuğu, yukarı dön düğmesi, çerez bandı. Her biri tek başına makul görünür, sorun toplamda çıkar. Sayı verelim: tipik bir telefonda görünüm alanı 375x667 CSS piksel, tarayıcı çubuğu düşünce geriye yaklaşık 600 piksellik dikey alan kalır. Üstte 56, altta 56 piksellik iki çubuk 112 piksel eder, yani kullanılabilir yüksekliğin yaklaşık beşte biri. Çerez bandını da ekleyin, kullanıcı içerik için kalan alanın yarısını kaybetmiş olur ve bu kayıp sayfa boyunca sürer, çünkü çubuklar kaydırmayla gitmez.

Buradan basit bir bütçe kuralı çıkıyor: aynı anda tek bir sabit katman. Sabit alt menü istiyorsanız üst başlık kaydırmada gizlensin, yukarı dön düğmesini alt menünün içine alın, çerez bandını ilk etkileşimde kapatın.

Sabit elemanların bir de ölçüm tarafı var. Mobil tarayıcılarda adres çubuğu kaydırma sırasında gizlenip geri açıldığı için 100vh gerçek görünür yüksekliği vermez; ekranın altına sabitlediğiniz çubuk tarayıcı arayüzünün altında kalır ya da sayfa gereksiz kayar. Bunu dvh ve svh birimleriyle çözersiniz, eski tarayıcı desteği gerekiyorsa visualViewport üzerinden ölçüp bir CSS değişkenine yazmak yeterli. Bu iş için üçüncü parti bir kütüphane kurmaya gerek yok.

Hamburger menü ve gizlemenin bedeli

Hamburger simgesi dar ekranda yer kazandırır, bu doğru. Kazandırdığı yerin karşılığı keşfedilebilirlik. Görünmeyen bir bağlantı aranmaz; kullanıcı sitede ne olduğunu bilmediği için menüyü açma ihtiyacı bile duymaz. Üstelik her hedefe erişim en az iki dokunuşa çıkar, ilk dokunuş da bir animasyonun bitmesini bekletir.

Hamburger menüyü tek başına ana gezinme olarak bırakmam. En çok kullanılan üç ya da dört hedef dışarıda, görünür durur; geri kalan derinlik simgenin arkasına girer. Hangi üçü olduğunu tahmin etmeye de gerek yok, günlüklerde zaten yazıyor.

Dokunma hedeflerinde iki referans var ve ikisi de yıllardır aynı yerde duruyor: Apple 44 punto, Google'ın Material yönergesi 48 dp öneriyor. Pratikte kritik olan hedefin kendi boyutundan çok hedefler arasındaki boşluk. Yan yana duran iki 48 piksellik düğme arasında birkaç piksel varsa, kullanıcı yine yanlışına basar.

Hız: CDN neyi çözer, neyi çözmez

CDN, statik dosyaların kullanıcıya coğrafi olarak yakın bir noktadan servis edilmesini sağlar. Görsel, yazı tipi ve betik dosyalarında bunun etkisi gerçektir ve ölçülür. Ama mobilde yavaşlığın kaynağı çoğu zaman burada değildir.

CDN'in çözmediği üç şey var. Birincisi HTML'i üreten tarafın yavaşlığı: sayfa her istekte veritabanına gidip hesaplanıyorsa ilk baytın gelme süresi CDN'den bağımsız olarak yüksek kalır. İkincisi işleme engelleyen betikler; dosya ne kadar hızlı inerse insin, tarayıcı onu çalıştırana kadar ekrana bir şey çizmez. Üçüncüsü ve mobilde en belirleyicisi cihazın işlemcisi. Orta seviye bir telefon, aynı JavaScript'i geliştiricinin dizüstü bilgisayarından birkaç kat yavaş çalıştırır. Bu yüzden ölçümü kendi makinenizde değil, işlemciyi kasten yavaşlatarak ve yavaş bir bağlantı profiliyle yapın; sahadan toplanan gerçek kullanıcı verisi varsa öncelik onda.

Görsel tarafında kazanç hâlâ en ucuz yerde duruyor: doğru boyutta üretilmiş, AVIF ya da WebP olarak servis edilen bir görsel, üzerine width ve height yazılmış olarak gelirse hem daha hızlı iner hem de yüklenirken sayfanın altındaki metni zıplatmaz.

Masaüstünü mobilin gölgesinde bırakmayın

Mobil öncelikli çalışmak bir düşünme sırasıdır, bir tasarım hedefi değil. Dar ekranda ne kaldığını sorarak başlarsınız, çünkü orada eleme yapmak zorundasınız. Ama o elemenin sonucunu 1400 piksellik ekrana olduğu gibi taşırsanız ortada tek sütun içerik, iki yanında devasa boşluk ve fare kullanıcısını hiç ilgilendirmeyen kocaman dokunma hedefleri kalır.

Fare parmaktan hassastır, imleç üzerine gelme durumu vardır, ekran geniştir. Kırılım noktalarında yalnızca ölçek değil bilgi yoğunluğu da değişmeli: masaüstünde gezinme açık dursun, tablo tablo kalsın, ikincil bilgi bir katman aşağı inmek yerine yanda görünsün.

Kalıcı olanla geçici olanı ayırmanın ölçütü de burada. Bir çözüm somut bir sınırdan doğuyorsa kalır: içerik paritesi indeksleme ve beklentiden, dokunma hedefi parmağın boyutundan, görsel optimizasyonu ağdan. Sırf yeni göründüğü için benimsenen ne varsa, ilk ölçümde kendini ele veriyor.