Content-to-Chrome: Arayüzde Chrome'un Gerçek Maliyeti

Content-to-chrome oranı, ölçülüp hedef konulabilecek bir sayıymış gibi anlatılıyor. Öyle bir sayı yok. Terim, Jakob Nielsen'in tarayıcı ve uygulama arayüzü için kullandığı chrome kelimesinden geliyor ve bir gerilimi adlandırıyor: ekranın ne kadarı içeriğe, ne kadarı içeriğe ulaştıran araçlara gidiyor. Gerilimi adlandırmak işe yarar, oranı düşürmeyi hedef ilan etmek yaramaz.

Maliyet oransal değil, sabit

Bir üst çubuk kaç piksel yer kaplıyorsa ekran büyüdükçe de o kadar yer kaplar; değişen tek şey bunun toplam içindeki payı. 360x640 bir telefonda üstte ve altta 56 piksellik iki çubuk 112 piksel eder, dikey alanın yüzde 17,5'i. Aynı iki çubuk 1080 piksel yüksekliğindeki bir pencerede yüzde 10,4'e iner.

Fark iki katın altında, yani tek başına bakınca çarpıcı değil. Asıl mesele şu: masaüstünde chrome'u yatay eksene taşıyabilirsiniz, yan panel ya da geniş üst çubuk, ve orada yer bol. Mobilde kıt olan eksen dikey ve chrome tam oraya oturuyor. Aynı bileşen iki platformda aynı pikseli yiyor ama aynı şeyi maliyetlendirmiyor.

Gizlemek maliyeti yok etmez, taşır

Hamburger menü piksel maliyetini sıfırlar, karşılığında etkileşim maliyeti üretir: ek bir dokunuş, bir animasyon beklemesi ve daha pahalısı, öğenin orada olduğunu hatırlama yükü. Bu takas her zaman kötü değil. Kötü ya da iyi olması kullanım sıklığına bağlı.

Günde birkaç kez kullanılan bir işlev görünür kalır. Ayda bir açılan bir ayar menüye girer, girmesi de doğrudur. Sıklığı bilmiyorsanız zaten karar veremezsiniz, o zaman soru chrome oranı değil, ölçüm eksikliği.

Bir ekranda dönüşüm düştüğünde bunu ilk anda chrome miktarına bağlamam. Aynı ekranda başlığın ne söylediği, formun kaç alan istediği ve sayfanın kaç saniyede açıldığı çoğunlukla daha büyük paya sahip. Chrome tartışması ölçülmesi zor olduğu için değil, gözle görüldüğü için öne çıkıyor.

Masaüstünde hamburger meselesi

Hamburger menünün masaüstünde kötü olduğu o kadar sık tekrarlandı ki gerekçesi unutuldu. Gerekçe basit: yer varken saklarsanız karşılığında hiçbir şey almazsınız. Beş başlıklık bir menüyü 1400 piksel genişlikte ikonun arkasına koymak saf kayıp.

Ama kırk başlıklık bir menüyü olduğu gibi sermek de kayıp. Oradaki sorun ikon değil, bilgi mimarisi. Menü ikonu, çözülmemiş bir gruplama problemini arayüzde erteleme aracına dönüşmüşse, ikonu kaldırmak da işe yaramaz.

İkon tek başına etiket değil

Chrome'u sıkıştırmanın en yaygın yolu etiketleri atıp ikon bırakmak. Kalp, yıldız, üç nokta ve büyüteç dışında bunun güvenle çalıştığı ikon sayısı çok az. Basit bir sınama var: ekibinizden birine ikonu gösterip ne yaptığını sorun, ürünü hiç bilmeyen birine sorarsanız daha da iyi. Cevap gecikiyorsa etiket gerekiyor demektir.

Yerleşimi breakpoint'e bırakın, ayrı arayüz yazmayın

Chrome'un yeri ekran genişliğiyle değişmeli: mobilde alt çubuk, masaüstünde yan panel. Bunu aynı bileşeni farklı düzenlerle yerleştirerek yapın. İki ayrı arayüz yazmak ilk gün hızlı görünür, altı ay sonra iki ayrı yerde unutulan menü maddeleri olarak geri gelir. Aynı veriyi besleyen tek bileşen, düzeni CSS'e bırakan bir yapı, bakımda kendini ödüyor.

Karar sırası şu: önce bu öğe ne sıklıkla kullanılıyor, sonra bulunamazsa kullanıcı ne kaybediyor, en sonda kaç piksel yer kaplıyor. Çoğu tartışma sondaki soruyla başladığı için içerik ve chrome birbirinin rakibi gibi konuşuluyor. Değiller; ikisi de aynı işin parçası ve yanlış olan yalnızca sıralama.