Kullanıcı Kontrolü ve Özgürlüğü: Geri Alma, İptal ve Çıkış
Kullanıcı kontrolü ve özgürlüğü pratikte üç düğmeye iner: geri, iptal, geri al. Zor olan bunları koymak değil, hangi işlemin gerçekten geri alınabilir olduğuna karar vermek. Onay kutusuyla geri alma arasındaki sınır yanlış çizildiğinde arayüz ya herkesi yavaşlatır ya da telafisi olmayan bir kaybı sessizce mümkün kılar.
Çıkış yolu görünür değilse yok sayılır
Kullanıcı bir akışa girdiğinde çıkışın nerede olduğunu tahmin etmek zorunda kalmamalı. Mobilde sol üstteki geri oku, webde üst köşedeki kapatma simgesi, çok adımlı formlarda adımlar arası gezinme: bunların yeri tartışmaya açık değil, göz zaten oraya gidiyor. Yeni bir konum icat etmek yerine yerleşik olanı kullanın.
İptali onaydan uzağa koyun, ama gizlemeyin. Gri, küçük ve köşeye sıkıştırılmış bir "Vazgeç", kullanıcıya çıkmasının istenmediğini söyler. O his oluştuktan sonra geri kalan her tasarım kararı güven kaybını kapatmaya çalışmakla geçer.
Geri alma mı, onay kutusu mu
Bu ikisi aynı işi yapmaz, birbirinin yerine geçemez. Onay kutusu kullanıcıyı işlemden önce durdurur, geri alma işlemden sonra kurtarır. Ve tekrarlanan onaylar birkaç gün içinde otomatik tıklamaya dönüşür, yani en sık kullanılan yerde en az koruma sağlar.
Ayrım şurada: etki sistemin içinde kaldığı sürece doğru araç geri almadır. Satır silme, ayar değiştirme, sepetten ürün çıkarma, listeyi yeniden sıralama. Etki sistemden çıktığı anda geri alma yalana dönüşür: gönderilen e-posta, çekilen ödeme, tetiklenen webhook, muhasebeye düşen fatura. Orada iki dürüst seçenek var, gerçek bir onay adımı ya da gecikmeli gönderim. İkincisi genelde daha iyi çalışır: işlemi birkaç saniye kuyrukta bekletip kullanıcıya o süre boyunca "geri al" göstermek, arkasında gerçekten bekleyen bir kuyruk olduğu sürece hem hızlı hem güvenli.
Çok adımlı geri alma bir arayüz ayarı değil
"Kullanıcı birkaç adım öncesine dönebilmeli" cümlesi arayüz isteği gibi görünür, karşılığı veri katmanında çıkar. Çok adımlı geri alma her işlemin tersinin tanımlı olmasını ister, yani sunucuda etki yaratan her uç nokta için bir telafi ucu. Beş yazma ucu olan bir üründe bu beş ek uç, beş ek test ve bir de sıralama sorunu demek: işlemler birbirine bağımlıysa geri alma sırası ileri sıranın tersi olmak zorunda, aksi halde ikinci geri alma birincinin bıraktığı duruma çarpar.
Ucuz yol tersini hesaplamak değil, durumu saklamak. Düzenlenen kaydın önceki halini sürüm olarak tutmak, silinen satırı işaretleyip yerinde bırakmak, ayarları değiştirmeden önce kopyalamak. Depolama maliyeti neredeyse her zaman ters işlem yazmanın ve bakımının maliyetinin altında kalıyor.
Tarayıcının geri tuşuyla kavga etmeyin
Geri tuşunu devre dışı bırakmaya çalışan siteler kullanıcıyı sitede tutmuyor, sadece bir daha gelmemesini sağlıyor. Asıl sorun da genelde orada değil. Katman (modal) açıkken geri tuşuna basan kullanıcı katmanın kapanmasını bekler, oysa sayfadan tamamen çıkar. Kullanıcı geri tuşunu yanlış kullanmıyor, arayüz onun beklentisine cevap vermiyor.
Çözüm küçük: katmanı açarken geçmişe bir durum ekleyin, geri tuşu o durumu geri aldığında katmanı kapatın. Çok adımlı formlarda aynısı adım adım geçerli. Adımı adrese yazdığınızda geri tuşu kendiliğinden doğru davranır, üstelik kullanıcı bulunduğu adımı yeniden yükleyebilir ya da bağlantısını paylaşabilir. Ayrı bir kütüphane gerekmiyor, history.pushState yetiyor.
Sıralama
Zaman sınırlıysa şu sırayla ilerleyin: önce yıkıcı işlemleri geri alınabilir hale getirin, sonra çıkış yollarını görünür kılın, en son onay kutularını gözden geçirip gereksizleri kaldırın. İlki en pahalısı, ama tek başına şikayetlerin çoğunu kapatıyor. Kullanıcı hata yaptığı an sinirlenmiyor, hatayı düzeltemediğini anladığı an sinirleniyor.