Arayüzde Geri Bildirim: İndikatör, Doğrulama ve Bildirim Arasında Seçim
Üç geri bildirim aracı sürekli birbirinin yerine kullanılıyor: indikatör, doğrulama, bildirim. Karışıklığın sonucu tanıdık; kritik hata dört saniyede kaybolan bir toast'ta duyuruluyor, önemsiz bir sistem mesajı ekranı kilitliyor. Seçim aslında zevk meselesi değil, üç soruya verilen cevapla belirleniyor.
Seçimi belirleyen üç soru
Bir geri bildirimi tasarlamadan önce şunları sırayla cevaplayın: Bilgi kullanıcının kendi yaptığı bir işlemden mi doğdu? Kullanıcının bir şey yapması gerekiyor mu? Şimdi mi görmesi gerekiyor, sonra fark etse olur mu?
| Durum | Araç | Örnek |
|---|---|---|
| Aksiyon gerekmiyor, sonra fark edilse olur | İndikatör | Okunmamış mesaj rozeti |
| Kullanıcının girdisi hatalı, düzeltmesi gerek | Doğrulama | Boş bırakılan adres alanı |
| Sistem tarafında bir olay oldu, bilgi yeterli | Pasif bildirim | Dosya yüklendi |
| Sistem tarafında olay oldu, karar gerekiyor | Diyalog ya da kalıcı uyarı bandı | Oturum sona eriyor |
Son satır çoğu metinde bildirim başlığı altında geçiyor ve burada bir tutarsızlık var. Bildirimlerin araya girmemesi gerektiği söylenir, hemen ardından kritik bilgilerin daha belirgin yöntemlerle desteklenmesi tavsiye edilir. İkisi aynı anda olmaz. Bir şey kullanıcıyı gerçekten kesmeyi hak ediyorsa o artık bildirim değildir, karar noktasıdır ve kalıcı bir bileşen ister.
İndikatörler: yer kaplama hakkını kazanmalı
İndikatör pasiftir, kullanıcıdan hiçbir şey beklemez, sadece bir yerde bir şey olduğunu söyler. İkon, kalın yazı, renk farkı, sayı rozeti. Doğru konumlandığında güçlüdür: bilgi, ait olduğu öğenin yanında durur.
Pratikte asıl sorun sayı değil, sayının anlamı. Rozete 12 yazıyorsa kullanıcı bunu bir görevin büyüklüğü olarak okur ve azaltmaya çalışır. Azaltılamayan bir rozet (asla sıfırlanmayan bildirim sayacı gibi) kısa sürede görsel gürültüye dönüşür ve o noktadan sonra gerçekten önemli olan artışı da kimse görmez. Sıfırlanamayacak bir sayacı hiç koymayın, yerine nokta işareti yeterli.
Bir de görünmeyen maliyeti var. Her sayfa yüklemesinde sayaç için ayrı sorgu çalışıyorsa, listede on satır varsa bu on ekstra sorgu demek. Rozeti tasarım kararı olarak verip uygulama maliyetini sormamak, sonradan sayfa açılış süresi olarak geri geliyor.
Doğrulama: mesajın kendisi kadar zamanlaması
Doğrulama mesajının içeriği için kural basit: sorunu değil çözümü yazın. "Alan boş bırakıldı" yerine "Adresinizi girin". "Geçersiz format" yerine beklenen formatı gösterin. Bu kısım yeterince tekrarlandı.
Az konuşulan kısım zamanlama. Her tuş vuruşunda doğrulayan bir e-posta alanı, kullanıcı daha adresini yazarken kırmızıya döner; kişi henüz hata yapmamıştır, sadece yazmayı bitirmemiştir. Doğru davranış şu: alanı ilk kez odaktan çıkınca doğrulayın, hata verdiyse artık her tuşta yeniden doğrulayın. Böylece kullanıcı yazarken azarlanmaz, düzeltirken de anında onay alır.
İkinci nokta hatanın nerede duracağı. Mesaj alanın hemen altında kalmalı, formun tepesinde toplu liste halinde değil. Uzun formlarda ikisi birden gerekiyorsa tepedeki özetten ilgili alana bağlantı verin ve gönderim sonrası odağı ilk hatalı alana taşıyın. Klavyeyle çalışan biri için bu tek satırlık düzenleme, formu tamamlanabilir kılan şey oluyor.
Sunucu tarafı doğrulamayı da atlamayın. Tarayıcıdaki kontrol kullanıcıya yardım etmek içindir, veriyi korumak için değil.
Bildirimler ve toast'ın sınırı
Toast kullanışlı bir araç, ama tek bir işe yarıyor: geri alınabilir, sonucu önemsiz, kullanıcının zaten beklediği bir olayı onaylamak. "Kaydedildi", "Kopyalandı".
Bir hata mesajını toast'a bağlamam. Sebep basit: toast kendi kendine kaybolur ve kaybolduktan sonra o bilgiyi geri getirmenin yolu yoktur. Kullanıcı başka sekmedeyse, ekranın diğer ucuna bakıyorsa ya da yavaş okuyorsa hata hiç yaşanmamış gibi olur. Hata, oluştuğu bağlamda kalıcı olarak durmalı.
İçinde düğme olan toast'lar ayrı bir sorun. "Geri al" bağlantısı dört saniyede kaybolacaksa, o düğmeye yetişmek bir refleks testine dönüşür. Aksiyon içeren bildirim otomatik kapanmamalı; kullanıcı kapatana kadar durmalı.
Görünmeyen geri bildirim, olmayan geri bildirimdir
Ekran okuyucu, DOM'a sessizce eklenen bir kutuyu okumaz. Dinamik geri bildirimin duyurulması için canlı bölge tanımlamak gerekir: bilgilendirme mesajları için nazik bir canlı bölge, düzeltme gerektiren hatalar için anında duyurulan uyarı rolü. Doğrulama mesajını ilgili girdiye bağlamak da ayrı bir adım, yoksa mesaj okunur ama hangi alana ait olduğu anlaşılmaz.
Renk tek başına da yeterli değil. Kırmızı çerçeve, kırmızıyı ayırt edemeyen kullanıcı için sadece çerçevedir. Yanına ikon ya da metin koyun.
Bunları test etmek için özel araç şart değil. Fareyi bırakıp formu baştan sona klavyeyle doldurun, sonra ekran okuyucuyu açıp aynı şeyi yapın. Yirmi dakikalık bu tur, çoğu erişilebilirlik raporundan daha fazla iş çıkarıyor.