Flat mı Deep mi: Site Hiyerarşisinde Derinliğin Gerçek Maliyeti

Site yapısı tartışması çoğu zaman tek bir sayıya indirgenir: flat hiyerarşi kullanıcıyı iki tıkta hedefe götürür, deep hiyerarşi yorar. Oysa bir seviye eklemek kapasiteyi katlarken tıklama maliyetini yalnızca bir birim artırır. Asıl soru kaç tık değil, kullanıcı yanlış dalı seçtiğinde ne olduğu.

Aradaki tek değişken

Flat yapıda ana sayfanın altında çok sayıda kategori yan yana durur ve yol iki ya da üç seviyede biter. Deep yapıda ana kategori sayısı azdır, derinlik dört beş seviyeye kadar iner. İkisi arasındaki fark aslında tek bir tercih: aynı içerik hacmini genişliğe mi yayıyorsun, yoksa derinliğe mi?

Derinlik logaritmik büyür, genişlik büyümez

Her seviyede ortalama 7 dal açtığını varsay. Üç seviyede 343 sayfaya, dört seviyede 2401 sayfaya yer açarsın. Yani 2400 sayfalık bir arşivi dörde böldüğün an kullanıcının yolu yalnızca bir tık uzar.

Seviye	Dal başına 7	Dal başına 10
2	49	100
3	343	1.000
4	2.401	10.000

Aynı 2400 sayfayı iki seviyeye sıkıştırmak istersen? Kategori sayısıyla kategori içi sayfa sayısının çarpımı 2400 olmak zorunda, yani 30 ana kategori ve her birinde 80 sayfa gibi bir dağılım çıkar. Otuz maddelik bir ana menü kimsenin bir bakışta tarayabileceği bir şey değil, özellikle telefonda. Derinliğin maliyeti doğrusal, genişliğin maliyeti ise kullanıcının bir ekranda kaç şeyi karşılaştırabildiğiyle sınırlı. Bu yüzden "derin yapı kullanıcıyı yorar" cümlesi, tek başına, savunulabilir bir gerekçe değil.

Yanlış dalı seçmenin bedeli

Derin yapıda dördüncü tıkta aradığını bulamayan kullanıcı dört tık kaybetmez; nerede yanlış yaptığını bilmediği için baştan başlar. Kayıp burada. Flat yapıda hata anında görünür, menü zaten önünde duruyor.

Derinliğe çıkıyorsan geri dönüş yolunu önceden döşemen gerekiyor:

• Breadcrumb, sadece bulunduğun yeri değil, bir üst seviyeye dönüşü de tıklanabilir hale getirir.
• Site içi arama, derin yapıda dekoratif bir kutu değil, ana navigasyonun ikinci yarısıdır.
• Çok görüntülenen alt kategorileri üst seviyeye kısayol olarak çıkarmak, derinliği seçili yerlerde kırar.

Arama logları bu işin en ucuz verisi. Kullanıcıların arama kutusuna yazdığı kelime menünde hiç geçmiyorsa sorun derinlikte değil, kategori adında.

Flat yapının kendi içindeki çelişki

Flat hiyerarşinin iki artısı sık sık bir arada sayılır: kategori adları daha spesifik olabilir, çünkü her şey ana menüde durur. Ve menü kalabalıklaşınca başlıklar birbirine karışır. Bu ikisi aynı yönde çalışmaz. Adları ne kadar spesifikleştirirsen o kadar çok başlığa ihtiyacın olur, başlık sayısı arttıkça da bir içeriğin iki kategoriye birden yakışma olasılığı yükselir. Genişliği seçtiysen kategori adlarının üzerinde fazladan çalışmayı da seçmişsindir, bu bedava gelen bir avantaj değil.

Hiyerarşiyi adrese gömme

Menü ağacını URL'ye birebir yansıtmak ilk bakışta düzenli görünür: /kategori/alt-kategori/alt-alt/sayfa. Sonra bir seviye eklemen ya da bir kategoriyi ikiye bölmen gerekir ve altındaki bütün adresler değişir. Yönlendirme tablosu şişer, dış bağlantılar eski yola gider, aynı içerik iki adresten görünür. Kategoriyi menüde ve breadcrumb'da tut, adresi düz bırak: /urun-adi, /makale-basligi. Hiyerarşiyi yeniden kurmanın maliyeti böylece bir menü düzenlemesine iner. Veritabanında ağacı parent_id ile tutmak zaten yeterli, adres bu ağaca bağlı olmak zorunda değil.

Hangisi, ne zaman

Ana kategori sayın on civarında kalıyorsa ve adlar birbirine girmiyorsa flat yapı doğru tercih; derinlik eklemek sadece gereksiz bir ara katman olur. Kategori sayısı yirmiyi geçtiği noktada flat yapı artık sade değil, uzun bir liste. Orada derinliğe çıkmak daha doğru, ama breadcrumb ve çalışan bir site içi arama olmadan çıkmaya değmez.

Trafiğinin büyük kısmı aramadan geliyorsa, yani kullanıcılar ana sayfadan değil doğrudan derin bir sayfadan içeri giriyorsa, menü derinliği zaten ikincil bir sorun. O durumda emeği menü ağacına değil, sayfadan sayfaya giden ilgili içerik bağlantılarına ve breadcrumb'a ayır: kullanıcı siteye nereden girdiyse oradan yukarı ve yana gezinebilsin.