Büyük Hipermetinlerde Gezinme ve Breadcrumb'ın Sınırı
Nielsen 1989'da HyperCard uygulamalarını incelerken yön bulmayı üç soruya indirmişti: neredeyim, buradan nereye gidebilirim, buraya nasıl geldim. Aradan geçen zamanda arayüzler değişti, sorular değişmedi. Değişen tek şey, bu üç sorunun her birini farklı bir mekanizmanın cevapladığını unutmuş olmamız.
Üç soru, üç ayrı mekanizma
Sorular birbirine benziyor ama aynı bilgiyi istemiyorlar. "Neredeyim" yapısal bir soru: kullanıcı içeriğin bütünü içinde hangi noktada durduğunu soruyor. "Buraya nasıl geldim" ise tarihsel bir soru, yapıyla ilgisi yok; kullanıcının kendi izini soruyor. "Buradan nereye gidebilirim" üçüncüsü ve en çok ihmal edileni, çünkü cevabı sayfanın kendisinde değil komşuluklarında.
Bu ayrımı kurmadan araç seçmek, üç sorunun hepsini tek bileşene yükletmeye çıkıyor. Breadcrumb yapıyı gösterir, geçmiş listesi izi gösterir, menü ve ilgili içerik bağlantıları komşuluğu gösterir. Biri diğerinin yerine geçtiğinde bir soru cevapsız kalıyor ve kullanıcı bunu kaybolmuşluk olarak yaşıyor.
Breadcrumb'ı geçmiş listesinden daha güvenilir buluyorum, çünkü kullanıcının yolunu değil yapının kendisini gösteriyor. Geçmiş listesi kullanıcının hatasını da sadakatle tekrarlar: yanlış dala girip dönmüşsen, geçmiş sana o yanlış dalı da yol olarak sunar. Yapı ise nereden gelirsen gel aynı cevabı verir. Ama bu güvenilirlik bir varsayıma dayanıyor ve o varsayım her sistemde tutmuyor.
Breadcrumb ağaç varsayar
Breadcrumb'ın anlamlı olabilmesi için her düğümün tek bir üstü olması gerekiyor. Yani içerik yapısının ağaç olması. Hipermetin ise tanımı gereği ağaç değil, çizge: bir kart birden fazla karttan bağlanabilir, bir makale iki kategoriye birden ait olabilir.
Bir düğümün iki üstü olduğu anda breadcrumb ikiye ayrılıyor. Ya kullanıcının izlediği yolu gösterirsin, ki o zaman elindeki şey adı değişmiş bir geçmiş listesidir ve aynı sayfa iki ziyaretçide iki farklı yol gösterir. Ya da düğüme sabit bir kanonik üst atarsın, ki o zaman kullanıcı A yolundan gelmişken breadcrumb ona B yolunu gösterir. İkincisi daha az zararlı, ama zararsız değil: kullanıcı breadcrumb'ın son öğesine tıklayıp geldiği yere değil, hiç görmediği bir listeye düşer.
Pratikte doğru olan, çizgeyi olduğu gibi kabul edip kanonik üstü içerik tarafında bilinçli seçmek. Her içeriğe bir birincil kategori atanır, breadcrumb onu gösterir, çoklu aidiyet ise sayfa içindeki ilgili kategori bağlantılarıyla ayrıca verilir. Yolu takip eden dinamik breadcrumb üretmek kolay görünüyor ama aynı sayfayı her ziyarette farklı gösterdiği için mekânsal hafızayı bozuyor.
Derinlikle genişlik arasındaki takas
"Beşten fazla hiyerarşi seviyesi kullanıcıyı yorar" tavsiyesi yaygın, tek başına da doğru. Yalnız bu tavsiye tek başına verildiğinde neyin bedeliyle geldiğini söylemiyor.
Hesap basit. Her seviyede b seçenek sunan, d seviye derinliğinde bir yapı bd düğüme ulaşır. On bin içerikli bir arşivi üç seviyede kapsamak istiyorsan seviye başına yaklaşık 22 seçenek gerekiyor, çünkü 223 yaklaşık 10.600 eder. Dört seviyeye çıkarsan seviye başına 10 seçenek yetiyor. Derinliği kısaltmak seçenek sayısını azaltmıyor, sadece onu yatay eksene taşıyor.
Yani sığ yapı bedava değil. Kullanıcı beş tıklama yerine üç tıklama yapıyor ama her tıklamada yirmi başlığı okuyup ayırt etmek zorunda kalıyor. Derin yapıda her adım kolay, adım sayısı fazla. Ölçüt tıklama sayısı değil, adım başına verilen kararın zorluğu: yirmi seçenekten biri açıkça sizin aradığınızsa geniş menü iyi çalışır, yirmi başlık birbirine benziyorsa aynı menü tıkanma noktasına dönüşüyor.
Landmark ve bölge hissi
1989'un HyperCard uygulamaları bunu farklı yollardan çözmüştü. The Manhole bir hikaye evreniydi ve kullanıcı orada zaten keşfetmek için bulunuyordu; kaybolmak sorun değil, oyunun kendisiydi. Time Table of History bir arşivdi ve kullanıcı belirli bir tarihi arıyordu. Whole Earth Catalog ise kataloglama mantığıyla kurulmuştu, gezinme kategoriler üzerinden yürüyordu. Aynı gezinme çözümü üçünde birden doğru olmuyor.
Ortak olan şey landmark fikri: her yerden ulaşılabilen, tanınabilir sabit noktalar. Ana ekran, harita, kategori girişi. Landmark'ın işlevi kullanıcıya yol göstermek değil, kaybolduğunda başa dönme maliyetini sabit tutmak. Bu güvence olmadan kullanıcı denemeyi bırakıyor ve sadece bildiği yolu kullanıyor.
Bölge hissi de aynı işe yarıyor. Farklı bölümlerin farklı renk, tipografi ya da düzen imzası taşıması, kullanıcının konumunu okumadan anlamasını sağlıyor. Burada ölçü kaçırmak kolay: bölümler arası fark okunur olmalı ama sitenin tek bir sistem olduğu hissini bozmamalı. Aynı bileşenlerin farklı renk değişkenleriyle kullanılması genelde yeterli, bölüme özel ayrı tasarım dili gerekmiyor.
Geri dönüşün tutarlılığı
Geri dönüş mekanizmasının yeri her ekranda aynı olmalı, bu neredeyse tartışmasız. Daha az konuşulan şey, tarayıcının geri düğmesiyle arayüzün kendi geri düğmesinin çakışması.
Tek sayfa uygulamalarında bu çakışma sık yaşanıyor. Arayüz içinde bir panel açılıyor, adres değişmiyor, kullanıcı paneli kapatmak için tarayıcının geri düğmesine basıyor ve sayfadan tamamen çıkıyor. Çözüm arayüze ikinci bir geri düğmesi eklemek değil; durum değişikliğini adrese yazmak. Panel açıldığında adres değişirse tarayıcının geri düğmesi zaten doğru işi yapar ve kullanıcının öğrenmesi gereken yeni bir kural kalmaz.
Uzun sayfalarda da benzer bir eksik var. Yirmi ekran boyu bir metinde başlıklara atlayabilmek gerekiyor, ama sadece yukarı doğru değil. İçindekiler bağlantısına tıklayıp bir bölüme atlayan kullanıcının geri dönebilmesi lazım; bu, sayfa içi hedeflere de adres verilerek çözülüyor.