it-swarm.asia

Apa praktik terbaik untuk merancang pesan kesalahan formulir?

Saya telah melihat cukup banyak penelitian tentang desain formulir, tetapi sejauh ini, saya belum menemukan studi tentang praktik terbaik desain pesan kesalahan. Satu-satunya saran tampaknya adalah bahwa setiap kesalahan harus dengan jelas dikaitkan dengan bidang formulir tidak valid yang bertujuan untuk diperbaiki. Apakah ada penelitian tentang ini?

Saya memiliki beberapa masalah spesifik yang saya coba selesaikan dan akan sangat menghargai wawasan atau sumber daya apa pun.

Lokasi pesan kesalahan

Ketika Anda memiliki validasi formulir langsung, di mana seharusnya pesan kesalahan (atau sukses) muncul dalam kaitannya dengan elemen formulir?

Beberapa opsi:


Di sebelah kanan input

mockup

nduh sumber bmml - Wireframes dibuat dengan Balsamiq Mockups


Di sebelah kanan label

mockup

nduh sumber bmml


Di atas label

mockup

nduh sumber bmml


Di bawah label

mockup

nduh sumber bmml


Di bawah input

mockup

nduh sumber bmml


Ada beberapa masalah pelik yang juga perlu dipertimbangkan terkait lokasi:

  • Bagaimana kesalahan ditampilkan untuk radio atau grup kotak centang?
  • Seberapa luas pesan kesalahannya?
  • Apakah pesan kesalahan multi-line?

Visibilitas pesan kesalahan

Selain lokasi, saya juga tertarik pada bagaimana visibilitas pesan kesalahan mempengaruhi kegunaannya. Apakah itu penting atau hanya keputusan estetika? Pertimbangkan 3 opsi berikut:

mockup

nduh sumber bmml

Edit : Ada beberapa poin bagus tentang aksesibilitas di beberapa jawaban sejauh ini, serta beberapa contoh menarik. Namun, saya benar-benar ingin melihat beberapa data dari studi aktual, jika memungkinkan. Juga, tidak ada jawaban sejauh ini yang benar-benar menjawab dua pertanyaan yang saya miliki di atas:

  • Di mana letak kesalahan terkait dengan input dan label?
  • Bagaimana desain dan visibilitas pesan kesalahan itu sendiri mempengaruhi kegunaannya?

Mengenai aksesibilitas formulir, menurut saya seolah-olah ada dua kasus penggunaan yang berpotensi saling bertentangan, validasi langsung dan validasi sisi server (yang akan membutuhkan memuat ulang halaman). Jika halaman dimuat ulang dan pengguna mulai lagi di bagian atas formulir, ringkasan kesalahan masuk akal, terutama dari perspektif aksesibilitas. Namun, dalam kasus validasi langsung, ringkasan kesalahan di bagian atas kurang masuk akal, baik untuk desain formulir dan untuk tujuan aksesibilitas.

Pertimbangkan bagaimana pengguna akan benar-benar menggunakan formulir dengan validasi langsung:

Validasi terjadi pada peristiwa blur. Biasanya, fokus akan berada pada elemen bentuk berikutnya, bukan daftar di atas. Ketika saya memahami pembaca layar, tidak akan ada alasan untuk kembali ke atas formulir untuk membaca daftar kesalahan. Untuk pengguna yang tidak menggunakan pembaca layar, daftar kesalahan di bagian atas mendorong seluruh formulir ke bawah, jadi dua kali lipat jika kesalahan memakan ruang vertikal di dekat bidang formulir juga. Dalam bentuk yang lebih lama, ini adalah masalah kegunaan karena ringkasan kesalahan mungkin tidak terlihat. Dalam formulir yang lebih pendek yang memiliki kesalahan per-bidang, seperti login, ringkasan kesalahan hanya terlihat seperti berlebihan. Untuk semua bentuk, antarmuka akan didorong ke bawah, membuat pengalaman pengguna yang buruk.

Untuk validasi langsung, jika Anda benar-benar ingin membuat kesalahan formulir dapat diakses, saya pikir menggunakan ARIA Live Region mungkin solusi yang lebih disukai.

152
Virtuosi Media

Bendera yang dienkapsulasi adalah satu-satunya solusi yang saya temukan yang menjangkau semua kasus Edge. Mengarahkan bendera pada label daripada input memungkinkan konsistensi dengan tombol radio dan memeriksa kelompok tanda atau input aneh seperti slider atau penyortir.

Menyorot bidang dengan warna merah juga membantu, tetapi tidak selalu memungkinkan. Contoh penggunaan di bawah ini.

mockup

nduh sumber bmml - Wireframes dibuat dengan Balsamiq Mockups

mockup

nduh sumber bmml

mockup

nduh sumber bmml

Dalam membaca jawaban @ jonW, saya sangat setuju dengan pemikirannya tentang pembaca layar, dan solusi saya bisa sama efektifnya tergantung pada implementasinya. Anda dapat menempatkan bendera di utara pada input di markup, dan menggunakan aria untuk mencapai aksesibilitas yang sama


Bagian "Acara Validasi dan Validasi Inline" pada halaman ini tampaknya ideal: http://semantic-ui.com/modules/form.html

61
Fresheyeball

Tampaknya Anda sudah menandai bidang formulir opsional instad yang diperlukan . Tampaknya tidak ada indikator 'wajib', tetapi juga tidak ada indikator 'opsional', jadi saya ingin menyebutkannya.

Apa yang ingin saya lakukan pada formulir adalah "micro-gamify" mereka: Untuk setiap bidang dalam formulir berikan "indikator validasi". Untuk kesederhanaan, katakanlah itu hanya lingkaran kecil. Ini dimulai pada posisi netral: Lingkaran abu-abu dengan tanda tanya. Untuk bidang opsional, ini adalah lingkaran abu-abu dengan tanda centang. Setiap kali pengguna meninggalkan bidang formulir, itu divalidasi langsung dan hal-hal berikut terjadi:

  1. indikator berubah menjadi "sukses", mis. lingkaran hijau + tanda centang, atau "kesalahan" (mis. lingkaran merah + tanda seru)

  2. jika ada kesalahan, bidang tersebut disorot

  3. jika ada kesalahan, tombol kirim akan berwarna abu-abu (mengkliknya masih berfungsi, tetapi hanya akan membawa pengguna ke kesalahan pertama) dan pesan informasi umum akan ditampilkan di atasnya.

Jika Anda menulis petunjuk yang baik, cukup dengan menyorot bidang dan petunjuknya saja. Jika Anda merasa membutuhkan pesan kesalahan yang terpisah, kemungkinan petunjuk Anda dapat menggunakan beberapa pekerjaan. Dalam pengalaman saya hampir selalu mungkin untuk menutupi kesalahan input pengguna dengan petunjuk yang baik.

enter image description here

Pengguna tidak suka secara mental kembali dalam bentuk. Ini diproses bidang demi bidang, pengguna berfokus pada bidang demi bidang, dan melewati daftar periksa mental. Dengan menunjukkan kesalahan saat terjadi, kami mendukung mode ini dan tidak membuat pengguna kembali "nanti". Ini adalah jeda dalam aliran pengguna dan gangguan untuk mengklik "kirim" dan kemudian "diblokir" dan "dikirim kembali". Ini adalah pengalaman yang jauh lebih lancar jika masalah hanya disorot, dan dengan demikian dapat diperbaiki, saat terjadi.

44
Christian

Pesan kesalahan akan muncul sebelum bidang formulir itu sendiri (minimal di markup itu sendiri, tetapi idealnya ditampilkan secara visual seperti ini di layar juga) sehingga ketika seseorang membaca formulir mereka membaca bahwa bidang telah kesalahan sebelum mereka kemudian membaca bidang yang dipermasalahkan - dengan cara itu pengguna disiapkan secara mental bahwa "isi bidang ini yang akan saya baca salah dan karena itu saya perlu mengubahnya".

Ini bahkan lebih penting untuk membuat formulir yang dapat diakses . Jika seseorang membaca formulir melalui screenreader mereka harus disajikan dengan kesalahan sebelum bidang formulir dibacakan untuk alasan yang sama seperti yang dijelaskan di atas. (Mereka tidak mau harus kembali setelah mendengar konten bidang dan lalu diberi tahu bahwa bidang tersebut memiliki kesalahan). Inilah sebabnya mengapa itu adalah label formulir itu sendiri yang perlu mengandung teks kesalahan, dan bukan hanya berupa sembulan atau peringatan skrip karena Anda tidak dapat menjamin bahwa pembaca layar atau peramban yang lebih lama akan dapat mendeteksi teks ini.

Juga, jika itu adalah formulir yang panjang, atau jika pengguna menelusuri melalui keyboard dan menggunakan tombol Tab beberapa bidang mungkin ada di bawah flip, jadi jika Anda Tab bawah formulir Anda mungkin tidak melihat bahwa ada kesalahan dalam bidang sampai Anda kemudian telah menabrak yang berikutnya (bidang akan bergulir ke tampilan tetapi jika pesan kesalahan di bawahnya kesalahan mungkin ditampilkan di luar layar).

Akhirnya, ada rute tambahan yang mungkin harus Anda ambil untuk pesan kesalahan Anda:

Anda harus merangkum kesalahan tepat di awal formulir sehingga pengguna tahu berapa banyak kesalahan ada, dan apa kesalahan itu. Benar-benar ini harus berupa tautan yang mengarahkan Anda ke bidang yang salah yang dipermasalahkan (namun alasan lain mengapa pesan kesalahan terhadap bidang tersebut harus ada sebelum bidang itu sendiri)

Banyak dari informasi ini dapat ditemukan di artikel WebAIM: Validasi Formulir yang Dapat Digunakan dan Diakses dan Pemulihan Kesalahan

Berikut ini sebuah contoh. Kesalahan ditampilkan di awal formulir dan juga tautan sehingga pengguna dapat dengan mudah menavigasi ke bidang yang dimaksud, di mana teks kesalahan juga ditampilkan:


mockup

nduh sumber bmml - Wireframes dibuat dengan Balsamiq Mockups

30
JonW

Ada kertas putih (2007) lama yang disajikan oleh Human Factors International yang memiliki beberapa data tentang pesan kesalahan. Kesimpulan yang muncul saat itu adalah:

... sebagian besar pengguna melewati tahap penyelesaian — di mana tujuannya adalah penyelesaian formulir — diikuti oleh fase koreksi atau revisi, di mana kesalahan diperbaiki ... kesalahan langsung sebagian besar diabaikan hingga formulir selesai.

Jadi, dari enam cara yang mungkin untuk menyajikan pesan kesalahan, ketiganya terbukti lebih efektif daripada yang lain.

  1. Sajikan kesalahan setelahnya, tertanam dalam formulir, sekaligus
  2. Sajikan kesalahan sesudahnya, disematkan dalam formulir, satu per satu
  3. Sajikan kesalahan setelah itu, dalam dialog, satu per satu

Jelas kami tidak akan melakukan nomor 3 lagi. Buku putih itu disebut "Apa yang telah kita pelajari: Melihat kembali pada 2007." Anda dapat mengunduhnya dari situs mereka, setelah mengisi formulir . :)

Itu tidak benar-benar berbicara tentang penempatan pesan kesalahan, kecuali dialog vesus tertanam, jadi tidak yakin apakah ini benar-benar bermanfaat.

10
Julia D

Apa yang akan saya sarankan hanyalah apa yang terlintas dalam pikiran sebagai solusi yang akan saya gunakan ketika saya membaca pertanyaan Anda, jadi jelas Anda mungkin tidak menemukan penelitian atau materi terkait untuk membuktikannya.

Saya secara khusus menjawab pertanyaan "Ketika Anda memiliki validasi formulir langsung, di mana seharusnya pesan kesalahan (atau sukses) muncul dalam kaitannya dengan elemen formulir?"

Bagaimana jika kita menunjukkan pesan itu, bukannya label itu sendiri, seperti apa

enter image description here

Saat dan ketika kesalahan diselesaikan (mengingat mereka adalah tingkat validasi sisi klien), Anda dapat kembali ke tampilan asli label membantu pengguna melacak yang tersisa.

Agar pendekatan ini berhasil, Anda mungkin ingin menyampaikan pesan Anda dengan hati-hati untuk menyampaikan sepenuhnya apa yang perlu dilakukan pengguna dengan kata-kata yang sesedikit mungkin. Jika pesannya panjang, Anda bisa membungkusnya dengan panjang bidang.

4
roni

Tepat di atas tombol kirim, mungkin ada daftar item wajib dalam bentuk tag. Setiap tag harus di-hyperlink ke bidang masing-masing. Saat pengguna mulai mengisi formulir dari atas, tag terus menghilang. Sebelum pengguna menekan tombol kirim, ia dapat memverifikasi apakah semua bidang wajib diisi atau tidak. Jika dia melewatkan beberapa item, dia dapat dengan mudah menggulir kembali ke bidang dengan menekan tag yang sesuai.

4
Rutvij Kotecha

Karena pertanyaannya menyangkut hasil studi nyata, berikut ini tautan ke studi 2009 tentang berbagai variasi pesan validasi oleh Luke Wroblewski (penulis Fill in the Blanks).

Ini memberikan wawasan yang sangat menarik tentang cara terbaik untuk menampilkan pesan validasi, beberapa di antaranya mungkin menarik bagi Anda. Sebagai contoh,

[ON BLUR] METODE MEMBANTU PENGGUNA UNTUK MENGISI FORMULIR LEBIH CEPAT Ketika kami menggunakan metode "setelah" ([blur]) ..., peserta mengisi formulir tujuh hingga sepuluh detik lebih cepat daripada ketika kami menggunakan "sementara" ([pada keystroke]) dan metode "sebelum dan sementara" masing-masing.

Sejauh posisi pesan kesalahan, penelitian mengungkapkan hal itu

BUKANLAH JAUH — TETAPKAN PESAN KEBERHASILAN DI BENTUK LUAR BENTUK FORMULIR Menampilkan validasi di dalam bidang formulir gagal memberikan manfaat besar. Posisi pesan-pesan ini — tentu saja — tidak konsisten. (Meskipun dimungkinkan untuk membuat pesan validasi muncul di dalam bidang formulir, jauh lebih sulit untuk menampilkannya di dalam daftar drop-down standar, jadi kami menampilkannya di luar elemen-elemen ini.) Validasi di lapangan tidak lebih terlihat daripada pesan yang ditampilkan di luar Lapangan.

2- Mengenai visibilitas pesan (warna, dll.), Inilah artikel lain menyarankan Desainer UX untuk mengurangi tingkat keparahan pesan-pesan itu dan benar-benar membuat pengguna merasa senang dengan kemajuan mereka (dan tidak frustrasi atas tidak ada perkembangan)

Antara lain, itu pada dasarnya mengatakan bahwa kita harus menggunakan warna oranye/oranye untuk pesan kesalahan bentuk: cukup mengkhawatirkan ketika pengguna melihatnya tetapi kurang merangsang secara fisik sebagai merah (kemungkinan menyebabkan mereka panik).

3
Son Do Lenh

Saya belum menemukan studi apa pun di mana tempat terbaik untuk meletakkan pesan validasi. Namun, dari sudut pandang praktis, saya pikir pedoman antarmuka pengguna cukup dekat. Microsoft diketahui telah melakukan banyak penelitian langsung di laboratorium kegunaannya untuk mendapatkan informasi dalam pedoman mereka. Seperti yang kita semua suka memilih Microsoft untuk beberapa praktik UI yang buruk, umumnya praktik itu tidak mengikuti Pedoman Desain Antarmuka Pengguna mereka :)

Jadi ... Microsoft Pedoman Interaksi Pengalaman Pengguna Windows pada dasarnya memilih tanda bintang di sebelah kiri label dan tooltip dengan pesan :

mockup

nduh sumber bmml - Wireframes dibuat dengan Balsamiq Mockups

Pedoman ini juga membuat beberapa poin wawasan, yang telah saya rangkum di bawah ini:

  • Jika sebagian besar kontrol bersifat opsional, jangan tunjukkan apa pun (Menangani input yang diperlukan yang hilang dengan pesan kesalahan. Pendekatan ini mengurangi kekacauan.)
  • Jika sebagian besar kontrol memerlukan input, tunjukkan input opsional dengan "(opsional)" setelah label.
  • Jika semua kontrol memerlukan tempat input "Semua input diperlukan" di bagian atas area konten.
  • Validasi input lebih awal, tampilkan kesalahan di dekat titik input.
  • Gunakan balon sembulan untuk kesalahan input pengguna yang dapat dideteksi dengan segera . * Balon tidak memerlukan ruang layar yang tersedia atau tata letak dinamis yang diperlukan untuk menampilkan pesan di tempat.
  • Hanya tampilkan satu balon pada satu waktu.
  • Gunakan kesalahan di tempat untuk deteksi kesalahan yang tertunda (mis. Setelah mengirimkan formulir).

Menariknya, tidak ada banyak detail dalam Panduan Antarmuka Manusia Apple pada topik ini, tetapi di bawah ini adalah ringkasan dari poin yang relevan yang saya temukan:

  • Validasi input awal
  • Hindari memvalidasi input setelah setiap keystroke. Untuk sering validasi menjengkelkan.

Sekali lagi, sementara saya menyadari ini bukan "studi tentang praktik terbaik desain pesan kesalahan", saya yakin penelitian masuk ke dalam pembentukan pedoman ini dan sebagai alat praktis mereka adalah titik acuan yang bagus untuk topik ini.

2
Scott Willeke

Menandai bidang yang harus diisi dengan * atau menandai bidang mana yang opsional dengan (opsional) - yang paling tergantung pada titik kritis dalam formulir.

Jika Anda memiliki formulir yang panjang - misalnya 40 bidang (untuk melebih-lebihkan -Saya tidak menyarankan formulir harus memiliki 40 bidang pada satu layar) dan dari 40 bidang tersebut, diperlukan 36, kemudian menandai 36 dengan * keduanya berisik dan menjadi berlebihan.

Jauh lebih mudah untuk membuat pernyataan di atas bahwa 'semua bidang wajib diisi kecuali yang ditandai opsional'. Sebaliknya formulir dengan bidang yang relatif sedikit harus menunjukkan yang diperlukan.

Dengan kata lain yang mana yang perlu kita sorot sebagai pengecualian.

Tren ke arah formulir web yang menghadap publik adalah hanya meminta informasi yang diperlukan untuk mengurangi tingkat drop off, maka langkah menuju penandaan opsional daripada diperlukan karena semuanya cenderung diperlukan. Ini tidak selalu terjadi pada sistem perusahaan/bisnis meskipun ada dalam bentuk mendalam yang sah yang berisi bidang opsional dan wajib yang sah.

Sehubungan dengan pertanyaan utama penempatan pesan kesalahan:
Hal ini tergantung pada tata letak desain formulir sehubungan dengan bidang label->.
Dengan asumsi label di atas bidang, saya akan menempatkan pesan kesalahan di sebelah kanan lapangan dan memberikan sebanyak mungkin isyarat visual, seperti menyoroti batas bidang dengan warna merah serta 'bidang ini diperlukan' di merah.

Alasan:
1) penempatan proksimal pesan kesalahan ke bidang
2) tidak merusak kedekatan dan asosiasi label (yang menempatkan kesalahan antara label dan bidang)
3) pesan kesalahan Anda bertindak sebagai rambu apa yang perlu diperbaiki (teks menunjukkan caranya). Dalam hal ini Anda ingin plang Anda menjadi panah yang menunjuk pada hal yang sebenarnya perlu dilakukan oleh pengguna, yaitu bidang, bukan label.
4) perpesanan jenis tooltip bukan konvensi yang mapan dan seperti orang lain telah menunjukkan risiko atau menutupi item (tidak mungkin saya tooltip yang sebenarnya di mana pengguna mengambil tindakan untuk melakukan ini) - itu juga tidak mungkin baik untuk aksesibilitas.

Kesan awal saya tentang ikon gaya wajah + highlighting + message adalah karena sensorisnya berlebihan. Saya tidak yakin di mana mata saya harus fokus untuk mendapatkan informasi. Lapangan adalah apa yang perlu diperbaiki di tengah tetapi ada informasi visual berlomba untuk perhatian saya sebelum dan sesudah ini, yang berarti banyak gerakan mata dan upaya bagi pengguna untuk mencerna makna (hipotesis murni, saya tidak pernah menjalankan pengujian pengguna pada set-up form hampir sama)

2
GlenFinch

Setelah membaca Desain Formulir Web: Mengisi Kosong dan meneliti tentang ini di web saya menemukan bahwa yang terbaik berada di bawah input atau di sebelah kanan input.

Juga anggapan bahwa * = Diperlukan tidak selalu benar, beberapa orang tidak tahu itu. Cara paling populer untuk melakukannya adalah memiliki penjelasan apa * yang ada di bagian atas formulir. Atau favorit saya adalah menyingkirkan semua bidang yang tidak diperlukan dan memiliki "semua bidang yang diperlukan" atau yang serupa di bagian atas formulir.

2
Igor-G

Saran bagus dibuat tentang ringkasan bidang yang diperlukan di atas formulir sebagai penarikan.

Saya akan mengatakan bahwa contoh pertama yang ditunjukkan di sini adalah yang agak bagus (pesan kesalahan di sebelah yang diajukan itu sendiri). Anda mungkin ingin menyorot bidang dalam warna merah juga tetapi tidak terbukti lebih efektif.

Sekarang mengenai masalah tombol radio, saya akan mengatakan bahwa jika Anda memerlukan pesan kesalahan untuk tombol radio, itu berarti bahwa tombol radio bukanlah pilihan desain yang tepat di tangan pertama: memang, pada dasarnya, a tombol radio HARUS dan HARUS HANYA miliki satu opsi tunggal dipilih secara default. Ini berarti bahwa tombol radio harus selalu menyajikan opsi default yang dipilih, apakah itu pilihan "tidak ada". Dalam kasus lain, Anda harus mempertimbangkan untuk menggunakan opsi desain lain yang sesuai dengan kebutuhan Anda (mis .: kotak centang jika beberapa opsi mungkin dipilih, atau menu dropdown atau apa pun).

2
Ivan

Pesan kesalahan yang mengkhawatirkan dapat membuat pengguna cemas. Kecemasan pengguna dapat menyebabkan pengguna meninggalkan formulir Anda. Anda tidak perlu menekankan seberapa buruk pengguna mengacaukannya agar mereka memperbaikinya.

Meyakinkan pesan kesalahan akan membuat pengguna merasa lebih nyaman memperbaiki kesalahan mereka. Tujuannya adalah untuk menarik perhatian mereka dan membimbing mereka untuk memperbaiki kesalahan mereka, bukan mengesankan mereka bahwa mereka membuat kesalahan besar.

1
Relvid

Sayangnya, sepertinya tidak ada cara "standar" untuk menampilkan kesalahan dari, yang merupakan pertanyaan awal.

Saya mencoba mencari jawaban yang lebih terperinci, tetapi saya pikir tidak ada solusi yang pasti karena ada begitu banyak gaya bentuk yang berbeda. Formulir yang dilihat di desktop umumnya akan memiliki lebih banyak ruang untuk teks kesalahan daripada formulir di perangkat seluler. Baru-baru ini, Anda bahkan harus berpikir tentang sistem operasi apa yang Anda rancang sekarang karena gaya modern Windows 8 (secara resmi Metro) memiliki pedoman gaya khusus untuk IE. Tambahkan fakta bahwa setiap browser modern memiliki gaya sendiri untuk validasi formulir HTML5, dan standarisasi ini menjadi berantakan.

Yang paling bisa saya temukan adalah seperangkat pedoman dari Jakob Nielsen ( http://www.useit.com/alertbox/20010624.html ). Panduan ini sangat luas, dengan satu-satunya aturan eksplisit adalah bahwa Anda tidak bisa hanya mengandalkan warna (mengubah teks untuk bidang merah) karena itu dapat menyulitkan pengguna dengan ketidakmampuan membaca. Pengguna buta warna atau mereka yang menggunakan pembaca layar tidak akan dapat membedakan teks.

Itu adalah satu-satunya reservasi yang saya miliki dengan solusi info yang diposting di sini. Apakah pengguna dengan disabilitas dapat membacanya?

Sebuah solusi bisa berupa adaptasi gaya yang digunakan oleh sebagian besar pengguna yang Anda targetkan (baik Microsoft, Google, atau Apple) dan ikuti itu.

1
Kevin G

berbagi salah satu pendekatan yang saya rancang untuk proyek yang sangat intensif dan itu dihargai oleh tim tetapi karena beberapa kendala kami tidak bisa membangunnya.

Interaksi - saat Anda memindahkan UI kursor Anda akan menampilkan pesan instruksi sisi klien untuk memperbaikinya sebelum memicu tombol kirim.

enter image description here

1
Rajesh R. Nair

Saya pikir google memiliki solusi sederhana untuk pesan kesalahan pada formulir pendaftaran mereka; ubah batas menjadi merah untuk menyorot bidang dan pesan sederhana di bawahnya dengan pesan berwarna merah.

Ini mudah ketika menskalakan desain ke perangkat kecil dan jelas dan ringkas.

0
Jay

Saya pikir cara Facebook menampilkan pesan kesalahan adalah yang paling efisien dan ramah pengguna. Periksa tangkapan layar. Yang ini tidak memakan ruang ekstra. Pengguna mendapatkan apa yang salah dan juga untuk mengetahui secara lebih rinci, ia hanya bisa mengarahkan di lapangan untuk mengetahui mengapa bidang itu wajib . enter image description here

0
Parag Bandewar

Saya setuju dengan orang lain bahwa harus ada ringkasan. Apakah itu akun tertentu atau "Ada yang salah di sini. Harap tinjau setiap entri yang disorot, buat perubahan yang diperlukan, dan kirim kembali formulir. Terima kasih."

Pesan ini bisa di bagian atas, atau di bagian bawah dengan mengirimkan formulir, tetapi itu hanya harus terlihat dan menonjol bagi pengguna, tanpa menggulir, segera. Jadi, jika sihir javascript dapat menjaga halaman turun dengan tombol kirim, bagus. Di situlah pengguna berada, jadi ada lebih sedikit pemindahan halaman/berkedip.

Lalu, saya pikir konvensi paling sederhana adalah versi "Below the label", dari contoh Anda. Labelnya adalah bagaimana pengguna pertama kali akan berorientasi, dan memiliki teks kesalahan tepat di bawahnya masuk akal, dengan tempat yang dapat ditindaklanjuti (bidang), tepat di bawah.

Saya suka contoh 'kotak merah', dan gelembung melayang, tetapi UI favorit saya untuk ini adalah salah satu tempat bidang yang dimaksud adalah:

  • Ditandai dengan teks kesalahan yang terlihat berbeda dari warna. Miring atau tebal dengan warna lebih baik dari sekedar warna. Warna unik (dengan merah sebagai standar) bagus, tapi kita semua tahu tentang pengguna buta warna, bukan?
  • Berdiri dari bidang lain dengan cara di luar teks dan warna teks. Akan sangat keren jika semua bidang "ok" akan sedikit abu-abu, sehingga orang dapat melihat yang membutuhkan pengeditan menonjol dalam kontras yang lebih tajam. Namun, jika seseorang ingin mengedit salah satu bidang "ok" ini, klik harus tetap 'membukanya' untuk pengeditan 'cerah'.
0
Tom Quick

Saya ingin mengatakan apa yang dikatakan JonW dengan sedikit perubahan. Untuk para pengguna pembaca layar, Anda ingin meringkas kesalahan di bagian atas formulir. Kemudian, setelah Anda masuk ke formulir, Anda ingin memberi tahu pembaca layar tentang kesalahan individu sebelum bidang.

Saya menghadapi masalah ini di tempat kerja dan ingin menemukan metode yang dapat digunakan dan diakses. Saya menemukan posting blog ini http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ yang sangat membantu. Karena saya bekerja dalam pengembangan aplikasi untuk sebuah Universitas, hal-hal seperti ini sangat penting.

Ada praktik terbaik - metode yang terbukti berhasil - tetapi tidak ada yang mengalahkan pengujian pengguna nyata. Ini sangat berharga.

Contohnya bergantung pada jQuery dan plugin yang divalidasi.

Untuk meringkas:

  • Kelompokkan semua kesalahan bersama-sama sehingga pengguna dengan teknologi bantu (AT) memahami apa yang salah dari sudut pandang burung.
  • Tempatkan kesalahan individual di atas masing-masing bidang isian sehingga AT memperingatkan pengguna akan kesalahan sebelum mereka menyelesaikan isian tersebut.
  • Jika memungkinkan, tautkan kesalahan yang diringkas ke masing-masing bidang yang dimaksud, seperti dalam contoh.

Terakhir, jika Anda memerlukan format tertentu, pastikan Anda menyebutkan format dalam label untuk mengurangi jumlah kesalahan (dan untuk membuat kehidupan lebih mudah bagi mereka yang tidak bisa melihat dengan baik atau tidak sama sekali).

0
zxbEPREF

Selalu terbaik untuk

  1. Tampilkan pesan kesalahan sebaris
  2. Dan Setel fokus ke Bidang Mandat Pertama dibiarkan kosong atau bidang dengan data yang tidak valid setelah pengiriman formulir.

Dalam kasus validasi Real time/live data

  1. Memfokuskan Field Red dan menampilkan pesan kesalahan sebaris

Dalam hal validasi sisi server-untuk misalnya. Di mana js dinonaktifkan -

  1. Masih menampilkan pesan kesalahan sebaris dengan fokus ke bidang kosong atau bidang dengan data yang tidak valid

Latihan biasa -

  1. Validasi data harus real time (Tip alat menyarankan format yang tepat ketika pengguna memasukkan data yang tidak valid)
  2. Memeriksa bidang mandat harus terjadi pada pengiriman formulir - Ini membantu menghindari terlalu banyak intervensi sistem pada input data pengguna)

Tetap cara tradisional menandai bidang mandat dengan "*" adalah yang terbaik