Konu Başlıkları
Yükleniyor...

Arayüzde Chrome: Kabuk İçerikten Ne Kadar Çalıyor?

Chrome ve İçerik Dengesi: Arayüz Kabuğunu Ölçmek

Arayüzde chrome, ekrandaki asıl veriye ait olmayan ama ona erişmeni sağlayan kabuktur: menü çubukları, sekmeler, başlık ve alt bilgi, kaydırma çubukları. Sorun tek bir kabukta değil, kabukların üst üste binmesinde. Bir telefonda içeriğe gelene kadar işletim sistemi, tarayıcı ve sitenin kendi kabuğu sırayla pay alır.

Kabuk tek katman değil

Chrome'u tek bir arayüzün süsü gibi düşünmek yanıltıcı. Kullanıcı senin tasarladığın kabuğu diğerlerinin üstüne yığılmış halde görüyor:

  • İşletim sistemi: durum çubuğu, görev çubuğu, bildirim alanı.
  • Tarayıcı: adres çubuğu, sekmeler, yer imleri satırı.
  • Uygulama: menü, şerit, araç çubukları, durum satırı.
  • Site: üst menü, arama kutusu, çerez bildirimi, alt bilgi, yandan giren sohbet balonu.

Bir e-tabloda bu birikimin bedeli sayılabilir: her araç çubuğu satırı, aynı anda görünen veri satırı sayısını düşürür. Kullanıcı kaydırmak zorunda kaldığında kaybettiği şey piksel değil, iki satırı yan yana karşılaştırabilme imkânı.

Ekran bütçesini tahmin etmeyi bırak

Kabuğun ne kadar yer kapladığı konusunda herkesin bir hissi var, ölçümü olan az. Hedef cihazda sayfayı aç, kaydırmadan bir ekran görüntüsü al, asıl içeriğin kapladığı yüksekliği toplam yüksekliğe böl. Tek bir sayı çıkar ve o sayı tartışmayı bitirir.

Eşik nerede? Katı bir kural yok, ama içerik ilk ekranın yarısının altına düşüyorsa kabuk fazla yer tutuyor demektir. Ölçümü masaüstünde ve telefonda ayrı ayrı yapmak gerekiyor, çünkü 360 piksel genişliğinde bir ekranda çerez bildirimi ve sabitlenmiş üst menü ilk görünen alanın neredeyse tamamını yiyebiliyor.

Gizlemek mi, küçültmek mi?

Fazla kabuğu azaltmanın iki yolu var: öğeyi gizlemek ya da küçültmek. Gizlemeyi küçültmekten daha riskli bulurum. Küçültülmüş bir araç çubuğu görünür kalır, kullanıcı orada olduğunu bilir, tek hamlede erişir. Hamburger menüsünün arkasına alınan gezinti ise piksel kazancını etkileşim maliyetine çevirir: fazladan bir dokunuş, üstüne menünün içinde ne olduğunu hatırlama yükü.

Peki öğe gerçekten kullanılmıyorsa? O zaman doğru cevap gizlemek değil, çıkarmak. Gizleme çoğu projede kullanılmayan bir şeyi korumanın kibar yolu olarak iş görüyor ve arayüzde hakkında karar verilmemiş bir yığın bırakıyor. Kullanım verisi yoksa gizleme kararı da zaten tahmine dayanıyor, önce ölçümü yap.

Kaybolan kabuk, bozulan düzen

Mobil tarayıcılar kaydırmada adres çubuğunu küçültüp geri açar. Kabuk açısından kazanç, düzen açısından baş ağrısı: görünür alanın yüksekliği sayfanın ortasında değişir.

CSS tarafında bunun en bilinen sonucu 100vh. Bu birim büyük görünür alanı, yani kabuk gizliyken kalan yüksekliği baz alır. Adres çubuğu açıkken tam ekran olsun diye yazdığın bölüm taşar, altındaki düğme görünmez. Yerine 100dvh kullanılır, dinamik yükseklik kabuk açılıp kapandıkça güncellenir. Taşma riskini hiç istemiyorsan 100svh en küçük görünür alanı verir; bir miktar boşluk kalır ama hiçbir şey ekranın dışına çıkmaz.

Sabitlenmiş alt çubuklar aynı sorunun ikinci yüzü. Kabuk kaydırmayla hareket ederken position: fixed öğeler bazı tarayıcılarda titrer ya da yanlış yere oturur. Tasarım dosyasında bunu göremezsin, gerçek cihazda beş saniyede görürsün.

Kabuğun hak ettiği yer

Bütün bunlar kabuğu düşman ilan etmek değil. İyi kabuk iki iş yapar. Aynı işlevi her sayfada aynı yerde tutarak öğrenmeyi bir kereye indirir, ve kaçış yolu verir.

Tarayıcının geri düğmesi bu yüzden webin en değerli chrome öğesi. Kullanıcı yanlış bir yere girdiğinde oradan çıkmayı senin tasarımından öğrenmek zorunda değil, garanti bir kapı var. Geri davranışını kendi yönlendirmesiyle bozan tek sayfa uygulamaları en çok o garantiyi kaybettikleri için can sıkıcı.

Yani soru "kabuk mu içerik mi" değil. Her kabuk öğesi için sorulacak soru şu: çaldığı ekran alanı ve dikkat karşılığında kullanıcıya bir karar ya da bir çıkış imkânı veriyor mu? Vermiyorsa yeri menünün içi değil, çöp kutusu.