Tarih alanında takvim mi, gün–ay–yıl kutuları mı kullanmalı?
Bir teknik servis formunda cihazın satın alındığı tarih soruluyor. Başka bir formda ise gelecek ay için ziyaret günü seçiliyor. İkisinde de sonuç bir tarih olabilir; fakat kullanıcı aynı işi yapmıyor. İlkinde belgedeki bilgiyi aktarıyor, ikincisinde seçenekleri değerlendiriyor. Bu ayrımı yapmadan bütün tarih alanlarına aynı takvimi koymak, özellikle yıllar öncesine gitmek gerektiğinde gereksiz gezinme yaratabilir. Buradaki karar saat dilimi değil, tarihin nasıl girileceğidir.
Önce bilginin nereden geldiğini sorun
Özgün bir eğitim örneği olarak, garanti talebi ile keşif randevusunu yan yana düşünelim. Garanti talebinde ziyaretçi faturadan tarih okuyabilir. Keşif talebinde ise uygun günleri karşılaştırmak ister. Formu tasarlamadan önce işletmenin gerçekten tam tarih isteyip istemediğini öğrenin. Yalnız satın alma yılı yeterliyse gün ve ayı zorunlu yapmak daha doğru veri üretmez. Kullanıcının hatırlayamadığı bilgi için uydurma bir tarih girmesini teşvik eden bir yapı kurmayın.
Bilinen tarih için gerçek bir örneği inceleyin
GOV.UK tarih girişi örneği, bilinen veya belgeden bulunabilen tarihleri gün, ay ve yıl alanlarıyla sunar. Tasarım dersimiz, takvim bileşenini her sorunun varsayılanı kabul etmemektir. Garanti örneğinde alanların ortak başlığı “Satın alma tarihi” olabilir; her kutunun etiketi ve beklenen sıra ayrıca görünmelidir. Kutular arasında otomatik atlama yerine ziyaretçinin yazma ve düzeltme kontrolünü koruyun. Örnekteki kamu hizmeti görünümünü aynen kopyalamak gerekmez.
Seçim yapılacaksa takvimin anlamını belirleyin
Keşif örneğinde takvim, haftanın günlerini birlikte görmeye yardımcı olabilir. Ancak takvimde görünen her günün gerçekten müsait olduğu sonucu çıkarılmamalı. Bir tarih tercihi mi alıyorsunuz, yoksa kesinleşen randevu mu oluşturuyorsunuz? Bu iki işlemi etiket ve onay ekranında ayırın. Takvim uygunluk sistemiyle bağlı değilse “Tercih ettiğiniz gün” gibi doğru bir ifade kullanın. Müsait olmayan tarihleri yalnız soluk renklerle anlatmak yerine açıklamasını da anlaşılır kılın.
Tarayıcının sunduğu kontrolü gerçek cihazda deneyin
MDN belgesine göre yerel tarih alanının arayüzü tarayıcı ve işletim sistemine göre değişebilir; gösterilen biçim ile iletilen tarih değeri de aynı şey değildir. Bu nedenle masaüstündeki tek ekran görüntüsüyle onay vermeyin. Bir telefonda eski bir yıl seçin, başka bir cihazda elle giriş yapın ve kaydın işletmeye hangi değerle ulaştığını kontrol edin. Ay ve günün yer değiştirmediğini özellikle sınayın.
Hatalı girişleri düzeltilebilir bırakın
Örnekte 31 Şubat, eksik yıl ve yanlışlıkla gelecek yıl girilmesi farklı sorunlardır. Mesajın hangi alanın değişeceğini açıklamasını isteyin. Bütün tarihi silmek yerine geçerli parçaları koruyun. Fatura tarihi bilinmiyorsa destek yolunu gösterin; otomatik olarak bugünün tarihini kaydetmeyin. Alan boş bırakıldığında ortaya çıkan davranışı, işletmenin kabul ettiği kuralla birlikte değerlendirin. Sadece takvimde seçim yapılabilmesi, kaydın iş açısından doğru olduğunu kanıtlamaz.
Kabul testini iki ayrı görevle bitirin
Bir katılımcıya örnek belgedeki tarihi yazdırın; diğer görevde gelecek ay bir ziyaret günü seçtirin. Süreden önce yanlış tarih, geri dönüş ve düzeltme davranışlarını kaydedin. Klavye ile ulaşılabilirlik, görünür etiketler ve telefon ekranındaki kullanım da kontrol listesine girsin. Bu kararları web tasarım kapsamına ekleyin. Randevunun saati ve ülke farkı ayrıca söz konusuysa saat dilimi rehberi ayrı soruyu ele alır.
Sık sorulan sorular
Her tarih alanına varsayılan olarak bugünü koymalı mıyız?
Hayır. Satın alma tarihi gibi bir soruda bu, yanlış bir kaydın fark edilmeden gönderilmesine yol açabilir. Varsayılanın anlamını görev üzerinden değerlendirin.
Takvim kullanmak daha profesyonel görünür mü?
Profesyonel karar, kontrolün gösterişinden çok göreve uygunluğudur. Bilinen tarihi yazmak ve uygun günü seçmek için aynı çözüm şart değildir.