Apabila alat AI sedang menjana kandungan, memproses set data, atau menjalankan tugas autonomi, pengguna memerlukan jalan keluar yang jelas. Terlalu banyak antara muka menganggap hentian kecemasan sebagai perkara sampingan. Mereka menukar label butang daripada "Stop" kepada "Stopped" dan menganggap tugas telah selesai. Warnanya mungkin bertukar kelabu. Animasinya mungkin kelihatan lancar. Namun, tugas tersebut terus berjalan di pelayan, dan pengguna tidak menyedari ada sesuatu yang tidak kena. Bagi seseorang yang bergantung pada pembaca skrin, kegagalan ini lebih parah. Mereka mendengar pengesahan audio bahawa proses telah tamat, sedangkan kerja tersebut terus berjalan secara senyap di latar belakang. Itu bukan pepijat kecil. Ia adalah keruntuhan kepercayaan.

Penipuan Butang Hentian Senyap

Butang hentian yang buruk menipu pengguna anda. Ia memaparkan perkataan "Stopped" sedangkan tugas tersebut terus dilaksanakan di dalam kontena atau pada pekerja jauh (remote worker). Ini berlaku kerana pembangun front-end sering mengemas kini antara muka secara optimistik sebelum pelayan mengesahkan pemberhentian tersebut. Pengguna visual mungkin menyedari ketidakpadanan jika bar kemajuan terus bergerak atau log terus menatal, tetapi pengguna pembaca skrin tidak mempunyai saluran sekunder sedemikian. Mereka bergantung sepenuhnya pada apa yang diumumkan oleh antara muka. Jika teks butang berubah terlalu awal dan tiada maklum balas audio yang menjelaskan keadaan sebenar, pengguna akan percaya bahawa kecemasan telah berakhir walaupun sebenarnya tidak. Kebolehcapaian di sini bukan sekadar permintaan ciri. Ia adalah keperluan keselamatan.

Dua Keadaan Berbeza

Kawalan kecemasan yang sebenar mesti mengendalikan dua tanggungjawab yang berbeza. Pertama, sistem menerima permintaan anda. Kedua, sistem menarik balik kuasa (revokes authority). Kedua-duanya bukan perkara yang sama. Penerimaan bermaksud bahagian front end telah mendengar anda dan menyampaikan mesej tersebut. Penarikan balik bermaksud bahagian back end benar-benar menamatkan proses tersebut. Disebabkan kewujudan kependaman rangkaian (network latency), barisan tugas (job queues), dan lapisan orkestrasi, jurang antara dua saat tersebut boleh berlarutan selama beberapa saat. Dalam tempoh itu, antara muka anda mesti menyatakan kebenaran tentang tahap mana yang sedang berlaku. Menggabungkan kedua-dua tahap menjadi satu saat yang sama mengandaikan infrastruktur yang tidak wujud. Pengguna anda akan menanggung akibat daripada sikap optimistik tersebut.

Memetakan Empat Keadaan ke dalam Antara Muka Anda

Bina UI anda berasaskan empat keadaan eksplisit supaya pengguna sentiasa tahu kedudukan mereka.

  • Running: Paparkan butang "Stop task" dengan label yang jelas. Pastikan ia sentiasa kelihatan. Jangan sembunyikannya di bawah tab atau panel akordion.
  • Requesting: Nyahaktifkan butang supaya pengguna tidak boleh menghantar permintaan tambahan secara berulang-ulang. Paparkan mesej "Stop requested". Kejujuran ini penting. Ia memberitahu pengguna bahawa arahan mereka sedang diproses dan sistem belum mengesahkan penyelesaiannya.
  • Stopped: Nyahaktifkan butang. Paparkan ID resit. Ini memberi bukti kepada pengguna bahawa pelayan telah bertindak balas dan hentian tersebut telah direkodkan. Ia menukarkan satu dakwaan kepada satu rekod.
  • Failed: Aktifkan butang "Try stop again". Paparkan mesej kegagalan yang khusus. Jangan biarkan pengguna dalam keadaan tergantung (limbo) yang senyap. Jika pelayan mengalami masa tamat (timeout) atau mengembalikan ralat, nyatakan perkara tersebut.

Keadaan-keadaan ini harus memacu maklum balas visual dan auditori. Apabila keadaan berubah, pembaca skrin mesti mengumumkan label dan status baharu melalui kawasan langsung (live region) yang diuruskan dengan betul. Butang yang dinyahaktifkan bersama dengan pengumuman teks dapat mengelakkan kekeliruan tentang sama ada kawalan tersebut masih aktif.

Peraturan Reka Bentuk yang Berkesan di Bawah Tekanan

Kawalan kecemasan membawa beban reka bentuk yang berbeza daripada butang biasa. Pengguna mungkin merasa cemas, tergesa-gesa, atau bertindak balas terhadap output yang tidak dijangka. Antara muka anda mesti kekal boleh digunakan dalam keadaan tertekan itu.

Jangan gunakan warna sebagai satu-satunya isyarat. Butang yang bertukar daripada merah ke hijau membantu sesetengah pengguna yang boleh melihat, tetapi pengguna rabun warna dan pengguna pembaca skrin memerlukan perubahan teks dan struktur. Padankan warna dengan label eksplisit, ikonografi dengan alternatif teks, dan pengumuman keadaan.

Jangan sembunyikan kawalan dalam menu hover. Tiada sesiapa yang patut mencari melalui menu lungsur (dropdown) semasa kecemasan. Butang hentian sepatutnya berada dalam paparan utama (primary viewport), sentiasa boleh dicapai tanpa perlu pergerakan kursor yang terlalu tepat.

Pastikan butang mudah ditekan dengan penunjuk. Tekanan mengurangkan kawalan motor halus. Gunakan padding yang luas dan sasaran klik yang besar. Jika pengguna sedang menggigil atau menggunakan pad sesentuh (trackpad) di dalam kereta api yang sedang bergerak, mereka sepatutnya masih boleh melakukan klik dengan tepat.

Pastikan pengguna papan kekunci dapat mencapai butang dengan cepat. Urutan tab tidak sepatutnya memaksa seseorang melalui tiga puluh elemen yang boleh difokuskan sebelum mencapai kawalan kecemasan. Pertimbangkan pautan lompat (skip link) atau penempatan fokus logik yang meletakkan tindakan hentian dalam jangkauan segera.

Elakkan pintasan papan kekunci yang tidak disengajakan. Pintasan global yang menghentikan sesuatu proses harus menggunakan kombinasi yang sukar dicetuskan secara tidak sengaja. Jika pintasan simpan atau cetak yang biasa bertindih dengan arahan henti anda, seseorang akan mencetuskannya secara tidak sengaja dan kehilangan hasil kerja.

Jangan gunakan pengesahan berbilang langkah untuk kecemasan. Dialog pengesahan adalah satu penghalang, bukannya pagar keselamatan. Menjelang masa pengguna membaca "Adakah anda pasti?" dan klik sekali lagi, output yang tidak diingini mungkin telah pun dihantar. Satu tindakan yang tegas sudah memadai.

Resit, Kehilangan Rangkaian, dan Had yang Jujur

ID resit membuktikan pelayan telah bertindak balas. Ia tidak membuktikan setiap kesan hiliran telah dibatalkan. Tugasan AI anda mungkin telah mencetuskan API luaran, penulisan fail, atau barisan mesej (message queues) menjelang masa arahan henti tiba. Menghentikan orkestrator tidak menjamin setiap proses anak dibatalkan serta-merta. Bersikap jujur tentang had ini dalam mesej dan dokumentasi anda.

Anda juga perlu mereka bentuk untuk mod kegagalan yang berlaku di luar bilik pelayan anda. Uji apa yang berlaku apabila pengguna kehilangan sambungan rangkaian sejurus selepas mengklik henti. Uji apa yang berlaku apabila respons mengambil masa sepuluh saat dan bukannya seratus milisaat. Jika permintaan tergantung, antara muka anda harus mengalami tamat masa (time out) ke dalam keadaan gagal daripada terus tersangkut pada "Requesting" selama-lamanya. Pengguna berhak tahu apabila talian telah terputus.

Cara Menguji dengan Serius

Pengesahan tidak boleh menjadi perkara sampingan. Jalankan antara muka anda melalui keadaan sebenar yang dihadapi oleh pengguna kurang upaya setiap hari.

Navigasi hanya menggunakan papan kekunci. Cabut tetikus anda. Gunakan kekunci Tab untuk melalui setiap keadaan. Pastikan anda boleh mencapai butang henti dari mana-mana bahagian dalam aliran kerja tanpa memerangkap fokus atau mencipta hentian tab yang tidak kelihatan.

Zum pelayar 200%. Besarkan halaman. Periksa sama ada butang henti disusun semula (reflows) atau hilang. Pengguna dengan penglihatan rendah bergantung pada zum, dan keruntuhan susun atur sering menyembunyikan kawalan kritikal.

Tetapan gerakan dikurangkan. Keadaan "Requesting" anda mungkin menggunakan animasi denyutan atau pemuat berputar (spinning loader). Hormati prefers-reduced-motion. Sediakan penunjuk visual statik bersama-sama sebarang gerakan supaya pengguna yang menyahaktifkan animasi tetap mendapat maklum balas keadaan yang jelas.

Urutan pengumuman pembaca skrin. Gunakan rantau langsung (live region) untuk menyiarkan perubahan keadaan, tetapi uji urutan tersebut dengan teliti. Urutan pengumuman harus sepadan dengan perkembangan peristiwa yang logik. Jika butang dinyahaktifkan sebelum pembaca skrin menyebut "Stop requested," uji sama ada urutan itu menimbulkan kekeliruan. Pepijat masa yang kecil dalam teknologi bantuan boleh mengelirukan mesej, jadi sahkan dengan pembaca skrin sebenar dan bukannya menganggap bahawa markup sahaja sudah mencukupi.

Intipati Sebenar

Membina butang henti kecemasan yang boleh diakses bermaksud menghormati pengguna anda dengan cukup untuk memberitahu mereka kebenaran. Antara muka harus bercakap secara terus terang, bergerak secara boleh diramal, dan jangan sesekali berpura-pura bahawa sesuatu permintaan adalah sama dengan hasil. Apabila tekanan tinggi dan data berisiko, kejelasan menyelamatkan lebih daripada sekadar masa. Ia menyelamatkan kepercayaan. Butang henti yang jujur bukan sekadar menghentikan tugasan. Ia membuktikan produk anda selamat untuk dikendalikan sejak dari awal lagi.