GitHub tidak lagi menggunakan Toasts

 (primer.style)
16 poin oleh GN⁺ 2025-12-12 | 1 komentar | Bagikan ke WhatsApp
  • UI notifikasi toast tidak lagi direkomendasikan di GitHub karena masalah aksesibilitas
  • Struktur notifikasi sementara yang hilang otomatis berisiko melanggar standar aksesibilitas visual dan fungsional (WCAG)
  • GitHub mengajukan banner dan dialog sebagai alternatif umpan balik yang persisten dan dapat diakses
  • Toast juga memiliki banyak masalah kegunaan, seperti pada layar besar, multitasking, dan kecenderungan mengabaikan banner
  • Demi aksesibilitas dan pengalaman pengguna yang konsisten, penggunaan Toast dihentikan di seluruh sistem desain Primer

Gambaran umum Toasts

  • Toast adalah jendela notifikasi persegi kecil yang muncul sebentar di sudut bawah layar, dipicu oleh tindakan pengguna atau sistem
  • Karena dirancang untuk hilang otomatis setelah beberapa waktu, pola ini memiliki masalah aksesibilitas dan kegunaan bawaan
  • Karena alasan tersebut, GitHub merekomendasikan cara komunikasi yang lebih stabil dan mudah diakses

Alternatif pengganti Toast

  • Perlu memilih UI yang sesuai berdasarkan tujuan penggunaan
    • Untuk notifikasi sukses sederhana, tidak perlu umpan balik tambahan karena hasilnya bisa dikonfirmasi langsung dari layar hasil
    • Untuk pekerjaan yang lebih kompleks, status keberhasilan disampaikan melalui banner atau penampilan konten secara bertahap
    • Untuk pekerjaan yang gagal, informasi kesalahan diberikan melalui banner atau dialog
  • Untuk pengiriman formulir, formulir sederhana tidak memerlukan konfirmasi tambahan, sedangkan formulir kompleks menggunakan halaman konfirmasi perantara atau banner
  • Untuk validasi input, gunakan komponen validasi formulir yang sudah ada di Primer
  • Untuk pekerjaan berdurasi panjang, status selesai disampaikan melalui banner atau kanal lain seperti email dan notifikasi push
  • Saat terjadi desinkronisasi sesi, gunakan dialog atau banner untuk memberi tahu bahwa penyegaran halaman diperlukan

Pertimbangan aksesibilitas (Accessibility Considerations)

  • UI toast berpotensi melanggar beberapa kriteria keberhasilan WCAG
    • 2.2.1 Timing Adjustable (A) : harus tetap tampil sampai pengguna menutupnya sendiri
    • 1.3.2 Meaningful Sequence (A) : ketidaksesuaian antara urutan DOM dan urutan visual dapat membingungkan saat menggunakan teknologi bantu
    • 2.1.1 Keyboard (A) : interaksi di dalam toast harus dapat dikendalikan dengan keyboard
    • 4.1.3 Status Messages (AA) : keberadaannya harus diberitahukan ke teknologi bantu tanpa mengganggu
    Iklan
  • Kriteria lain yang juga berpotensi dilanggar
    • 1.4.4 Resize text (AA) : saat ukuran teks diubah, ada risiko menutupi layar atau terjadi overflow
    • 1.4.10 Reflow (AA) : saat terjadi scroll horizontal, aksesibilitas keyboard harus tetap terjamin
    • 2.4.3 Focus Order (A) : ada kemungkinan membingungkan urutan fokus
    • 3.2.4 Consistent Identification (AA) : perlu menjaga konsistensi dalam kode

Pertimbangan kegunaan (Usability Considerations)

  • Pada layar besar, toast bisa berada di luar bidang pandang sehingga tidak terlihat
  • Saat hilang otomatis, ada risiko pengguna melewatkan pesan karena sedang mengerjakan hal lain
  • Fenomena menutupi UI: toast dapat menutupi elemen penting seperti tombol di bagian bawah
  • Pengguna yang memperbesar tampilan layar mungkin tidak dapat melihat toast yang berada di luar area pembesaran
  • Masalah memori kerja: karena hilang otomatis, informasi tidak bisa diperiksa ulang
  • Kecenderungan mengabaikan banner: penggunaan berlebihan membuat pengguna cenderung mengabaikannya
  • Ketidaksesuaian posisi: jarak fisik antara UI pemicu dan toast dapat membingungkan keterkaitannya
  • Perilaku tutup yang keliru: tombol Esc dapat menyebabkan UI lain ikut tertutup

Referensi tambahan

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-12
Komentar Hacker News
  • Saat memberi kuliah tentang aksesibilitas, ada pengalaman setelah klik muncul jeda 3 detik sehingga terasa seperti tidak ada respons sama sekali
    • Saat banner diklik, pengguna harus menunggu tanpa indikasi apa pun, lalu belakangan malah berpindah ke halaman lain yang tidak relevan, sehingga terasa menjengkelkan
    • Masalahnya dianggap sebagai tidak adanya umpan balik yang memberi tahu bahwa proses sedang memuat
    • Ada yang mengatakan itu hanyalah tautan `` biasa, dan jedanya cuma karena halaman yang tidak perlu terlalu besar
    • Orang lain mengatakan bahwa bahkan di 4G yang lambat pun responsnya langsung, jadi mungkin masalahnya ada pada browser atau jaringan
  • Dokumen GitHub Primer dibaca dengan minat
    • Meski tidak setuju dengan semua isinya, tetap ada hal yang bisa dipelajari, dan rasanya jauh lebih baik daripada mengandalkan intuisi semata
    • Sebagai referensi, Apple dan Android juga masing-masing menyediakan panduan desain
  • Semoga tren seperti ini akhirnya makin menyebar
    • Terlalu banyak pesan yang terlewat karena notifikasi toast
    • Pengguna lain sepenuhnya setuju dengan kalimat “toast tidak direkomendasikan karena masalah aksesibilitas”, dan menekankan bahwa kalaupun ada notification center mungkin sedikit lebih baik, tapi tetap saja pendekatan yang buruk
  • Saya suka toast sebagai konfirmasi non-intrusif, tetapi menurut saya tidak cocok untuk menyampaikan informasi penting
    • Orang lain menjelaskan konteks penggunaan toast secara lebih rinci
      • Respons langsung setelah tombol diklik → lebih baik beri umpan balik dari tombol itu sendiri
      • Respons shortcut keyboard → tidak masalah
      • Notifikasi bahwa pekerjaan yang memakan waktu lama telah selesai → tidak masalah, tetapi perlu kotak notifikasi yang persisten
      • Menampilkan peringatan saat masuk ke halaman → jika penting, harus ditampilkan sebagai notifikasi permanen di dalam halaman
    • Di React, pemanggilan global toast() mudah dilakukan sehingga cenderung disalahgunakan, tetapi disarankan bahwa struktur seperti useAlerts() jauh lebih baik
  • Bagi saya, toast itu seperti torniket
    • Berguna untuk sementara menahan masalah mendesak, tetapi tidak boleh dipertahankan dalam jangka panjang
    • Saat proyek baru kekurangan umpan balik, bisa ditempelkan sementara lalu dihapus satu per satu sambil UI diperbaiki
    • Organisasi besar seperti GitHub mungkin tidak memerlukan solusi sementara seperti ini, tetapi tim kecil bisa berbeda
  • Saya suka bagian di dokumen GitHub yang mengatakan “saat membuat Issue dalam jumlah besar, diperlukan umpan balik tambahan”
    • Akan bagus jika GitHub Actions juga punya umpan balik seperti ini, karena setelah dijalankan hasilnya terlalu lama untuk muncul
  • Saya suka ide memakai toast sebagai log tindakan di seluruh UI
    • Daripada umpan balik yang hilang setiap kali klik, ada contoh implementasi yang bagus seperti Sonner
  • Rasanya sudah waktunya mempertimbangkan dukungan native untuk toast di tingkat browser
    • Sepertinya ini bisa meningkatkan aksesibilitas lewat pengaturan timing, notification center, integrasi screen reader, dan sebagainya
    • Secara visual memang baik-baik saja, tetapi sering terlewat karena hilang terlalu cepat
    • Sulit benar-benar memahami masalah yang dialami tunanetra secara langsung, tetapi ada keinginan untuk mendengar cara meningkatkan aksesibilitas bagi mereka
  • Kelebihan toast adalah mudah diimplementasikan dan tidak membebani desain
    • Kekurangannya mudah terlewat dan berisiko menumpuk di atas informasi lain
    • Jika ada kelonggaran, rasanya lebih baik menghapus semua toast
    • Orang lain menunjukkan bahwa “karena mudah dibuat, ini sering disalahgunakan sebagai tambalan yang berpura-pura menyelesaikan masalah”
    • Ada juga yang mengatakan mereka memakai toast hanya sebagai umpan balik untuk menenangkan pengguna
    • Sebaliknya, ada yang berpendapat bahwa “toast adalah alat yang berguna untuk memberi umpan balik langsung pada kejadian berprioritas rendah”, dan lebih efisien daripada modal atau area tetap
    • Mereka mengkritik pola pikir hitam-putih yang menolak alat sepenuhnya hanya karena sering disalahgunakan
  • Ada yang melihat tulisan berjudul “penghapusan toast oleh GitHub adalah kabar buruk bagi aksesibilitas”
    • Sebagian merasa klaim itu aneh
      • Menurut mereka, anggapan bahwa alih-alih menghapus toast, GitHub seharusnya membuat standar browser lewat W3C adalah lompatan logika
      • Munculnya item yang sudah dibuat di daftar saja dianggap sudah cukup sebagai umpan balik
    • Orang lain juga mengatakan, “kalau toast dianggap buruk untuk aksesibilitas dan UX, lalu GitHub dikritik karena tidak menstandarkannya di browser, itu kontradiktif”