Form Hata Mesajları: Zamanlama, Ton ve Görsel Ağırlık

Bir formda sorun çıkaran şey hata mesajının kendisi değil, ne zaman çıktığıdır. Telefon alanına ikinci rakamı yazarken geçersiz numara uyarısı alan kullanıcıya arayüz, hata yapmadan önce hata yaptığını söylüyor. Zamanlamanın doğrusu tek bir kurala sığmaz; alanın türüne göre değişir.

Zamanlamayı alanın türü belirler

Yaygın tavsiye şu: kullanıcı alanı bitirip bir sonrakine geçtiğinde doğrula. Bu tavsiye basit alanlarda doğru. Ad, e-posta, telefon gibi tek biçimli alanlarda yazarken uyarmak, kullanıcıyı henüz tamamlamadığı bir iş yüzünden cezalandırmaktır.

Kuralı olan alanlarda aynı tavsiye ters çalışır. Şifre alanını düşünün: kullanıcı on dört karakter yazar, alandan çıkar, en az bir büyük harf içermeli uyarısını ancak o anda görür ve geri döner. Burada beklemek kullanıcıya iyilik değil. Şifre alanında kuralları alanın altına sabit yazar, karşılanan maddeyi yazma sırasında işaretlerim; kırmızıya hiç sıra gelmiyor. Kullanıcı adının müsait olup olmadığı gibi sunucuya soru soran alanlar da aynı gruba girer.

Hata bir kez çıktıysa kural değişir

Bir alan hata durumuna girdikten sonra artık her tuş vuruşunda doğrulanmalı. Kullanıcı düzeltmeyi yapar yapmaz kırmızının kaybolduğunu görmeli; görmezse doğru yazıp yazmadığını anlamak için formu yeniden göndermek zorunda kalır. Uygulamada bu, alan başına tek bir durum bilgisi tutmak demek: alan daha önce hata verdi mi? Vermediyse blur'da, verdiyse her değişiklikte kontrol edilir.

Kırmızı ve ünlem enflasyonu

Hata olmayan şeyi hata gibi göstermek, gerçek hatanın gücünü düşürür. Ekli dosya yok bilgisi sarı zeminde ünlem ikonuyla verilirse kullanıcı bir şeyi yanlış yaptığını sanır. Bilgilendirme nötr renkte ve alçak sesle durmalı; kırmızı yalnızca kullanıcının düzeltmesi gereken yerde.

Renk tek başına ayırt edici değildir. Kırmızı-yeşil ayrımını yapamayan kullanıcı için kırmızı çerçeve ile nötr çerçeve aynı şeydir, ekran okuyucuyla gezen biri içinse çerçeve diye bir şey yoktur. Hatanın kendisi metindir: alanın hemen altında, ne olduğunu ve nasıl düzeltileceğini söyleyen bir cümle. Bu metni alana aria-describedby ile bağlayın, alanı aria-invalid ile işaretleyin. Kırmızı çerçeve süstür, mesaj değildir.

Mesaj sunucudan dönerken

Tarayıcıdaki doğrulama bir kolaylık katmanıdır, güvenlik sınırı değil. Gerçek kontrol sunucuda yapılır ve asıl kötü deneyim de orada üretilir: sunucu formu reddeder, sayfa yeniden yüklenir, kullanıcının doldurduğu on alan boşalmıştır. Hiçbir mesaj bu kaybı telafi etmez. Reddedilen form girilen değerlerle birlikte geri dönmeli, odak ilk hatalı alana taşınmalı.

Bir de çeviri sorunu var. Sunucudan gelen mesajlar çoğu zaman geliştirici için yazılmıştır (constraint violation: users.email_unique gibi). Bunları arayüze olduğu gibi taşımak yerine her hata koduna kullanıcıya söylenecek cümleyi eşleyen bir tablo tutun. Eşleşmeyen kod için de genel bir cümle bulunsun; ham hata metni ekrana düşmesin.

Hata çıkmadan önce

En iyi hata mesajı hiç görünmeyendir. Bunun için üç şey yeterli:

• Kısıtları alanın altında önceden yazın: kaç karakter, hangi biçim, hangi dosya türü.
• Zorunlu alanları tek bir göstergeyle belirtin; yıldız, renkli çerçeve, ikon ve bu alan zorunludur metnini aynı anda kullanmayın.
• Geri dönüşü olmayan işlemlerde (silme, ödeme) onay isteyin, kalanında istemeyin.

Tonla ilgili son bir not: kullanıcıya ne yaptığını değil, ne yapacağını söyleyin. Geçersiz tarih bir teşhistir, Tarihi GG.AA.YYYY biçiminde yazın ise çözüm. Aradaki fark, kullanıcının formu bitirip bitirmemesidir.