Mobil Tasarımı Farklı Cihaz, Tarayıcı ve Pazarlara Hazırlamak

Bir mobil arayüzün asıl sınavı amiral gemisi telefonda değil, üç yaşındaki orta segment bir cihazda ve zayıf bir şebekede başlar. Yeni pazarlara açılırken performans, cihaz çeşitliliği, tarayıcı dağılımı ve yerelleştirme aynı anda masaya geliyor. Peki dördüne birden mi bakmak gerekiyor, yoksa bir sırası var mı?

Test ettiğiniz cihaz sizin cihazınız değil

Geliştirme makinesi hızlı, ofis ağı hızlı, sonuç yanıltıcı. Sayfanın gerçek davranışını görmek için geliştirici araçlarındaki ağ kısıtlamasını açıp yavaş bir bağlantıda deneyin, mümkünse ucuz bir Android cihazda parmağınızla dokunun. Aradaki fark saniyelerle ölçülüyor ve o saniyeler doğrudan terk oranına yazılıyor.

Yükün büyük kısmı çoğu sitede görsellerde duruyor.

• Görselleri tek bir büyük dosya olarak servis etmek yerine srcset ile boyut varyantları üretin; telefon 320 piksel genişliğinde gösterdiği bir görseli 2000 piksel indirmesin.
• WebP ya da AVIF gibi modern formatlar aynı görsel kaliteyi belirgin biçimde daha küçük dosyayla veriyor.
• Ekranın dışında kalan görselleri geciktirmeli yükleyin.
• JavaScript paketinde ne olduğuna bakın. Tek bir tarih kütüphanesi için yüzlerce kilobayt taşımak yaygın bir durum.
• Statik dosyaları kullanıcıya coğrafi olarak yakın bir CDN üzerinden dağıtın; uzaktaki tek bir sunucuda gecikme, sayfa ne kadar hafif olursa olsun kalıyor.

Cihaz çeşitliliği ve ayrı sürüm tuzağı

Yaygın tavsiye şu: girişte cihazı algıla, zayıfsa sadeleştirilmiş sürümü sun. Bu tavsiyenin kendi içinde bir çelişki var. Zayıf ve az bilinen cihazlar, tam da user agent dizesini güvenilir biçimde tanıyamadığınız cihazlar; tespit en çok ona ihtiyaç duyduğunuz yerde yanılıyor.

İkinci bir maliyet daha var. Ayrı sürüm, test matrisini ikiye katlıyor. On cihaz ve beş tarayıcı denediğiniz bir arayüzde elli kombinasyon varken, iki sürümle bu sayı yüze çıkıyor. Ekip aynı kalırsa test derinliği yarıya iner, yani sadeleştirilmiş sürümü ekleyerek düzeltmeye çalıştığınız hataların bir benzerini başka yerden davet etmiş olursunuz.

Tek kod tabanı ve yetenek tespiti daha sağlam duruyor: cihazın kim olduğunu değil, aradığınız özelliğin var olup olmadığını sorun, yoksa çalışan bir taban kalsın. Arayüz o zaman tanımadığınız cihazda da bozulmadan, sadece daha sade çalışır (ayrı mobil sürümü bugün nadiren haklı çıkan bir tercih buluyorum).

Tarayıcı dağılımı ülkeye göre değişiyor

Chrome, Safari ve Firefox üçlüsü her pazarda aynı ağırlıkta değil. Samsung Internet bazı bölgelerde ciddi paya sahip, Opera Mini ve benzeri sıkıştırmalı tarayıcılar hâlâ kullanılıyor. Sıkıştırma kipi sayfayı sunucuda işleyip cihaza sadeleşmiş bir çıktı gönderdiği için, istemci tarafında kurduğunuz etkileşimlerin çoğu orada hiç çalışmaz. Arayüzünüz JavaScript olmadan en azından okunabilir kalıyor mu, bunu bir kez denemeye değer.

Hangi tarayıcılarda test edeceğinize tahminle karar vermeyin. Analitik verinizde tarayıcı ve sürüm kırılımı zaten duruyor; hedeflediğiniz ülkeleri filtreleyip bakın, liste çoğu zaman beklediğinizden farklı çıkıyor. Elinizde o pazardan gerçek trafik yoksa uzaktan cihaz test servisleri işi görür.

Yerelleştirme çeviriden ibaret değil

Metin uzuyor. Aynı düğme etiketi Almancada ya da Fincede belirgin biçimde büyüyebiliyor ve sabit genişlikte tasarlanmış bir düğme çeviriyle birlikte kırılıyor. Arapça eklendiğinde düzenin tamamı ayna görüntüsüne dönüyor, bu da ikon yönünden kaydırma davranışına kadar birçok kararı yeniden açıyor.

Asıl kayıp ise sıradan form alanlarında yaşanıyor:

• Posta kodu her ülkede yok. Zorunlu alan yaparsanız o ülkeden sipariş alamazsınız.
• Ad ve soyadı iki ayrı alana bölmek birçok kültürde karşılıksız kalıyor; tek bir isim alanı daha güvenli.
• Telefon numarasını istemci tarafında katı bir kalıba zorlamak geçerli numaraları eliyor.
• Tarih biçimini ve ondalık ayırıcıyı elle kurmak yerine platformun yerelleştirme desteğine bırakın; virgül ile nokta karışması ödeme ekranında sessizce yanlış tutar üretebiliyor.

Renk ve simge tercihlerinin kültüre göre değiştiği doğru, ama bu fark çoğu projede anlatıldığı kadar sık karşımıza çıkmıyor. Kullanıcıyı asıl kaybettiren, doldurulamayan bir adres formu oluyor.

Sıra

Baştaki soruya dönelim. Dördü de gerekli, ama aynı anda değil. Önce ölçüm: ziyaretçilerin hangi ülkeden, hangi cihaz ve tarayıcıyla geldiğini bilmeden yapılan her optimizasyon tahmine dayanıyor. Sonra performans, çünkü açılmayan sayfanın yerelleştirilmiş olması kimsenin işine yaramaz. Cihaz ve tarayıcı uyumu bunun doğal devamı, zaten aynı testlerin içinden çıkıyor. Yerelleştirmeyi en sona bırakın demiyorum; düzeni ondan önce esnek kurun ki çeviri geldiğinde arayüzü baştan yazmak zorunda kalmayın.