Mobil UX Standartları ve Yerleşen Kalıpların Maliyeti

Akıllı telefonun ilk yıllarında her uygulama kendi gezinme fikrini deniyordu; bugün mobil arayüzler birbirine benziyor. Alt navigasyon barı, hamburger menü, aşağı çekip yenileme. Yerleşen her kalıp bir tartışmayı kapattı, ama kapattığı yerde bir maliyet bıraktı: sabit bar tarayıcı çubuğuyla, parolasız giriş uygulama içi tarayıcıyla, izin kutuları birbiriyle çakışıyor.

Standart mı, yoksa sadece tekrar mı?

Hamburger menünün ne işe yaradığını bugün kimseye anlatmak gerekmiyor. Bilinir olmak ile iyi olmak ise aynı şey değil. Hamburgerin arkasındaki her bağlantı bir dokunuş uzakta duruyor, alt bardaki dört öğe ise sürekli görünür. Bu iki kalıbın aynı cümlede "mobil standardı" diye anılması, aralarındaki farkı gizliyor.

Peki bu kalıplar neden bu kadar yayıldı? Kullanıcı için en iyisi oldukları kanıtlandığı için mi, yoksa tasarım toplantısındaki tartışmayı bitirdikleri için mi? İkincisi bana daha yakın duruyor. Navigasyonun gerçekte ne kadar kullanıldığını ölçmek zahmetli; herkesin yaptığını yapmak bedava.

Pratik ayrım şu: kullanıcının her oturumda yaptığı üç dört şey alt barda kalsın, seyrek dokunulan hesap ayarları ve kurumsal sayfalar hamburgerin içine girsin. Alt bara beş öğeden fazlasını sıkıştırmak, dokunma hedeflerini parmak genişliğinin altına indirir ve kazandığın görünürlüğü geri verir.

Sabit alt bar ile tarayıcı çubuğu aynı pikselleri istiyor

Mobil tarayıcıda ekranın kullanılabilir yüksekliği sabit değil. Kullanıcı aşağı kaydırınca adres çubuğu küçülür, yukarı kaydırınca geri gelir. CSS'teki 100vh bu hareketi görmez; çubuk açıkken bile en büyük yüksekliği verir. Sonuç, sabit alt barın ya viewport'un altına taşması ya da bir buton yüksekliği kadar kesilmesidir. Tasarım dosyasında kusursuz görünen ekran, gerçek cihazda ödeme butonunu yarım gösterir.

Mobil bir düzeni 100vh üzerine kurmam. dvh dinamik yüksekliği izler, svh en küçük halini garanti eder; eski tarayıcılar için önce vh yazıp arkasından bunları vermek yeterli. Çentikli cihazlarda alt barın altına env(safe-area-inset-bottom) kadar boşluk bırakmazsan, ana ekran göstergesi butonun üstüne oturur. Bunu JavaScript ile ölçüp yeniden hesaplayan çözümler hâlâ dolaşıyor; her kaydırmada yerleşim tetikledikleri için ucuz görünen ama pahalı olan yol onlar.

Parolasız giriş uygulama içi tarayıcıda kırılıyor

Passkey desteği mobilde gerçekten iyi bir gelişme: kullanıcı şifre yazmıyor, parmak izi ya da yüz tanımayla oturum açıyor, kimlik bilgisi alan adına bağlı olduğu için sahte sayfaya girmesi mümkün değil. Buraya kadar herkes hemfikir.

Sorun, aynı metinlerde ayrı bir başlık altında şikâyet edilen uygulama içi tarayıcıyla birleştiğinde çıkıyor. Kullanıcı bağlantıya sosyal uygulamanın içinden dokunduğunda sayfa sistem tarayıcısında değil, uygulamanın gömülü görünümünde açılır. Bu görünümlerin bir kısmı passkey arayüzünü ve şifre yöneticisi otomatik doldurmasını desteklemez; desteklese bile oturum çerezi sistem tarayıcısıyla paylaşılmadığı için kullanıcı zaten giriş yapmış olduğu hesaba yeniden giriş yapmak zorunda kalır. Yani sürtünmeyi sıfırlamak için kurulan mekanizma, trafiğin en çok geldiği yerde çalışmıyor.

Buradan çıkan kural basit: parolasız akışı tek yol yapma. Passkey'in yanında e-posta ya da SMS ile tek kullanımlık kod bırak, gömülü tarayıcı tespit ettiğinde "tarayıcıda aç" seçeneğini görünür yere koy. Kampanya bağlantılarının nereden tıklandığını ölçmeden bu ihtimali hesaba katmayan her giriş ekranı, dönüşüm kaybını yanlış yere yazar.

Mobilde gizlenen içerik nereye gidiyor?

"Tam siteyi göster" bağlantısı hayatımızdan çıktı, doğru. Responsive yaklaşım masaüstündeki her işlevi mobilde de erişilebilir kıldı. Ama içerik eşitliği çoğu zaman gerçek bir sadeleştirme değil, görsel bir sadeleştirme oldu.

Şunu kendi sayfanda kontrol et: mobilde gizlenen bölüm HTML'den çıkarılıyor mu, yoksa yalnızca display:none ile görünmez mi yapılıyor? İkincisiyse o tablo, o galeri ve ona bağlı script hâlâ indiriliyor demektir. Kullanıcı hiç görmediği içerik için veri harcar, sen de sadeleştirdiğini sanırsın. Akordeon içine katlanan metin de aynı kapıya çıkar; ekranı kısaltır, ağırlığı kısaltmaz. Mobil için asıl karar, neyi göstermeyeceğin değil, neyi göndermeyeceğindir.

Overlay yığını ve izin isteme zamanı

Bir haber sitesini telefondan açtığında ilk ekranda kaç katman var? Çerez izni, bülten kutusu, uygulamayı indir bandı, bazen bildirim izni. Her biri ayrı bir ekipte ayrı bir hedefe bağlı olduğu için kimse toplamına bakmıyor, kullanıcı ise toplamını yaşıyor.

Bildirim izni bu yığının en zayıf halkası. Kullanıcı henüz tek bir cümle okumadan sorulduğunda cevap neredeyse her zaman ret olur ve tarayıcılar reddedilen izni bir daha sormanı kolayca vermez. Üstelik iOS tarafında web bildirimi yalnızca ana ekrana eklenmiş bir uygulamada çalışır; normal bir sekmede o kutuyu göstermek, hiçbir zaman gelmeyecek bir izin için ilk izlenimini harcamak demektir. İzni eyleme bağla: kullanıcı bir siparişi takip etmek ya da bir konuyu izlemek istediğinde sor.

Bu beş başlık aynı yere çıkıyor. Mobilde standart diye anılan şeylerin çoğu ölçülmüş olan değil, tekrar edilmiş olan. Tekrar kötü değil, kullanıcının öğrenme yükünü gerçekten azaltıyor; ama her kalıbın kendi sayfanda bir maliyeti var ve o maliyet ancak cihazda, gerçek bağlantı hızında ve gerçek girişten gelen kullanıcıyla görünür.