Saat Dilimi Seçici Tasarımı: Neyi Tahmin Et, Neyi Sakla
Saat dilimi seçicisi çoğu arayüzde ayarlar sayfasının en dibinde, yüzlerce satırlık bir açılır liste olarak durur. Kullanıcı kendi şehrini o listede bulamadığında ya da UTC+3'ün ne anlama geldiğini bilmediğinde takvim davetleri yanlış saate düşer. İyi kurulmuş bir seçici soruyu neredeyse hiç sormaz: tahmini kendisi yapar, kullanıcıya sadece doğrulatır.
Tahmini tarayıcıya sor
Kullanıcıya listeyi açtırmadan önce doğru cevabı zaten biliyorsun. Tarayıcıda Intl.DateTimeFormat().resolvedOptions().timeZone çağrısı Europe/Istanbul gibi bir IANA kimliği döner ve bu değer işletim sisteminin ayarından gelir. Tek satır, ek servis yok (IP tabanlı saat dilimi tahminini bu iş için gereksiz karmaşık buluyorum: VPN, kurumsal çıkış noktası ya da mobil operatör yüzünden sık sık yanlış ülkeyi gösterir).
Bu tahmini varsayılan yap, ama kilitleme. Seçili değeri ayarlar ekranında okunur biçimde göster ki taşınan ya da seyahatte olan kullanıcı değiştirebilsin.
Offset saklamak hataya davetiye
Seçicinin kaydettiği şey UTC+3 değil, Europe/Istanbul olmalı. Offset yıl içinde değişir; bölge kimliğine bağlı kalırsan değişimi saat dilimi veritabanı senin yerine hesaplar.
Fark küçük görünür, sonra bahar aylarında bir toplantı bir saat kayar. Avrupa yaz saatine martın son pazarı geçer, ABD ise martın ikinci pazarı; aradaki üç haftada Londra ile New York arasındaki fark alışılmış beş saat yerine dört saattir. Offset saklayan bir kayıt bu üç haftayı bilemez.
Aynı gerekçeyle offsetle aramaya da temkinli yaklaş. "+2" yazan kullanıcıya düzinelerce bölge listelenir ve hangisinin kendisi olduğunu ayırt edemez.
Arama kutusu asıl arayüz
Yüzlerce kaydı kapsayan bir listede kullanıcı kaydırmaz, yazar. Arama alanını menü açıldığında görünür ve odaklanmış tut, filtrelemeyi her tuş vuruşunda çalıştır.
Eşleşmeyi tek alanla sınırlama: şehir, ülke ve yerleşik takma adlar (Pacific Time, Türkiye Saati) aynı sorguda taranmalı. Türkçe arayüzde aksan duyarsız karşılaştırma da gerekir, "Istanbul" yazan kullanıcı "İstanbul" kaydını bulmalı. i ve İ dönüşümü Türkçe yerelinde tuzaklı olduğu için bunu küçük harfe çevirerek değil, karşılaştırma öncesi normalleştirmeyle çözersin.
Sıralamada yaygın tavsiyeler kendi içinde çelişir: hem alfabetik dizilim hem de popüler bölgelerin listenin başına alınması isteniyor. İkisini aynı dizide karıştırırsan tarama mantığı bozulur, kullanıcı alfabenin nerede başladığını bulmaya çalışır. Önerilenleri ayrı bir grup başlığı altında en fazla beş kayıtla ver, kalan listeyi kullanıcının gördüğü şehir adına göre sırala. Ham IANA kimliğine göre sıralarsan İstanbul "E" harfinin altına düşer.
Seçimi yerel saatle doğrulat
Kullanıcı "UTC+3" ifadesini doğrulayamaz, 14:32'yi doğrulayabilir. Her satırda ve seçim sonrasında o bölgedeki güncel saati göster: İstanbul, Türkiye (şu an 14:32). Yanlış kaydı seçen kullanıcı hatayı listeden çıkmadan fark eder.
Offset bilgisini tamamen atmak gerekmiyor, ikincil satırda durabilir. Kararı verdiren şey saatin kendisi olsun.
Klavye ve ekran okuyucu
Arama gerektiren bir liste native <select> ile kurulamaz, yani özel bir bileşen yazacaksın. O zaman combobox rolünü yarım bırakma: role="combobox", aria-expanded, aktif seçeneği işaret eden aria-activedescendant, ok tuşlarıyla gezinme, Enter ile seçim, Escape ile kapatma. Eksik bırakılmış özel bir açılır liste, optgroup ile gruplanmış sade bir select'ten daha kötü bir deneyim verir.
Mobilde listeyi tam ekran bir katmana taşı. Dar bir açılır kutu içinde yüzlerce satırı parmakla kaydırtmak küçük ekranda cezalandırıcıdır.
Ölçüt: kaç kullanıcı listeyi açıyor
Bu tasarımın başarısını seçim süresiyle değil, seçiciyi hiç açmayanların oranıyla ölç. Tahmin doğruysa kullanıcı ayarlardaki değeri okur ve geçer. Açma oranı yükseliyorsa sorun listenin sıralamasında değil, tahminde ya da tahmini gösterme biçimindedir.