Hypertext, Tek Yönlü Bağlantılar ve Gezinme Tasarımı

Hypertext’i ayrı bir teknoloji gibi anlatmak bugün zor, çünkü web’in kendisi o. Ted Nelson’ın 1965’te tarif ettiği fikirle tarayıcınızdaki bağlantı arasında ise sanılandan büyük bir fark var: Nelson iki yönlü bağ öngörmüştü, web tek yönlüsünü seçti. Kırık bağlantılardan içerik taşımalarına kadar gezinme tarafında uğraştığımız işlerin çoğu o seçimin faturası.

Nelson’ın bağı, web’in bağlantısı

1965’te ortaya atılan fikir basitti: metin doğrusal olmak zorunda değil, parçalar birbirine bağlanabilir ve okuyucu kendi yolunu seçer. Xanadu tasarımında bu bağ çift taraflıydı, yani bir belge kendisine kimin bağlandığını bilirdi.

Web bunu almadı. HTML bağlantısı tek yönlü çalışır: kaynak hedefi bilir, hedef kaynağı bilmez. Sonucunu her içerik taşımasında görürsünüz. Bir sayfanın adresini değiştirirken kime dokunduğunuzu hedeften okuyamazsınız, bütün arşivi taramak zorunda kalırsınız. Çift yönlü bağda bu iş gerçek gelen bağlantı sayısı kadar, tek yönlüde ise belge sayısı kadar maliyetlidir; arşiv büyüdükçe fark açılır. 301 yönlendirmesi bu eksiğin yamasıdır, çözümü değil: kopan bağı onarmaz, üstünü örter.

HyperCard neyi kanıtladı, neyi kanıtlamadı

Apple’ın HyperCard’ı fikri ilk kez elle tutulur hale getirdi. Kartlar arası geçiş, basit betikler ve görsel düzenleme sayesinde programcı olmayan insanlar kendi etkileşimli belgelerini kurdu. Okullarda çocuklar bununla dallanan hikâyeler yazdı, şirketler iç dokümantasyonunu kart destelerine taşıdı.

Buradan genellikle “hypertext bilgiye erişimi hızlandırır” genellemesi çıkarılır ve koşulu atlanır. Bir HyperCard destesi kapalı ve küçük bir kümeydi: bağlantıların hepsi aynı dosyanın içindeydi, hedefin var olduğu garantiydi, desteyi tek bir kişi tutuyordu. Üç varsayım da web ölçeğinde geçersiz. Kapalı bir yardım sisteminde iyi işleyen gezinme mantığını olduğu gibi geniş bir siteye taşımak çoğu zaman burada tökezler.

Kaybolma sorunu kılık değiştirdi

Eski hypertext literatürünün ana derdi kullanıcının belge ağında kaybolmasıydı. İki tasarım kolu tartışılırdı: gezinmeyi ayrı bir ekranda toplamak ya da bağlantıyı doğrudan metnin içine gömmek. Hangisinin daha memnun ettiği sorusunun genel bir cevabı yok, çünkü cevap göreve bağlı.

Okumak için gelinen içerikte metin içi bağlantı kazanır, çünkü bağlam bağlantının kendisindedir; okuyucu neye tıkladığını cümleden anlar. İşini yapmak için gelinen bir sistemde ise sabit ve kalıcı gezinme kazanır, çünkü kullanıcı keşfetmeye değil bir yere varmaya çalışıyor. İkisini karıştıran arayüzler, yani her paragrafı bağlantıyla delen belge sayfaları ve metnini menüye indirgeyen uygulama ekranları, iki dünyanın da kötü yanını alır.

Bağlantıyı bakılabilir tutmak

Bir bağlantı ağı kurulduğu gün değil, üçüncü yılında sınanır. Pratikte işe yarayanlar kısa bir liste:

• Adresi başlığa değil kalıcı bir kimliğe bağlayın; başlık değişir, adres yerinde kalsın.
• Bağlantı denetimini insana bırakmayın; 404 taraması gecelik bir işle biter.
• Taşınan her adres için yönlendirme kaydı tutun ve o kaydı temizlik adına silmeyin.
• Bağlantı metnini hedefe göre yazın; “buraya tıklayın” ekran okuyucuda bağlamsız kalır.

Gelecek tarafında yapay zekâ destekli öneri ve kişiselleştirme çokça konuşuluyor. Bunlar bağlantının yerini almıyor, üstüne biniyor: öneri motoru, kullanıcının bulamadığı bağı tahmin etmeye çalışır. Bağ doğru kurulmuşsa öneriye az iş kalır, kurulmamışsa öneri de yanlış yeri gösterir.