Hypertext Bağları ve Bilgiye Erişim: Bağ Sayısının Sınırı

Hypertext'in temel vaadi basit: metnin içindeki bir kelimeden başka bir metne atlarsın. Bu vaat kırk yılda web'in kendisine dönüştü, ama yolda bir varsayım sessizce kabul edildi: bağ eklemek erişimi kolaylaştırır. Kolaylaştırdığı yer de var, zorlaştırdığı yer de. İkisini ayıran şey bağın sayısı değil, kullanıcının o bağa bakarken nerede durduğunu bilip bilmemesi.

Web bağı tek yönlüdür, bu bir tasarım kararıydı

Bir <a href> yalnızca kaynağı hedefe bağlar. Hedef sayfa, kendisine kimin bağlandığını bilmez. Ted Nelson'ın Xanadu tasarımında bağlar iki yönlüydü; hedef taşındığında ona işaret eden her yer haberdar olurdu. Dexter referans modeli de benzer bir şey öneriyordu: bağları içerikten ayrı bir katmanda tut, böylece yapı tek yerden yönetilsin.

Web ikisini de almadı ve karşılığında ölçek kazandı. Bir sayfaya bağ kurmak için karşı tarafın izni, hatta haberi gerekmiyor; web'in bu kadar hızlı büyümesinin sebebi büyük ölçüde bu. Bedeli ise bakımda ödeniyor, üstelik gecikmeli olarak.

Her bağ bir karar noktasıdır

Jeff Conklin, 1987'de IEEE Computer'da yayımlanan hypertext derlemesinde iki problemi adıyla koydu: yönelim kaybı (disorientation) ve bilişsel ek yük (cognitive overhead). Birincisi kullanıcının bağlantı ağı içinde nerede olduğunu kaybetmesi, ikincisi ise "bu bağa girsem mi" sorusunun okumayı sürekli bölmesi.

Bir paragrafın ortasına konan bağ, okuyucuya şunu söyler: burada duraklaman gerekebilir. Beş tanesi arka arkaya geldiğinde metin artık okunmuyor, taranıyor. Bu yüzden gövde içindeki bağ ile bölüm sonundaki "devamı için" bağını aynı şey saymak yanlış; ilki okumayı böler, ikincisi okuma bittikten sonra devreye girer.

Yönelimi geri vermenin ucuz yolları

Kullanıcının nerede olduğunu anlaması için karmaşık bir gezinme haritası gerekmiyor. Sayfa başlığının, tıklanan bağın metniyle örtüşmesi tek başına çok iş görür: gittiğin yerin beklediğin yer olduğunu doğrular. Kırıntı navigasyonu (breadcrumb) hiyerarşideki konumu gösterir. Bağ metninin kendisi de hedefi söylemeli, çünkü ekran okuyucu kullananlar bağları çoğu zaman ayrı bir liste olarak, çevresindeki cümleden kopuk şekilde dinler. "Buraya tıklayın" o listede hiçbir şey ifade etmez.

Bakım maliyeti sayfa başına değil, site başına büyür

200 sayfalık bir yardım merkezinde her sayfaya beş ilgili bağ koyarsan ortada 1000 bağ olur. Bir sayfanın adresini değiştirdiğinde kaç bağın kırıldığını o sayfaya bakarak öğrenemezsin, çünkü sayfa kendisine kimin işaret ettiğini tutmuyor. Cevabı ancak 1000 bağın tamamını tarayarak bulursun. Yani tek bir sayfayı taşımanın maliyeti, sayfanın büyüklüğüyle değil, sitenin büyüklüğüyle ölçeklenir.

Bu yüzden "ilgili içerik" bloklarını elle doldurmam. Etiket ya da sorgu üzerinden üretilen bir liste, hedef silindiğinde kendiliğinden küçülür; elle yazılmış bağ ise kimse fark edene kadar 404'e bakmaya devam eder. Elle bağ kurmayı, gerçekten o cümleye ait olan, otomatikleştirilemeyecek bağlantılara saklamak gerekir.

Arşivde adres bir söz demektir

Uzun süre saklanacak içerikte asıl sorun depolama değil, adreslerin sabit kalması. Bir yazının adresi başlığına göre üretiliyorsa, başlık her düzeltildiğinde adres kayar ve dışarıdan verilmiş bütün bağlar kırılır. Akademik yayıncılığın DOI ile çözdüğü şey tam olarak bu: tanımlayıcıyı içerikten ve konumdan ayır.

Pratikte üç şey yeter. Adres bir kez üretilsin ve içerik değişse de değişmesin. Taşıma zorunlu olduğunda eski adres 301 ile yenisine gitsin, silinmesin. Ve bağ yapısı, mümkün olduğunca içerikten türeyen bir katmanda tutulsun ki hedef taşındığında tek yerde güncellensin.

Bağ eklemek bir içerik kararı gibi görünür, ama aslında bakım kararıdır. Bugün eklediğin her bağ, hedefi yaşadığı sürece değer üretir; hedef taşındığında ya da kaybolduğunda bakım borcuna dönüşür. Bağ sayısını arttırmak yerine, kırıldığında haberdar olacağın türden bağ kurmak daha iyi bir hedef.