Komut Dışı Arayüzler: Niyet Tahmini Nerede İşe Yarar, Nerede Yaramaz

Komut dışı arayüz fikri yeni değil. Jakob Nielsen 1993'te Communications of the ACM'de yayımladığı yazısında, kullanıcının açık talimat vermediği, sistemin davranışı gözleyip niyeti çıkarmaya çalıştığı bir etkileşim kuşağını tarif etmişti. Otuz yıl sonra sensörler ve model altyapısı hazır, ama asıl soru hâlâ cevapsız: sistem yanlış tahmin ettiğinde ne oluyor?

Komut dışı ne demek, ne demek değil

Komut tabanlı arayüzde bir işin olması için kullanıcının onu ifade etmesi gerekir. Menüden seçersin, tuşa basarsın, komutu yazarsın. Sistem bekler.

Komut dışı arayüzde bekleme yoktur. Sistem bağlamı, geçmiş davranışı, konumu, bakış yönünü ya da elindeki başka sinyalleri okur ve eyleme kendisi karar verir. Telefonun gece modu, arama kutusunun sen yazarken sonucu tazelemesi, e-posta istemcisinin "buna cevap vermeyi unuttun" demesi, hepsi bu ailedendir.

Burada sık yapılan bir karışıklık var: dokunmatik jestler ya da sesli komutlar komut dışı sayılmaz. "Hey, ışığı aç" demek, ifade biçimi değişmiş bir komuttur. Komut dışılığın ölçütü girdinin doğallığı değil, kararın kimde olduğudur.

Nielsen'in listesindeki asıl gerilim

Nielsen'in ayrımı on iki boyut üzerinden kurulur ve bunların çoğu tarif niteliğindedir: girdi kanalı sayısı artar, sıra alma ortadan kalkar, arayüz ekrandan çıkıp mekâna yayılır. Ama listedeki bir madde diğerlerinden farklı, çünkü bir bedeli var: kontrolün kullanıcıdan sisteme kayması.

Bu madde, aynı yazarın sezgisel değerlendirme ilkelerinden biriyle doğrudan çatışır. "Kullanıcı denetimi ve özgürlüğü" ilkesi, kullanıcının yanlışlıkla girdiği durumdan işaretli bir çıkış kapısı bulabilmesini ister. Sistem eylemi kendi başlattığında kullanıcı o duruma girdiğini bile fark etmemiş olabilir. Çıkış kapısını, varlığından haberdar olmadığın bir odada aramak zordur.

Dolayısıyla komut dışılık "daha kullanıcı odaklı" bir şey değil. Otomasyonla denetim arasında yapılan bir takas ve her takasta olduğu gibi kârlı olup olmadığı hesaplanabilir.

Hesabı yapalım

Sistemin niyeti doğru okuma oranına p diyelim. Kullanıcının aynı işi elle yapmasının maliyeti c, sistemin yanlış kararını fark edip geri almanın maliyeti r olsun. Otomasyon ancak şu koşulda kazandırır:

(1 - p) × r < c

Yani geri alma maliyeti, elle komut vermenin c / (1 - p) katından ucuz olmalı. Kulağa cömert bir sınır gibi geliyor, sayı koyunca öyle olmadığı görülüyor: p = 0,95 ise geri alma, işi elle yapmaktan en fazla 20 kat pahalı olabilir. Bir tıklamayla açacağın menüyü sistem senin yerine açıyorsa ve yanlış açtığında kapatıp doğrusunu bulman yirmi tıklamadan uzun sürmüyorsa, kârdasın.

Formül bir yerde tamamen çöker: geri alınamayan eylemlerde r sonsuza gider. Gönderilmiş e-posta, çekilmiş ödeme, paylaşılmış konum. Orada p ne olursa olsun eşitsizlik sağlanmaz. Bu yüzden niyet tahmini eylemi hazırlamalı, tetiklememeli: taslağı yaz, göndermeyi kullanıcıya bırak.

Göz takibi örneği

Göz takibi komut dışı arayüzlerin klasik vitrin örneği ve aynı zamanda en iyi uyarı hikâyesi. Bakış, dikkatin nereye gittiğini gerçekten söyler. Sorun şu ki bakış aynı zamanda merakı, tereddüdü ve dalgınlığı da söyler; sistem bunları seçim niyetinden ayıramaz. Literatürde bu duruma Midas dokunuşu problemi deniyor: baktığın her şey seçildiği için kullanıcı gözünü nereye koyacağını bilemez hale gelir.

Göz takibini girdi kanalı olarak değil, ölçüm aracı olarak çok daha güvenilir bulurum. Bir sayfada başlığın mı yoksa görselin mi önce okunduğunu öğrenmek için mükemmel; kullanıcının hangi butona basmak istediğini anlamak için değil. Bu ayrım pratikte şuna denk düşer: veriyi tasarım kararını beslemek için topla, çalışma zamanında eylem tetiklemek için değil.

Peki ne yapmalı

Komut dışı davranışı ürüne sokarken üç sorunun cevabını baştan yazılı hale getirmek işi kolaylaştırıyor. Sistem yanıldığında kullanıcı bunu nereden anlayacak? Geri alma kaç adım sürüyor? Aynı yanlış tahmin üst üste üçüncü kez olursa davranış kendini kapatıyor mu?

Son madde en çok atlanan. Uyarlanabilir bir sistem, kullanıcının düzeltmelerini de sinyal saymalı; geri alma her seferinde aynı öneriyi tazeliyorsa sistem uyarlanmıyor, ısrar ediyor demektir. Kod tarafında bu, öneri motoruna "reddedildi" olayını da yazmak kadar basit bir iş, ama analitik şemalarında genellikle sadece kabul edilenler kaydediliyor. Reddedilenleri saymayan bir model, kendi hata oranını hiçbir zaman öğrenemez.

Komut dışı arayüzlerin geleceği bu yüzden ekranların kaybolmasında değil. Sistemin kendi belirsizliğini ölçebilmesinde ve emin olmadığında sormayı bilmesinde.