Deferred Hypertext: İsteği Şimdi Al, Cevabı Sonra Gönder

Bazı istekler cevabı hemen beklemez. Kullanıcı ne aradığını kısa bir metinle söyler, sistem arka planda çalışır, sonuç bir süre sonra başka bir kanaldan gelir. Ertelenmiş köprü metin (deferred hypertext) bu takasın adı: etkileşim maliyetinden kazanıp gecikmeden harcarsın. Takasın kârlı çıkıp çıkmadığı tek bir şeye bağlı, cevabın kullanıcıya hâlâ işe yarar halde ulaşıp ulaşmadığına.

İstek ile cevabın ayrıldığı yer

Sıradan bir bağlantıda tıklama ve sonuç aynı oturumda olur: isteği gönderen el, cevabı aynı ekranda alır. Ertelenmiş kurguda bu zincir ikiye ayrılır. İstek bir kanaldan girer, arka planda bir iş çalışır, cevap başka bir kanaldan ve başka bir zamanda çıkar.

Üç parçadan biri genelde tasarım toplantısında hiç konuşulmaz: teslim kanalı. İsteğin biçimi ve arka plandaki işin ne yaptığı nispeten belli olur da, cevabın SMS mi e-posta mı bildirim mi olacağı sonraya bırakılır. Oysa kullanıcının o cevabı hangi cihazda, hangi ortamda, ne kadar dikkatle açacağını belirleyen şey tam olarak bu seçim.

Metin tabanlı servislerden kalan desen

Yöntemin çıkış noktası dar ekranlı telefonlar ve tuş takımıydı. Kullanıcı bir şehir adını SMS olarak gönderiyor, karşılığında ilk tren kalkışlarını kısa bir mesaj halinde alıyordu. Tarayıcıdan aynı bilgiye ulaşmak onlarca tuş vuruşu demekken burada tek kelime yetiyordu.

Cihazlar değişti, desen yerinde duruyor:

• Mobilde denk gelinen uzun yazının "sonra oku" listesine ya da e-okuyucuya gönderilmesi
• Büyük bir dışa aktarmanın tarayıcıda beklenmeyip hazır olduğunda e-postayla iletilmesi
• Telefondan seçilen belgenin ofisteki yazıcı kuyruğuna düşmesi

Üçünde de kullanıcı isteği saniyeler içinde bırakıyor, cevabı kendisine uygun cihazda topluyor. "Raporunuz hazır olduğunda e-posta göndereceğiz" cümlesi, yirmi yıl önceki tren tarifesi SMS'inin aynısı.

Gecikme bütçesi saniyeyle değil karar penceresiyle ölçülür

Ertelenmiş bir akışta "ne kadar gecikme kabul edilebilir" sorusunun teknik bir cevabı yok. Cevabı kullanıcının kararı veriyor. Tren kalkışını soran kişinin penceresi dakikalarla sınırlı, çünkü bilgiyi istasyona yürürken kullanacak. Okuma listesine atılan yazının penceresi günlerce açık kalabilir. Bir raporda pencereyi genelde mesai saati çiziyor.

Pencere kapandıktan sonra gelen cevap yavaş değil, zararlı. Kullanıcı sorunu çoktan başka yolla çözmüştür; elinde kalan şey kapatması gereken bir bildirimdir ve o kanala bir dahaki sefere daha az güvenir. Bu yüzden her ertelenmiş akışın "bu cevap kaç dakika sonra değersizleşir" sorusuna sayısal bir karşılığı olmalı. Sayı yoksa kuyruk önceliklendirilemez, zaman aşımı da yazılamaz.

Pratik karşılığı şu: süreyi istek anında kullanıcıya söyle, aşıldığında cevabı sessizce göndermek yerine gecikmeyi haber ver. Cevabın başına da kullanıcının gönderdiği metni aynen koy. İki satırlık iş, ama mesajı açan kişi hangi isteğin karşılığına baktığını tahmin etmek zorunda kalmaz; eşleştirme için ayrıca bilet numarası uydurmaya da gerek kalmaz.

Belirsizliği tek turda çöz

Senkron bir arayüzde kullanıcının ne demek istediğini sormak neredeyse bedava. Otomatik tamamlama, açılır liste, "şunu mu demek istediniz" satırı; hepsi aynı oturumda, milisaniyeler içinde döner. Ertelenmiş kurguda aynı soru çok farklı bir fatura çıkarır, çünkü her netleştirme turu gecikmenin tamamını bir kez daha ödetir. Dört dakikada cevap veren bir servis araya tek bir evet/hayır sorusu soktuğunda sekiz dakikaya çıkar, ve o sekiz dakika az önce çizdiğin karar penceresinin dışına taşabilir.

Buradan tek bir tasarım kuralı çıkıyor: soru sorma, tahmin et. En olası eşleşmenin cevabını gönder, yanına ikinci ve üçüncü adayları kısa birer satır olarak ekle. Kullanıcı yanlış tahmini okuduğu anda doğrusunu da görmüş olur, ikinci tura hiç gerek kalmaz.

Toleransın nerede gerektiğini de tahminle değil kayıtla bulursun. Eşleşmeyen girdileri olduğu gibi sakla: kısaltmalar, harf hataları, sistemde hiç karşılığı olmayan kelimeler. Bu kayıt kullanıcı testinde üretebileceğinden daha geniş bir varyasyon listesi verir, çünkü gerçek istekleri gerçek aceleyle yazılmış halde içeriyor.

Nerede kurulur, nerede kurulmaz

Ertelenmiş bağlantı üç koşul birlikte sağlandığında kazanır: istek birkaç kelimeyle ifade edilebiliyorsa, cevap ek etkileşim gerektirmiyorsa, işleme artı teslim süresi karar penceresinin belirgin şekilde altındaysa. Üçü de sağlanıyorsa kullanıcıya sıradan bir sayfadan daha azıyla daha fazlasını vermiş olursun.

Biri eksikse kurgu geri teper. Cevap üzerinde filtreleme, sıralama, karşılaştırma yapılacaksa ertelenmiş kanal her adımda bir tur daha ister; o noktada sıradan bir arayüz her koşulda daha hızlıdır. Soruyu kısa bir metne sığdırmak mümkün değilse de aynı şey geçerli. Ertelemenin değeri cevabı ucuzlatmasından değil isteği ucuzlatmasından geliyor, istek zaten pahalıysa erteleyecek bir şey kalmıyor.