Bir Arayüz Neden Kendi Geçmişini Saklar?

Çoğu arayüz bugünü göstermekte çok iyi. Güncel değer, güncel dosya, güncel ayar. Fakat o noktaya nasıl gelindiğini çoğu zaman saklıyor.

Bir şey ters gidene kadar bu çok önemli görünmüyor.

Bir blok siliniyor. Dosyanın adı değişiyor. Bir ayar açık durumdan kapalıya geçiyor. Ekran bana şimdi neyin doğru olduğunu söylüyor. Ne değiştiğini, kimin değiştirdiğini veya geri dönüp dönemeyeceğimi her zaman söylemiyor.

Bence bu eksik geçmiş, arayüze duyduğum güveni etkiliyor.

Mevcut durum hikâyenin yalnızca yarısı

Bir ekran genellikle son durumu gerçek kabul ediyor. Bu mantıklı. Kimse her yerde zaman damgaları ve eski sürümler görmek istemez.

Yine de bazen mevcut durum yetmiyor.

Bir fiyat değiştiyse ne zaman değiştiğini bilmek isteyebilirim. Bir belge düzenlendiyse kimin yaptığını merak edebilirim. Bir şeyi yanlışlıkla sildiysem boş ekranla değil, on saniye önceki durumla ilgileniyorum.

Sürüm geçmişi, geri al, etkinlik kaydı, çöp kutusu ve geri yükleme gibi özellikler burada birbirine yaklaşıyor. Hepsi ekranın arkasındaki yolun bir kısmını koruyor.

Bu yolun sürekli görünmesi gerekmiyor. Kullanıcı ihtiyaç duyduğunda orada olması yeterli.

Geri al, eylemin hissini değiştiriyor

Nielsen Norman Group'un kullanıcı kontrolü ve özgürlüğü ilkesi undo ve redo desteğini öneriyor. W3C'nin bilişsel erişilebilirlik rehberi de benzer şekilde kullanıcının işini kaybetmeden önceki noktaya dönebilmesini istiyor.

Benim ilgimi çeken komutun kendisi değil. O komutun, kararı vermeden önce yarattığı his.

Bir eylemin geri alınabilir olduğunu biliyorsam denemeye daha açığım.

Bir bloğun yerini değiştiririm. Bir şeyi yeniden adlandırırım. Bir ayarı kurcalarım.

Bu güvence olmadığında küçük bir hareket bile kalıcı hissedebilir. Arayüz, kullanıcı daha yeterli bilgiye sahip değilken kesinlik beklemeye başlar.

Her şey yolunda giderken geri al neredeyse görünmez. Belki de bu yüzden değerini kolay küçümsüyoruz.

Sürüm geçmişi işe yarıyor çünkü hafıza pek güvenilir değil

Google Docs önceki sürümleri incelemeye, değişikliği kimin yaptığını görmeye ve eski bir sürümü geri yüklemeye izin veriyor. Wikipedia'da ise revizyon geçmişi sistemin çok daha görünür bir parçası.

Bu araçlar hata sonrasında işe yarıyor. Bence başka bir işleri daha var.

Hatırlamak zorunda bırakmıyorlar.

Dün hangi paragrafın değiştiğini aklımda tutmam gerekmiyor. Sistem gösterebilir. final, final2, final-gerçekten-final diye on iki dosya kaydetmek zorunda da kalmıyorum. En azından teoride.

Birden fazla kişinin aynı şeyi değiştirebildiği ürünlerde bu daha önemli.

“Kapalı” yazan bir ayar tek başına pek bir şey anlatmıyor. Hep mi kapalıydı? Ben mi kapattım? Sabah başka biri mi değiştirdi? Sistem otomatik mi yaptı?

Bazen minicik bir geçmiş satırı, uzun bir açıklamadan daha faydalı oluyor.

Fark görünümü aslında ne olduğunu anlatabiliyor

Sürüm listesi bir şeyin değiştiğini söyler. Karşılaştırma görünümü neyin değiştiğini gösterir.

Arada önemli bir fark var.

Bir diff ekranı eklenen, çıkarılan veya yeri değişen içeriği görünür hâle getirebilir. “Bu dosya farklı” bilgisini inceleyebileceğim bir değişikliğe dönüştürür.

Bu fikir kodun dışında da işe yarıyor.

Bir fiyat tablosu düşünün. CMS makalesi. Takım yetkileri. Bir dashboard ayarı. Mevcut ekran açık olabilir ama değişikliğin kendisi görünmez kalabilir.

Bunu seviyorum çünkü geçmişi bir yönetim özelliği değil, bilgi tasarımı problemi gibi ele alıyor.

Amaç bütün veritabanı hareketlerini göstermek değil. Kullanıcının merak ettiği değişikliği açıklamak.

Geçmiş çok hızlı biçimde kalabalığa dönüşebilir

Burada açık bir sorun var.

Her kart “4 dakika önce düzenlendi” derse, her buton eski durumunu gösterirse ve her alanın altında kayıt tutulursa ekran yorucu olur.

Geçmiş, belirsizliği çözdüğü için değerli. Belirsizlik yokken göstermek gürültü yaratıyor.

Bu yüzden her ürünü bir denetim paneline çevirmek istemem.

Kullanıcının hangi anlarda “Burada ne oldu?” diyeceğini düşünürdüm.

Silme sonrasında olabilir. Ortak bir düzenleme sonrasında olabilir. Ayar değiştiğinde olabilir. Ödeme durumu güncellendiğinde olabilir. İçerik yayınlandığında olabilir.

Geri kalan yerler sessiz kalabilir.

Yıkıcı bir işlem sonrasında çıkan geçici geri al mesajlarını bu yüzden seviyorum. Ana ekranı sade bırakıyor, kısa süreli bir dönüş kapısı açıyor. Sorun, bazen bu kapının fazla hızlı kapanması. Beş saniyelik bir snackbar teknik olarak geri alınabilir olabilir. Rahat hissettirmeyebilir.

Bazı geçmiş görünmeli, bazı geçmiş yalnızca geri getirilebilmeli

Ben burada iki şeyi ayırmayı yararlı buluyorum.

Görünür geçmiş, mevcut durumu açıklar. “12 dakika önce Maya düzenledi” bilgisi, değişiklik şu anda önemliyse anlamlıdır.

Geri getirilebilir geçmiş ise bir sorun çıkana kadar gizli kalabilir. Sürüm paneli veya çöp kutusunun her gün ana ekranda yer kaplaması gerekmez.

Bu ayrım arayüzü hafif tutabilir.

Silme eylemine bakışımı da değiştiriyor. Onay penceresi, işlemden önce kesin olmamı istiyor. Çöp kutusu ise işlemden sonra fikrimi değiştirmeme izin veriyor.

Rutin işlemlerde çoğu zaman ikincisini tercih ederim.

Nielsen Norman Group da onay pencerelerini özellikle sonucu ciddi olan ve geri alınamayan eylemler için öneriyor. Bir şey kolayca geri getirilebiliyorsa her tıklamayı tehlikeli hissettirmek bazen güvenlikten çok sürtünme yaratıyor.

Arayüz, kullanıcının hatırlayamadığını hatırlamalı

Bir bağlantı daha var.

Eski kişisel sitelerde kararların izleri sayfaları daha yaşanmış hissettiriyordu. Modern bir ürün çok daha tutarlı olmak zorunda. Yine de izlerin hâlâ önemli olabileceğini düşünüyorum.

Dekoratif izlerden bahsetmiyorum. İşe yarayanlardan.

Bunu kim değiştirdi? Önceden burada ne vardı? Geri getirebilir miyim? Bu durum neden dünden farklı?

Ürün bu sorulara cevap verebildiğinde mevcut ekran biraz daha az gizemli oluyor.

Her arayüzün bütün geçmişini görmek istemiyorum. Çoğu zaman yalnızca bugünü görmek yeterli.

Ama hata yaptığımda veya bir şey ben dokunmadan değiştiğinde, geçmişin hâlâ bir yerde durmasını istiyorum.