Panduan Ramah untuk Date Picker Frontend

• Panduan yang mengusulkan metode input yang sederhana dan mudah diakses sebagai pengganti JavaScript date picker yang rumit
• Dengan memanfaatkan elemen input bawaan browser (date, time, datetime-local), kita bisa otomatis mendapatkan aksesibilitas, performa, dan dukungan internasionalisasi
• UI yang kompleks bisa disederhanakan lewat field input terpisah, masked input, atau grup tombol radio
• Bahkan di framework seperti React, elemen input HTML bawaan tetap bisa digunakan apa adanya; styling memang terbatas, tetapi UI sistem yang familier bagi pengguna tetap terjaga
• Karena semua date picker memiliki masalah aksesibilitas, struktur input yang sederhana dan pengujian dengan pengguna nyata adalah kunci desain form yang sukses

---

Apakah JavaScript date picker benar-benar diperlukan?

• Dalam kebanyakan kasus, JavaScript date picker terpisah tidak diperlukan
  • UI yang kompleks memicu kesalahan dan membuat pengguna membatalkan pengisian form
  • Ada cara input tanggal yang lebih mudah daripada widget kalender
• Panduan ini bertujuan menawarkan alternatif untuk antarmuka yang ramah pengguna

Input tanggal dan waktu bawaan browser

• Semua browser modern mendukung tipe input bawaan date, time, dan datetime-local
  • date untuk memilih tanggal, time untuk memasukkan jam dan menit, datetime-local menggabungkan keduanya
• Input bawaan bisa diterapkan hanya dengan satu baris kode, dan browser menangani aksesibilitas, performa, serta internasionalisasi
  • Mendukung input keyboard dan menyediakan UI kalender bawaan
  • Tidak sempurna, tetapi lebih stabil daripada kebanyakan library JavaScript
• Meski begitu, beberapa masalah aksesibilitas masih tetap ada

Input terpisah dan elemen pilihan

• Dibanding satu date picker, input tahun, bulan, dan hari yang dipisah dapat meningkatkan usability
  • Diberikan contoh komponen date input dari GOV.UK
• Jika data validnya terbatas, penggunaan elemen select lebih tepat
  • Mencegah kesalahan input dan mengurangi interaksi
  • Perlu berhati-hati karena pembaca layar bisa salah membaca bulan dalam format angka
• Untuk interval waktu tetap seperti pemesanan perjalanan (misalnya kelipatan 15 menit), representasi tanggal relatif seperti hari ini atau besok berguna

Masked input dan validasi

• Field masked input adalah alternatif untuk mengarahkan format tanggal tanpa kalender
  • Validasi dan pemformatan di sisi klien dapat dilakukan dengan JavaScript
  • Contoh: pesan error seperti “Masukkan tanggal yang valid untuk Februari (1~28)”
  • Gunakan API Intl untuk memformat tanggal secara otomatis
• Namun, jika JavaScript memperbarui nilai input, fitur undo/redo bisa rusak
• Dengan CSS, beberapa input bisa digabung agar secara visual terlihat seperti satu elemen

Pemilihan rentang dan opsi terbatas

• Date picker pemilihan rentang yang memakai dua kalender sulit dioperasikan dan tidak nyaman digunakan tanpa pointer
  • Sebagai gantinya, bisa disederhanakan menjadi dua field input
• Jika hanya tanggal tertentu yang boleh dipilih, ini bisa diganti dengan grup input radio
  • Alih-alih UI kompleks, gunakan alur kerja bertahap yang sederhana
  • Form multi-langkah dapat diperluas menjadi interaksi satu halaman dengan JavaScript

Input bebas dan fitur saran

• Saat tanggal atau waktu yang presisi tidak diperlukan, input teks biasa bisa berguna
• Dengan elemen datalist, saran input dapat diberikan
  • Juga dapat digunakan bersama tipe input date dan time

Pertanyaan yang sering diajukan

Saat menggunakan framework JavaScript

• Semua framework utama dapat menggunakan elemen HTML bawaan
  • Tidak perlu membuatnya sebagai komponen kustom
  • Binding status dua arah dimungkinkan melalui properti value

Styling date picker bawaan

• Hanya sebagian dari elemen input yang bisa diberi style, sisanya tidak
  • Ini justru menjadi kelebihan karena mempertahankan UI sistem yang familier bagi pengguna
  • Desain berbeda tergantung sistem operasi, metode input, dan browser
  • Penyatuan desain tambahan tidak diperlukan

Menanggapi stakeholder yang meminta JavaScript date picker

• Tujuannya adalah submit form yang berhasil, dan UI yang kompleks meningkatkan kesalahan
  • Semua date picker memiliki masalah aksesibilitas
  • Kombinasi input bawaan lebih ramah pengguna
  • UI JavaScript yang belum teruji bisa melanggar regulasi seperti European Accessibility Act (EAA)
  • Kesederhanaan adalah kunci keberhasilan

Pengujian dan jaminan aksesibilitas

• Memahami panduan aksesibilitas seperti WCAG itu penting
  • Manfaatkan standar web untuk mencegah kesalahan pada UI kustom
• Kesalahan bisa dideteksi dengan fitur aksesibilitas di developer tools browser
  • Tidak ada alat yang sempurna, dan pengujian dengan pengguna nyata adalah satu-satunya cara verifikasi
• Penggunaan accessibility overlay sangat tidak disarankan, karena justru dapat memperburuk masalah

Referensi terkait aksesibilitas

• Collecting dates in an accessible way — Graham Armfield
• What makes an accessible date picker? — Russ Weakley
• Maybe You Don’t Need a Date Picker — Adrian Roselli
• Date Picker Dialog Example — ARIA Authoring Practices Guide
• Designing The Perfect Date And Time Picker — Vitaly Friedman

Jawaban untuk permintaan rekomendasi JavaScript date picker

• Tidak ada solusi universal, semua date picker punya keterbatasan
• Panduan ini bertujuan membantu Anda mengevaluasi kebutuhan sendiri
• Sebisa mungkin, capai tujuan dengan cara yang paling sederhana
• Date picker belum tentu benar-benar diperlukan

Kesimpulan

• Pengujian dengan pengguna nyata dan pengumpulan umpan balik adalah hal yang wajib
• Panduan ini masih terus dikembangkan, dan masukan sangat diterima

[GN⁺]

Komentar Hacker News

• Beberapa tahun lalu saya membuat aplikasi mobile untuk pasien rumah sakit daerah. Banyak penggunanya adalah lansia, dan keluhan tentang date picker bawaan OS yang terlalu tidak nyaman berdatangan
  Ada cerita nyata seperti “tidak bisa mengatur tahun lahir”, “saya harus menekan panah bulan sebelumnya 720 kali untuk sampai ke tanggal lahir saya”
  Baik di iOS maupun Android saat itu, tahun hanya terlihat seperti judul biasa sehingga tidak dianggap sebagai elemen yang bisa diklik
  Saya merasa Flat Design yang terlalu berfokus pada estetika sedang merusak UX. Menurut saya, masalahnya adalah realitas bahwa UI OS ditentukan terutama oleh desainer, bukan pakar UX seperti Don Norman
  Pada akhirnya, setelah diubah menjadi bentuk kotak teks–dropdown–kotak teks (hari–bulan–tahun), keluhannya hilang
  • Riset tim desain Gov.uk di pemerintah Inggris juga sampai pada kesimpulan yang sama.
    Tiga kotak teks (hari, bulan, tahun) memberikan pengalaman terbaik.
    Ada juga panduan pola untuk implementasinya
  • Saya juga ingat pernah mengetuk kolom input itu lebih dari 100 kali saat pertama memakainya, lalu berpikir ‘ini aneh’ dan mencarinya di internet. Benar-benar mimpi buruk UX
  • Rasanya sampai spontan ingin bilang, “Tahun itu bisa diklik??” karena sama sekali tidak intuitif
  • Saya juga pernah lama kebingungan karena tidak tahu cara berpindah tahun di kalender itu
  • Tapi saya penasaran kenapa untuk input tanggal lahir malah harus memakai calendar picker
• Untuk kasus seperti pemesanan perjalanan dengan jadwal yang sudah ditentukan, ekspresi tanggal relatif seperti “hari ini” atau “besok” bisa terasa nyaman
  Tapi saat memesan penerbangan menjelang tengah malam, jadi membingungkan apakah “hari ini” itu berdasarkan zona waktu saya, server, atau GMT
  • Tanggal relatif seperti “hari ini” dan “besok” kelihatannya ide bagus, tapi implementasinya adalah neraka.
    Terlalu banyak pengecualian seperti zona waktu, daylight saving time, akhir bulan (31 Januari → bulan berikutnya?), tepat setelah tengah malam, dan sebagainya.
    Sebelum menambahkan fitur seperti ini, benar-benar harus sangat berhati-hati
  • Transportasi umum Montreal dulu pernah memakai jam 28 jam. Setelah tengah malam, bus ditampilkan sebagai pukul 27:30 atau semacamnya, dan itu sangat membingungkan
  • Saya tidak suka komputer mendefinisikan ‘hari ini’ berdasarkan tengah malam.
    Saat bekerja lewat pukul 12 malam, ekspresi “besok” terasa bertentangan dengan persepsi nyata.
    Dalam praktiknya maksudnya adalah “setelah pagi ini”, tetapi sistem menganggapnya sebagai hari berikutnya
  • Tapi baik “hari ini” maupun “12 November”, jika zona waktunya berbeda maka masalah yang sama tetap muncul
• Dari pengalaman menangani datepicker selama lebih dari 20 tahun, yang terbaik adalah cukup memakai input type="text" dan memberi petunjuk format
  Dengan begitu tidak perlu menderita karena masalah browser, aksesibilitas, dan locale
  Komponen kustom benar-benar gerbang neraka. Sekali coba tampil keren, tahu-tahu jatuh ke 10 lubang kelinci
  • Untuk tanggal yang sudah diketahui seperti ulang tahun itu tidak masalah, tetapi untuk mencari sesuatu seperti “sekitar hari Jumat di awal April” pada pencarian penerbangan, kalender memang diperlukan.
    Karena tanggalnya perlu dieksplorasi secara visual
  • Petunjuk format apa pun yang diberikan, “3-9-1980” tetap tidak bisa dipercaya sebagai 9 Maret atau 3 September bagi pengguna
  • Ini nasihat yang buruk. ISO 8601 oke untuk titik waktu di masa lalu, tetapi tidak cocok untuk pemesanan masa depan atau jadwal lintas negara.
    Masalah tanggal itu sangat rumit sehingga perlu pendekatan berdasarkan use case
  • Meski begitu, menurut saya itu tetap jauh lebih baik daripada kalender di mobile yang bahkan tidak bisa memilih tahun
• Lucu kalau bicara internasionalisasi tapi yang didukung cuma format tanggal ala Barat
  Jika membuat sistem rumah sakit Nepal, harus mendukung kalender Nepal dan kalender umum sekaligus. Kalender Nepal sangat rumit
  Ethiopia memakai kalender 13 bulan, dan bulan terakhirnya hanya 5~6 hari
  Kalau ada referensi date picker internasionalisasi yang benar-benar bagus, saya ingin tahu
• Konteks input tanggal harus menentukan picker apa yang dipakai
  Misalnya, untuk reservasi makan malam kalender berguna untuk melihat ketersediaan akhir pekan, tetapi untuk input tanggal lahir jauh lebih efisien jika dimasukkan cepat dengan angka
• Saat alur input angka penting, seperti ketika memasukkan informasi kartu kredit,
  proses seperti pilih nama bulan → dropdown → pilih tahun akan merusak ritme
  Cara yang hanya memakai input angka jauh lebih alami. Di mobile malah lebih tidak nyaman karena keyboard terus terbuka dan tertutup
• Melihat date picker yang bisa langsung diketik dengan keyboard terasa menyegarkan
  Memaksa custom picker alih-alih UI bawaan terasa aneh.
  Terutama di Android, meniru time picker model roda putar gaya iOS di web adalah yang paling buruk
• Sebagai orang Denmark, nama “Pikaday” terdengar lucu. “pik” dalam bahasa Denmark adalah bahasa gaul untuk alat kelamin pria
  • Sampai muncul lelucon seperti, “Kalau begitu Pokémon juga populer di Denmark ya?”
• Hanya punya picker Date, Time, dan DateTime itu tidak cukup
  Picker bulanan, mingguan, dan rentang kustom juga dibutuhkan. Elemen form native terlalu terbatas
  • Saya penasaran apakah selain dukungan Firefox, ada kekurangan lain pada <input type="week"> atau <input type="month">
  • Saya ingin ada AI time picker yang meminjam kekuatan Chronos, dewa Yunani
• Sebagai referensi, konteks diskusi ini ada di tulisan tentang Pikaday
  • Saya juga ingat pernah memakai library datepicker bernama Pikaday dulu