Tarih Giriş Alanı Tasarımı: Takvim mi, Yazarak mı?
Tarih alanı bir formun en küçük bileşeni, terk edilme nedenlerinin ise alışılmış şüphelilerinden biri. Sorun genelde görsel değil: kullanıcı hangi tarihi gireceğini biliyor, sistemin onu nasıl beklediğini bilmiyor. Aşağıda takvim ile metin girişi arasındaki tercih, format belirsizliğinin nerede çözülemez hale geldiği ve çift tarihli alanlardaki kayma var.
Takvim her tarih için doğru araç değil
Yaygın tavsiye şöyle işler: takvim açılırı koy, kullanıcı tıklayarak seçsin, format derdi kökten bitsin. Yakın tarihlerde doğru bir tavsiye. İki hafta sonrasına randevu alan biri için ay ızgarası yazmaktan hızlıdır, üstelik hangi günün hafta sonuna denk geldiğini de gösterir.
Uzak tarihlerde aynı bileşen tersine çalışıyor. Ayda bir adım ilerleyen bir takvimde 1985 doğumlu bir kullanıcı, 2026'da kendi doğum tarihine inmek için 41 yıl geriye, yani 492 tıklama gider. Çözüm diye üstüne yıl ve ay seçici eklenince de elinizde takvim kalmaz; adı takvim olan üç kademeli bir menü olur.
Doğum tarihini takvim açılırıyla sormam. Tek bir metin alanı ve yanında beklenen biçimi gösteren kısa bir ipucu, bu iş için fazlasıyla yeterli.
Ayırıcıda esnek olun, sırada olmayın
"Sistem farklı formatları otomatik tanısın" önerisi kulağa makul geliyor, ama bir yerde duvara çarpıyor: 03.04.2026 girdisini hem 3 Nisan hem 4 Mart olarak okumak mümkün ve hangisinin kastedildiğini girdinin kendisinden çıkarmanın yolu yok. Gün değeri 12'yi geçtiğinde tahmin yürütülebilir, fakat bu da ayrıştırmayı tutarsızlaştırır: 13.04 doğru okunur, 03.04 sessizce yanlış okunabilir. Kullanıcı hangi davranışla karşılaşacağını bilemez.
Pratikte işleyen bölüşüm şu: ayırıcı serbest, sıra sabit. Nokta, eğik çizgi, kısa çizgi ve boşluğun hepsini kabul edin; gün-ay-yıl sırasını alanın yanındaki ipucuyla sabitleyin. Ay adını yazmaya izin vermek belirsizliği büsbütün bitirir, çünkü "4 Mart 2026" tek türlü okunur.
Kaynaklarda sık görülen bir çelişki de burada ortaya çıkıyor: "ayrı açılır menüler kullanmayın" ile "hangi alanın gün, hangisinin ay olduğunu etiketleyin" tavsiyeleri aynı metinde yan yana duruyor. Tek alana indiğinizde etiketlenecek ayrı alan kalmıyor; o yük tamamen biçim ipucunun üstüne geçiyor. Dolayısıyla ipucu süs değil, tasarımın taşıyıcı parçası.
30 Şubat'ı reddetmek yetmiyor
Takvimde var olmayan bir tarihi geri çevirmek asgari şart. Mesajın işe yaraması içinse neyin yanlış olduğunu ve nasıl düzeltileceğini söylemesi gerekir. "Geçersiz tarih" uyarısı kullanıcıya hiçbir şey vermez; "Şubat 2026 28 gün" bilgisi işi tek seferde bitirir.
Doğrulama iki yerde durmak zorunda: anında geri bildirim için istemcide, kayıt için sunucuda. Serbest giriş kabul ediyorsanız bu, aynı ayrıştırma kurallarının iki dilde iki kez yazılması demektir ve iki kopya zamanla birbirinden ayrışır. Sunucudaki ayrıştırıcıyı tek doğruluk kaynağı sayın, istemcideki yalnızca kullanıcıyı erken uyarmak için çalışsın.
Aralık seçiminde kayma
Gidiş-dönüş, giriş-çıkış gibi çift tarihli alanlarda en sık karşılaşılan hata, ikinci tarih seçilirken takvimin görünümünü kendiliğinden değiştirmesi. Kullanıcı 14 Mart'ı seçer, takvim Nisan'a atlar, sonraki tıklama yanlış aya düşer. Kötüsü, bunun çoğu zaman fark edilmemesi.
İkinci seçimde mevcut görünümü olduğu yerde tutun. Geçersiz günleri pasifleştirin ama ekrandan kaldırmayın: pasif gün sınırın nerede olduğunu gösterir, kaybolan gün yalnızca kafa karıştırır.
Karar kuralı
Tarihin bugüne uzaklığı, bileşeni seçer. Yakın tarihlerde takvim, uzak tarihlerde metin girişi; ikisinin de gerektiği yerde metin alanı birincil, takvim yardımcı olur. Belirsizliği ise ayrıştırıcıyı zorlayarak değil, ne beklediğinizi açıkça yazarak çözün.