Artikel Pendidikan

FORM

1.      Prinsip Form Design

Pengunjung situs web membenci mengisi formulir. Mereka ingin menyelesaikan tugas dalam jumlah waktu yang sedikit, dengan jumlah kerumitan dan usaha yang sedikit pula. Semakin lama formulir, semakin mereka menjadi tidak sabar, hanya pengunjung yang paling termotivasi akan mentolerir bentuk lebih dari satu halaman. Semua ini berkaitan dengan prinsip-prinsip bentuk desain yang mengikuti.

Mengurangi Upaya Fisik

Kebanyakan pengunjung tidak suka mengetik dan "keyboarding" lebih dari yang mereka miliki. Akibatnya, kita harus mengambil keuntungan dari setiap kesempatan kita harus meminimalkan klik pengunjung, penekanan tombol, gerakan mouse, dan bergulir. Secara khusus, jangan meminta setiap bagian dari informasi lebih dari satu kali, setiap kali ada kesempatan beberapa input data yang identik dengan data yang dimasukkan sebelumnya. Misalnya, jika pengunjung sudah memasuki alamat penagihan, kemudian memberikannya dengan shortcut memeriksa sebuah "sama seperti alamat penagihan" kotak untuk pengiriman alamat. Mengambil langkah lebih lanjut, kita dapat mengingat data dari pengunjung sebelumnya terjun di situs kami, seperti ketika Amazon meminta izin untuk menyimpan pengiriman seorang pengunjung dan informasi penagihan sehingga dia tidak perlu memasukkannya setiap kali ia berhenti masuk.

Mengurangi Upaya Kognitif

Selain meminimalkan upaya fisik dari mengetik, kita juga perlu untuk mengurangi upaya kognitif. Ini hampir tidak dikatakan bahwa bentuk harus sederhana dan mudah mengerti. Memilah halaman visual yang membingungkan, dengan banyak yang tampaknya tidak berhubungan dan elemen terorganisir, membutuhkan tenaga mental yang lebih banyak dari pengguna.

Hindari Meminta Informasi Dianggap Tidak Perlu

Pengunjung yang paling terganggu oleh pertanyaan-pertanyaan yang mereka pandang tidak relevan untuk kebutuhan mereka sendiri. Mereka mengakui bahwa pertanyaan pemasaran (demografi, minat dan hobi, dan sebagainya) tidak menguntungkan diri mereka sendiri tetapi organisasi induk situs Web sebagai gantinya. Ini adalah mengingat bahwa pengunjung akan sangat kesal jika pertanyaan tersebut bersifat non-task.

Kita harus berhati-hati tentang cara di mana kita meminta data jika diperlukan. Misalnya, sebagian besar pengguna dimatikan oleh situs yang tidak akan membiarkan mereka masuk sama sekali sampai mereka
memberikan beberapa informasi pribadi, bagaimanapun mereka belum tahu apakah situs tersebut layak? Mereka bahkan tidak yakin apakah situs tersebut dapat dipercaya. Akibatnya, banyak dari mereka tekan tombol Back, dan itu berarti selamat tinggal. Sebaliknya, jika pengunjung pertama kali melihat isi dari situs, mereka setidaknya memiliki kesempatan menjadi tertarik, dan kemungkinan akan lebih bersedia untuk memberikan informasi. Semua ini berkaitan dengan isu salience, atau kepentingan untuk pengunjung. Semakin tinggi arti-penting, para pengunjung lebih bersedia untuk melompat melalui lingkaran.

Jika beberapa informasi yang Anda minta diperlukan, sementara bidang lainnya adalah opsional, menggunakan beberapa petunjuk visual untuk menandakan yang mana, sehingga pengunjung dapat memilih untuk mengabaikan bidang opsional (yang mana, tentu saja, sebagian besar dari mereka akan melakukan). Menempatkan tanda bintang di samping semua bidang yang dibutuhkan adalah teknik umum yang sebagian besar pengunjung mengakui, seperti dalam Gambar 8.1.

Secara kolektif, berbagai elemen form seperti daerah input teks dan kotak centang yang disebut kontrol, form kontrol, atau widget, subyek bagian berikutnya.

2.      Kontrol Input

Kontrol input yang dibungkus dalam tag <form> yang menentukan nama formulir sebagaimana serta metode dan tindakan yang harus terjadi ketika formulir dikirimkan. Dalam formulir, dua kategori kontrol umum menangkap masukan pengunjung:

a.       Sebelum mendefenisikan pilihan kontrol sebagai tombol radio, checkbox, dan kotak daftar.

b.      Teks kontrol memungkinkan pengunjung untuk memasukkan data teks-bentuk bebas.

Sebelum mendefenisikan kontrol pilihan meminimalkan keystrokes (tombol) pengunjung dan memastikan akurasi karena ada sejumlah pilihan, semua dijamin akan valid. Misalnya, kesalahan ketik dan kesalahan ejaan dieliminasi pada nama negara jika kita memberikan daftar drop-down pilihan (semua mungkin dieja dengan benar). Ini biasanya dalam kepentingan terbaik kami untuk menggunakan pilihan yang telah ditetapkan mengontrol setiap kali ada sejumlah pilihan dari mana pengunjung harus memilih.

Kadang-kadang, pilihan proses awal dapat menentukan pilihan yang, atau tidak, tersedia dalam proses selanjutnya. Pilihan sekunder ini disebut dependent pilihan (disebut juga pilihan saringan). Sebagai contoh, mungkin kami menawarkan pengiriman tarif murah dan satu hari pengiriman hanya untuk lokasi-lokasi di sebelah timur Sungai Mississippi. jika pelanggan memilih "barat Mississippi" bukan, maka pengiriman satu hari tidak ditawarkan sebagai pilihan dalam pemilihan yang berikut, seperti yang ditunjukkan pada Gambar 8.2.

Pada dasarnya, jika pengunjung tidak diperbolehkan untuk memilih opsi, Anda harus menghapusnya; sebagai gantinya, saring apapun pilihan yang menjadi tidak relevan karena pilihan sebelumnya. Karena penyaringan pilihan tergantung pada halaman yang sama sebagai pilihan awal dapat melibatkan beberapa program yang agak rumit, sering kali lebih mudah untuk menempatkan tergantung pilihan pada halaman berikutnya, seperti yang akan kita lihat dalam sedikit ketika kita melihat wizards. Kita akan melihat masing-masing dari tiga kontrol pilihan yang telah ditetapkan sebelum pindah ke kategori kontrol umum berikutnya, kontrol teks.

Radio Buttons

Tombol radio (atau pilihan buttons in terminologi Microsoft) digunakan dalam pilihan situasi tunggal, yaitu, hanya satu pilihan diperbolehkan dari pengelompokan alternatif terkait. (Pikirkan "Pilih salah satu dari pilihan berikut.") gambar 8.3 menunjukkan kelompok tombol radio untuk memilih satu tahun di sekolah. Tombol radio adalah lingkaran, sedangkan HTML centang (datang segera) adalah persegi.

Ini sangat penting untuk tombol radio visual entah bagaimana, sehingga jelas yang unsur-unsurnya dikelompokkan. Pada gambar 8.4 menunjukkan, menyelesaikan ini dengan menggunakan sebuah baris header menonjol antara kelompok-kelompok tombol radio. Metode lain akan menggunakan <field set>. Setidaknya, memberikan spasi ekstra sekitar kelompok radio.

Checkbox

Checkbox mirip dengan tombol radio, tapi mereka digunakan ketika pilihan adalah tidak eksklusif satu sama lain. Artinya, pengunjung dapat memilih beberapa item dari dalam grup kotak centang. (Pikirkan "Pilih semua yang berlaku.").

Gambar 8.5 menunjukkan kelompok checkbox setelah pengguna telah membuat satu pilihan. Perhatikan bahwa kotak centang yang, seperti yang Anda duga, sebuah kotak persegi.

Kode di sidebar menunjukkan centang dikelompokkan tetapi centang juga bisa digunakan secara individual. Contoh klasik tunggal, biner "ya/tidak" kotak centang adalah salah satu yang kita semua temui: tipe kecil, otomatis diperiksa, "Ya, saya ingin menerima penawaran khusus, atau dikenal sebagai spam" pertanyaan yang diajukan oleh begitu banyak websitus. (Worded sedikit kurang terang, tentu saja).

Seperti dengan tombol radio, kotak centang dalam perbatasan dan / atau memberikan tambahan ruang putih antara kelompok dan elemen halaman lainnya membantu untuk menunjukkan bagaimana
kotak centang yang terkait. Setiap daftar vertikal kotak centang harus menyesuaikan dengan tepat, satu di atas yang lain.

Daftar Box

Ketika pilihan begitu banyak yang tombol radio atau kotak centang akan mengambil terlalu banyak ruang di layar, kita malah dapat menerapkan daftar kotak. kotak daftar biasanya digunakan untuk pilihan seperti negara, negara, atau tanggal, serta untuk melompat menu. Gambar 8.6 menunjukkan drop-down box yang khas, pertama karena menampilkan pada beban halaman, dan kemudian karena akan ditampilkan ketika pengunjung telah mengklik panah "Down ".

Kotak daftar memang mengganggu banyak pengguna. Kebanyakan dari kita akan lebih suka memasuki dua karakter singkatan negara dalam kotak teks daripada bergulir melalui panjang daftar negara (terutama jika kita hidup di Wyoming). Namun demikian, kotak daftar benar-benar menjamin bahwa setiap masukan yang disampaikan adalah pilihan yang valid. Itu saja membuat kotak daftar layak faktor gangguan mereka.

Pikirkan baik-baik tentang urutan item daftar. Menyajikan item dalam alphabetikal atau perintah numerik adalah solusi yang paling jelas. Namun, dalam situasi di mana beberapa elemen dalam daftar yang dipilih jauh lebih sering dari pada yang lain, dapat membuat akal untuk memindahkan pilihan ke bagian atas daftar, dan mungkin bahkan menentukan salah satu yang paling umum sebagai default yang dipilih. Sebagai contoh, sebuah perusahaan yang berbasis di Amerika Serikat mungkin menunjukkan AS sebagai default di bagian atas daftar, seperti yang ditunjukkan pada gambar 8.7. Meski begitu, para ahli kegunaan dibagi dalam masalah ini, dengan beberapa menyarankan bahwa perintah standar dengan pilihan default dipilih adalah ide yang lebih baik.

Sebuah kotak daftar dapat diimplementasikan sebagai daftar drop-down atau sebagai daftar yang dapat digulir. Mari kita lihat
di masing-masing.

Drop-down List Box

Jika Anda menetapkan size = "1", yang sebenarnya adalah default pada tag <select>, hanya satu Pilihan awalnya ditampilkan dalam kotak daftar, dan sisanya dari daftar turun ke bawah ketika pengunjung mengklik pada panah scroll, seperti yang Anda lihat pada gambar 8.6. Item pertama
biasanya bukan pilihan yang valid, melainkan penjelasan, karena di sini dengan "Pilih satu ...". The HTML yang membuat daftar ini sebagai drop-down adalah sebagai berikut:

<select name="hobbies" id="hobbies" size="1">

Scrollable List Box

Sebuah ukuran yang lebih besar dari "1" menyediakan kotak scrollablelist, dengan size attribute yang menghalangi-pertambangan berapa banyak pilihan menunjukkan awalnya. Pilihan yang tersisa dapat diakses oleh bergulir. Gambar 8.8shows kotak daftar dengan size = "5":
<select name="hobbies" id="hobbies" size="5">

Multiple-pilihan List box

Jika multiple attribute termasuk dalam tag <select>, apakah drop-down atau digulir, pengunjung dapat memilih beberapa elemen dari daftar, seperti yang ditunjukkan pada Gambar 8.9. Satu-satunya perubahan dari HTML pada contoh sebelumnya disorot dalam tag <select> ini:
<select name="hobbies" id="hobbies" size="5" multiple>

Kombinasi size = "1" dan multipleattribute, seperti ini:

<select name="hobbies" id="hobbies" size="1" multiple>

Perubahan perilaku tag <select>. Alih-alih menampilkan daftar drop-down dari semua atribut, karena biasanya jika size = "1", daftar ini digulir dengan hanya satu item yang menunjukkan pada suatu waktu, seperti pada Gambar 8.10. Karena melihat hanya satu item pada suatu waktu adalah sesak dengan pengunjung, biasanya lebih baik untuk menentukan ukuran pada setidaknya tiga atau empat item.

Pengelompokan List Box Pilihan di Bawah Header

            Item <option> individu dalam <select> dapat dikelompokkan di bawah khusus untuk-kusut, sundulan non selectable menggunakan wadah <optgroup>. Misalnya, dalam gambar 8.11, baik "Hobi" maupun "Olahraga" garis dipilih.

Single-line Area Text Input

Single-line daerah input teks ditentukan dengan tag <input />, seperti ini :

< input type = "text" name = "kota" id = "kota" value = "Chicago " maxlength = "30" size = "20" / >

Nilai pilihan atribut memberikan nilai default yang tidak hanya ditampilkan di area input pada beban halaman, tetapi juga diajukan untuk field kecuali pengunjung lain perubahan itu. Luas opsional atribut menentukan jumlah karakteristik pengunjung akan diizinkan untuk masuk.

Ukuran command opsional menentukan ruang horisontal area masukan diperlukan di layar. Biasanya, panjang visual lapangan harus mencerminkan yang sebenarnya. Ini akan menjadi konyol untuk mengharapkan pengunjung untuk memasukkan nama last full (maxlength = "25") di daerah masukan yang tampaknya hanya 6 karakter (size = "6"), seperti pada gambar 8.12. Meskipun field gulir untuk memungkinkan masuknya penuh 25 karakter, pengguna bisa melihat hanya sedikit karakter pada satu waktu, yang membuatnya sulit untuk mengetahui apakah dia memasukkan teks dengan benar.

Sebaliknya, itu sama-sama pantas untuk menyediakan pengunjung dengan 25 ukuran karakter untuk sembilan digit kode pos, seperti dalam kolom input bawah pada Gambar 8.12.

Bagaimana jika beberapa pengunjung harus jauh lebih dari pada karakter khas untuk sebuah tertentu masukan field? Misalnya, sebagian besar nama-nama terakhir dapat dengan mudah diakomodasi
dalam 15 karakter. Namun, pengunjung yang langka mungkin perlu 25 karakter. Kita mungkin enggan untuk mencurahkan ruang layar ekstra untuk mengakomodasi entri-entri lama langka.

Solusi kompromi adalah untuk mengatur size yang mengakomodasi mayoritas entri dan maxlength yang menampung orang-orang lagi. Sebagai contoh, kita bisa mengatur size bidang terakhir - nama hingga 15 karakter dan maxlength 25 karakter. Spesifikasi tersebut akan mengizinkan sebagian besar pengunjung untuk memasukkan nama mereka tanpa scroll, sedangkan pengunjung dengan nama lagi akan ditampung oleh bergulir.

Tapi meskipun kita biasanya ingin ukuran visual area masukan untuk mencerminkan perkiraan jumlah karakter yang diperbolehkan di lapangan, itu bisa kacau untuk membuat setiap bidang panjang yang berbeda. Dalam gambar 8.13, bentuk di sebelah kiri tidak memiliki visual yang koherensi karena sisi kanan field input tidak berbaris dengan satu sama lain. Bentuk di sebelah kanan jauh lebih menyenangkan secara visual, karena bidang yang sama panjang bila memungkinkan. Tampaknya kita harus temukan kompromi antara indikator panjang lapangan secara akurat dan membuat bentuk estetis menarik, atau paling tidak kacau.

Tanda Baca dan Formatting dalam Kontrol Input Teks

Jika field tanda baca telah tertanam di dalamnya, seperti tanda hubung, garis miring, atau spasi, itu baiknya untuk menunjukkan format itu, atau setidaknya memberikan beberapa indikasi ke pengguna untuk format yang kita harapkan. Misalnya, gambar 8.14 menunjukkan beberapa
cara membimbing pengunjung untuk memasukkan tanggal dengan benar.

Baris pertama pada Gambar 8.14 agak bermasalah. Meskipun melestarikan keystroke karena menghilangkan tanda baca, bahwa tanda baca dihilangkan bisa membantu dalam memverifikasi akurasi entri data. Misalnya, itu jauh lebih mudah bagi pengunjung untuk mengecek nomor telepon ketika sepertinya 815-555-1212 dari pada 8155551212. Mungkin saja bahwa dalam upaya untuk "memberi makan" kebutuhan web – mengunjungi masyarakat sibuk untuk mendapatkan segala sesuatu dilakukan dengan cepat, kita mengorbankan akurasi demi menyelamatkan orang-orang beberapa penekanan tombol.

Alternatif lain adalah untuk memungkinkan pengunjung untuk memasukkan data dengan cara apapun yang mereka suka, sementara
kita menggunakan bahasa scripting seperti Java Script untuk memformat dan menampilkan kembali data dalam format pilihan kami, termasuk tanda baca. Misalnya, pengunjung bisa memasuki nomor telepon di salah satu format yang dapat diterima berikut :

a.       8155551212

b.      (815) 555-1212

c.       815-555-1212

d.      815.555.1212

Kami kemudian akan menampilkan kembali lapangan dalam baru, diedit format sehingga pengunjung dapat melihat bahwa lapangan dimasukkan dengan benar. Misalnya, jika pengunjung mengetik 8155551212, yang sistem mungkin menampilkan kembali 815.555.1212.

Meskipun banyak ahli menganjurkan kegunaan seperti entry bentuk bebas, banyak pengunjung yang dimengerti bingung ketika mereka menemukan sebuah field input yang tidak menyediakan
petunjuk format sama sekali. Kebingungan tersebut cenderung membuat jeda pengunjung, yang mengalahkan prinsip-prinsip yang sangat kegunaan yang merekomendasikan bentuk-bebas masuk di tempat pertama.

Menyembunyikan Input Data pada Layar Kadang-kadang, area teks satu baris harus dilindungi sehingga seseorang melihat dari atas
bahu pengunjung tidak dapat membacanya. Misalnya, kita biasanya tidak menampilkan kata pas pada layar di mana mereka dapat dibaca oleh pengamat apapun. Dalam kasus seperti itu, Anda menggunakan type = "password" pada tag <input /> untuk menampilkan tanda bintang atau titik bukan karakter sebenarnya sedang dimasukkan oleh pengguna. Perhatikan bahwa type = "password" tidak melindungi atau mengenkripsi data dengan cara apapun, hanya menyembunyikan itu di layar.

Nilai default untuk Kontrol Text Input

Sebuah entri default untuk nilai atribut dapat menyimpan keystrokes pengguna dalam kasus-kasus di mana ada satu nilai yang mungkin yang jauh lebih umum daripada yang lain. Katakanlah
bahwa 90% dari pengunjung kami berasal dari Chicago. Jika kita memberikan "Chicago" sebagai nilai default untuk kota tempat tinggal, kita menghemat 90 % dari pengguna kami harus mengetikkan yang masuk tradeoff di sini adalah bahwa non orang Chicago kami harus pergi ke kesulitan menghapus "Chicago" dari lapangan sebelum memasuki nilai yang berbeda. Oleh karena itu, mungkin lebih baik untuk menggunakan default hanya jika itu berlaku untuk 80 % atau lebih dari pengunjung kami.
Ini membuat penggunaan kemungkinan valueattribute untuk memberikan petunjuk kepada pengunjung tentang apa yang harus masuk di lapangan, seperti pada gambar 8.15. Namun, praktik ini tidak banyak direkomendasikan, karena membawa kerugian serius:

a.       Menghapus petunjuk menambah lapisan lain usaha untuk semua pengunjung dan semua lebih bagi pengunjung dengan cacat fisik.

b.      Instruksi hilang setelah pengunjung mulai mengetik nilai baru.

c.       Jika pengunjung melompati field, instruksi akan diserahkan sebagai nilai kecuali jika Anda menangkap dan menangani kelalaian yang dengan script validasi.

Re-memasuki Fields Kritis

Untuk bidang orang penting yang tidak bisa mentolerir jenis kesalahan sama sekali, seperti memilih password, kita mungkin memerlukan pengunjung baru untuk mengetik lapangan dua kali, karena
cara menangkap sebagian kesalahan ketik. Salah satu cara untuk memastikan bahwa pengunjung tidak mencoba untuk mengakali kita dengan menyalin dan menyisipkan entri pertama ke yang kedua, sehingga mengabadikan setiap kesalahan yang dimasukkan dalam pertama, adalah untuk menempatkan entri kedua pada halaman kedua. gambar 8.16 menunjukkan bagaimana AMCORE Bank mengharuskan pengunjung untuk mengetik ulang sebuah nomor rekening billpayer pada halaman kedua.

Multi-saluran Area Text Input

Seringkali, input teks tidak dapat dibatasi hanya satu baris, perlu menjadi setara paragraf teks, seperti pada gambar 8.17. Berikut HTML:

Cols attribute ini menentukan lebar perkiraan lapangan, sementara rowsdictates ketinggian kotak. Jika pengunjung masuk lebih karakter daripada yang dapat ditampilkan dalam yang cols attributes rows and ditentukan, scrollbar akan muncul secara otomatis sehingga ia
dapat terus memasukkan teks. Perlu diingat bahwa browser mengalokasikan ruang untuk scrollbar dalam <textarea> bahkan tidak diperlukan.

The wrap attribute opsional menentukan apakah teks dibungkus dalam diberikan ruang dan apakah tombol enter yang disampaikan bersama dengan lapangan. Karena wrap attribute tidak termasuk dalam standar HTML resmi, beberapa browser lama tidak mendukungnya. Browser modern, bagaimanapun, tampaknya telah menetap di tiga nilai dimungkinkan untuk atribut ini :

a.       lunak (default): teks secara otomatis membungkus sebagai jenis pengguna, tetapi enter otomatis dimasukkan tidak tertanam di lapangan ketika itu disampaikan ke server.

b.      keras: Kata bungkus diaktifkan, sama seperti halnya dengan lembut, tapi sekarang kembali pembawaan dimasukkan disampaikan dengan lapangan.

c.       off : kata bungkus dimatikan, sehingga area teks terus gulir ke kanan sebagai jenis pengunjung. Hanya jika pengunjung menekan kembali atau enter apakah kursor drop down ke baris berikutnya.

Tag <textarea> memiliki kegunaan lain, di luar menangkap masukan pengunjung, tetapi juga dapat digunakan untuk menampilkan teks informasi yang perlu gulir. Sebagai contoh, lisensi perangkat lunak
perjanjian sering ditampilkan menggunakan tag <textarea>, dimana pengunjung mempekerjakan scrollbar untuk membaca perjanjian ( harus ia benar-benar memilih untuk membaca lisensi perangkat lunak, yaitu). Gambar 8.18 menunjukkan seperti contoh. ketika digunakan
untuk menampilkan teks, daripada input, kita dapat menambahkan read only attribute untuk tag sehingga pengunjung tidak dapat mengubah teks yang ditampilkan.

3. FORMULIR PENYELESAIAN

Kami biasanya menggunakan JavaScript untuk memvalidasi data secara lokal pada klien sebanyak dimungkinkan, untuk memastikan bahwa kita tidak menyerahkan data jelas tidak valid. Hanya setelah
Data divalidasi kita mengirimkan itu ke server web. Mari kita lihat pertama pada spesifik untuk memvalidasi data, dan kemudian menentukan pada tombol Submit.

Form Validasi

Validasi pada klien umumnya terbatas pada kelengkapan dan format. Untuk Misalnya, kita mungkin memvalidasi nomor pelanggan untuk memastikan itu tidak kosong, yang itu semua numerik, yang berisi jumlah yang tepat dari angka, dan bahwa itu adalah dalam rentang yang diijinkan tertentu. Apa yang kita tidak bisa lakukan dari dalam dokumen HTML adalah membuat yakin bahwa sejumlah pelanggan cocok dengan jumlah pelanggan yang sudah ada dalam basis data, validasi tersebut akan membutuhkan query server-side ke database pelanggan.

Idealnya, kita memvalidasi setiap field secepat fokus bergerak jauh dari itu setelah itu telah berubah. Dengan begitu, kami dapat menyediakan pesan kesalahan dan memungkinkan pengunjung untuk memasukkan kembali data segera, sebelum bergerak maju. Setelah seluruh formulir adalah disampaikan, semua data harus divalidasi lagi untuk menangkap apapun yang diperlukan field yang pengunjung mungkin telah terlampaui.

Situs web seperti http://javascript.internet.com menyediakan script gratis bagi banyak kesamaan memvalidasi tugas. Misalnya, Anda mungkin menemukan script untuk memvalidasi alamat email, memeriksa kode pos yang valid, atau menanggalkan ruang kelebihan dari entri teks.

Hal penting untuk diingat adalah bahwa setiap upaya untuk kesalahan format perangkap yang tepat jauh dapat menghemat perlu (dan dalam beberapa kasus mahal) terhadap pertanyaan server –side Database. Yang terbaik untuk menangkap dan memperbaiki banyak kesalahan sebanyak mungkin, secepat dimungkinkan, sedangkan pengunjung masih pada halaman. Kita akan membahas bersaing dengan kesalahan-kesalahan
di bagian Dukungan pengunjung.

Tombol Submit

Tombol submit, tentu saja, menyerahkan formulir dan semua datanya menggunakan perlakuan dan metode yang spesifikasi dalam tag <form>. Tombol dapat berupa standar, browser dihasilkan tombol Submit, atau tombol kustom yang dibuat dalam program editing gambar.
Gambar 8.19 menunjukkan contoh masing-masing, dan sidebar ulasan HTML

Menghindari Beberapa Submissions

Apakah menggunakan browser yang disediakan atau custom tombol Submit, kita tidak ingin membentuk akan sengaja disampaikan beberapa kali. Kita semua telah melihat halaman web yang
memperingatkan pengunjung untuk tidak mengklik sebuah tombol Submit dua kali. Sayangnya, jika pengajuan Dibutuhkan lebih dari sekedar satu atau dua detik, pengunjung dibiarkan bertanya-tanya apakah klik benar-benar terdaftar. Pada saat yang sama, dia takut untuk mengklik untuk kedua kalinya - setelah semua, dia telah memperingatkan konsekuensi jika dia klik yang kedua kalinya. Hanya berapa lama pengunjung menunggu dalam kasus seperti ini ?

Ada dua cara yang mudah digunakan untuk menghindari menyebabkan pengunjung kami semacam ini kecemasan :

a.       Segera meyakinkan pengunjung dengan umpan balik bahwa bentuk sedang dalam proses menjadi disampaikan, sering dilakukan dengan beberapa jenis animasi kecil. Ini adalah cara yang bagus, di bawah kondisi apapun, dari meyakinkan pengunjung bahwa ada sesuatu yang memang terjadi.

b.      Gunakan JavaScript untuk menonaktifkan tombol Submit setelah itu diklik, sehingga mencegah pengajuan ganda. Lihat sidebar untuk kode.

Atur Ulang Buttons

Ulang tombol kontrol jelas bentuk itu kembali ke nilai awal mereka pada beban halaman. Seperti Tombol submit, ulang tombol dapat browser disediakan atau kustom. Lihat sidebar untuk kode .

Banyak ahli kegunaan berpendapat bahwa kita seharusnya tidak pernah, pernah, gunakan tombol Reset, melainkan terlalu mudah bagi pengunjung untuk memukul sengaja, sehingga kliring beberapa menit
entri data. Dan seberapa sering pengunjung sengaja ingin menghapus seluruh? Jarang, tampaknya. Sebagian besar waktu, pengunjung yang ingin mengetik ulang satu atau dua tapi hampir tidakpernah lapangan perlu mengetik ulang bentuk keseluruhan. Selain itu, memukul browser "refresh" tombol akan melayani fungsi yang sama sebagai tombol Reset.

Jika Anda merasa perlu untuk menyertakan sebuah tombol Reset, menggunakannya dengan hati-hati, dan setidaknya Pastikan untuk menggunakan JavaScript untuk menangkap acara ulang untuk bertanya, "Apakah Anda yakin ...?", demikian double pemeriksaan pengunjung sebelum dia melakukan sesuatu yang tidak dapat diubah.

Submit dan Reset Tombol Petunjuk

Submit dan tombol Reset harus mudah untuk dilihat, dan harus terkait dengan form kontrol. Dalam setiap situasi di mana pengguna harus memilih antara dua atau tombol tindakan yang lebih, seperti Submit dan Reset, pastikan untuk posisi yang lebih aman atau tindakan positif di sebelah kiri, dan tindakan berisiko atau lebih negatif di sebelah kanan. Juga pastikan lahan fokus default pada lebih aman dari dua tindakan tersebut, dalam hal pengunjung memasukkan tanpa memperhatikan pilihan yang ditawarkan.

Setiap kali disebut akan ada konsekuensi yang tidak dapat diubah untuk tindakan seorang pengunjung ("fungsi kursi ejector"), pastikan untuk mengkonfirmasi bahwa tindakan adalah apa yang benar-benar dimaksudkan. Sebagai contoh, tidak pernah menghapus account, mengirimkan perintah, atau mengubah data kritis dalam database tanpa meminta terlebih dahulu, "Apakah Anda yakin ingin ______" (isi
kosong, tentu saja, dengan deskripsi dari tindakan kritis).

Setelah formulir sudah diserahkan ke server, pengunjung diyakinkan jika server mengirimkan kembali halaman respon yang menampilkan kembali informasi yang dimasukkan. Dengan cara itu,
mereka dapat memeriksa bahwa informasi yang mereka dimaksudkan untuk memberikan tidak hanya dimasukkan dengan benar, tetapi juga diterima dengan benar oleh situs web.

4. STRUKTUR TRANSAKSI

Pada bagian Arsitektur Site dari Bab 2, kita melihat menciptakan sebuah hirarki atau organisasi berurutan untuk halaman terpisah ke dalam arsitektur situs intuitif. Salah satu tugas yang diidentifikasi adalah untuk mengkategorikan informasi dan kemudian menggunakan kategori tersebut untuk membagi konten ke halaman individual. Sekarang kami bekerja dengan bentuk masukan. Namun, kita perlu memutuskan bagaimana membagi struktur transaksi di masing-masing halaman. Sebagai contoh, jika kita memiliki interaksi yang membutuhkan banyak informasi dari pengunjung, sebaiknya transaksi dipecah menjadi beberapa halaman, satu halaman per langkah, atau harus seluruh interaksi berlangsung pada satu halaman? Keputusan disini adalah antara menggunakan struktur penyihir atau struktur panel kontrol, yang keduanya adalah pilihan yang sah, tergantung pada keadaan.

Wizards

Sebuah wizardis itu linear, interaksi langkah demi langkah yang memuat satu halaman per langkah, dalam urutan yang didefinisikan. Sebagai contoh, sebuah wizard untuk menempatkan pesanan mungkin hadir satu halaman untuk meninjau item yang saat ini dalam keranjang belanja, halaman lain untuk memasukkan pengiriman informasi, dan satu lagi halaman untuk memasukkan informasi pembayaran. Lihat tiga halaman pertama wizard checkout Amazon pada gambar 8.20.

Wizards memiliki keunggulan tertentu :

a.       Seluruh proses tampaknya kurang besar untuk pengunjung dari versi satu halaman. Setelah semua, ketika dihadapkan dengan tunggal, panjang, rumit, bentuk bergulir, pengunjung terikat untuk bertanya-tanya apakah itu benar-benar layak usaha. Jika kita menyembunyikan beberapa bahwa kompleksitas awalnya, pengunjung lebih mungkin untuk melanjutkan.

b.      Wizards yang ideal untuk proses dimana beberapa langkah tergantung pada sebelumnya pilihan. Misalnya, proses sign-in (Langkah 2) pada gambar 8.20. Seorang pengunjung kembali membutuhkan proses yang agak berbeda dari pengunjung baru, karena baru pengunjung perlu mendaftar. Dengan wizard seperti ini, halaman berikutnya (mendaftar dibandingkan tidak perlu mendaftar, dalam kasus ini) dapat bergantung pada pilihan sebelumnya.

c.       Wizards memastikan bahwa tidak ada langkah-langkah yang melewatkan atau diselesaikan rusak, karena pengunjung tidak bisa bergerak maju sampai langkah saat ini berhasil diselesaikan.

d.      Kesalahan dilaporkan sementara pengunjung masih terfokus pada langkah tertentu dalam proses.

e.       Wizards ideal bagi pengunjung yang tidak teknis cerdas atau yang melakukan diberikan tugas hanya sesekali.

Tapi tentu saja ada beberapa kelemahan juga :

a.       Melanggar interaksi di beberapa halaman memerlukan beberapa beban halaman, meskipun yang setidaknya agak diimbangi oleh kenyataan bahwa setiap halaman yang lebih kecil download lebih cepat dari satu halaman panjang.

b.      Wizards tampak membosankan, rumit, dan merendahkan untuk pengunjung yangsudah akrab dengan proses.

Panel Kontrol

Alih-alih menggunakan struktur penyihir, kita bisa menempatkan seluruh interaksi pada satu (mungkin panjang) halaman, yang disebut panel kontrol. Gambar 8.21 memperlihatkan bagian dari Dell
kontrol panel untuk mengkonfigurasi komputer kustom. Keunggulan dan kerugian adalah, untuk sebagian besar, kebalikan dari yang tercantum untuk penyihir; panel kontrol setelan pengunjung yang akrab dengan proses dan ingin menyelesaikan tugas mereka sebagai
secepat mungkin. Perhatikan bahwa layar konfigurasi kustom Dell mungkin akan untuk digunakan terutama oleh pelanggan savvy-komputer pelanggan tetap akan lebih cenderung untuk membeli, sistem yang tidak disesuaikanr.

Pilihan Dependent (dibahas sebelumnya pada kontrol input) lebih sulit untuk program untuk kontrol dibandingkan untuk wizard. Sebagai contoh, hanya ada satu HTML satunya cara untuk menangani pengunjung yang kembali terhadap situasi pengunjung baru diperiksa terlebih dahulu. Anda harus menyajikan semua informasi untuk kedua pengunjung pada halaman yang sama, yang bisa berfungsi untuk membingungkan kedua penonton.

5. Tata Letak Form Masukan Halaman

Setelah memutuskan antara wizard dan kontrol panel, kita perlu merancang layout untuk setiap halaman. Bab 4 diperiksa pedoman untuk tata letak halaman pada umumnya, termasuk karakteristik garis, warna, grid, dan ruang putih untuk membuat halaman koheren visual. Namun demikian, kita perlu mempelajari beberapa tambahan halaman - layout
keprihatinan khusus untuk bentuk masukan.

Mengontrol Fokus Kursor dan Tab Order

Sebuah bentuk kontrol dikatakan memiliki focusif kursor sedang beristirahat diatasnya. Bentuk kontrol naturally memperoleh fokus mengikuti urutan lokasi mereka pada kode HTML kode. Misalnya, nilai default dalam kontrol di gambar 8.22A menunjukkan bagaimana tombol tab, secara default, melintasi bentuk kontrol kiri ke kanan, kemudian ke atas bawah. Sebagian besar waktu, urutan ini adalah cara kita ingin dan mengharapkan pengunjung untuk kemajuan melalui formulir, karena itulah bagaimana sebagian besar dunia barat membaca.

Tapi kadang-kadang, seperti disini bahwa tatanan alam tidak masuk akal, dan kita mungkin perlu melanggarnya. Kami ingin pengunjung untuk kemajuan vertikal ke bawah kiri kolom sebelum pergi ke bagian atas kanan, seperti dalam Gambar 8.22B.

Kita bisa mendikte urutan tab non -default ini dengan menetapkan tabindexvalue untuk masing-masing bentuk elemen yang terkena dampak, seperti ini :

<input type="text" tabindex="n"name="billAddress" id="billAddress" />

Saat kemudian halaman, kursor pada awalnya diposisikan pada kontrol dengan nilai terendah tab index lebih besar dari nol. Kursor kemudian berkembang melalui mengingat kontrol agar dengan naik tab index. Elemen kurang tabindexor dengan a tab index of nol datang terakhir dalam urutan tabbing, agar lokasi mereka di kode sumber HTML dokumen. (Di Internet Explorer, angka negatif menghapus item dari urutan tabbing seluruhnya.) Sidebar ini menunjukkan HTML untuk "kolom pertama" order tabbing Gambar 8.22B, dengan meja tata letak sekitarnya, format, dan atribut yang tidak relevan dihapus karena demi kesederhanaan.

Bahkan jika Anda tidak perlu menentukan urutan tabbing non-standar, Anda masih bisa mengatur fokus untuk kontrol tertentu di mana Anda ingin pengunjung untuk memulai entri data awal. Sebagai contoh,
bila pengunjung membuka www.google.com, kursor ditempatkan secara otomatis diarea input pencarian, siap dan menunggu untuk pengunjung untuk mengetik dalam frase pencarian. Secara otomatis mengatur fokus ke kontrol bentuk pertama menggambarkan bagaimana beberapa bijaksana
dapat menyimpan pengunjung sebuah keystroke yang tidak perlu atau gerakan mouse.

Untuk mengatur fokus pada beban halaman awal, tambahkan onLoadattribute berikut ke tag <body> , mengganti bentuk dan nama field Anda sendiri untuk formNameand field Name :

<body onLoad="document.formName.fieldName.focus();">

Menyajikan Input Controls Pada Masa Orde Yang Diharapkan

Terlepas dari di mana kita mengatur fokus, kita harus menyajikan kontrol input dalam urutan bahwa pengunjung akan mengharapkan untuk melihat mereka. Sebagai contoh, kita semua akan bingung jika
bentuk meminta kami untuk alamat kami dalam urutan yang ditunjukkan pada Gambar 8.23, karena kita terbiasa format jalan - negara kota -zip standar.

Contoh lain dari melanggar harapan agar pengguna akan meminta
nomor kartu kredit sebelum menampilkan item dalam keranjang dan menghitung pajak dan biaya pengiriman. Setelah semua, pengunjung akan ingin memastikan bahwa pesanan sudah benar sebelum pengisian kartu kredit. Penyimpangan dari urutan masukan bahkan mungkin menyebabkan
dia mempertanyakan apakah situs tersebut benar-benar sah, mungkin itu sebuah situs untuk nomor kartu kredit sebagai gantinya.

Jika pengunjung konsultasi dokumen sumber kertas saat mereka memasuki data, web Halaman harus menyajikan bidang dalam urutan yang sama dengan dokumen sumber. untuk Misalnya, sebuah situs yang digunakan untuk mengirimkan already-filled-out-on-paper bentuk harus mengikuti standar tata letak formulir IRS. (Salah satu pasti bisa berdebat
bahwa mengubah urutan entri pada formulir IRS mungkin apa-apa selain meningkatkan, tapi itu masalah lain.)

Chunking Kontrol input menurut Kategori

Kita dapat menjelaskan struktur form input dengan chunking kontrol berdasarkan kategori. Demikian pengelompokan adalah sangat menyambut baik dalam tata letak panel kontrol panjang. Misalnya, pada
Control panel Dell kembali pada Gambar 8.21, judul kategori ("Hard Drive ,""CD/DVD Drives,"dan seterusnya) ditampilkan dengan latar belakang abu-abu pucat, yang juga berfungsi untuk memisahkan setiap kategori dari tetangganya. Pilihan lain untuk visual chunking kategori-kategori termasuk menggunakan perbatasan, <field> tag, dan karakteristik font yang berbeda seperti ukuran dan warna.

6. Dukungan pengunjung

Secara historis (artinya, pada dasarnya, pra-web), perancang sistem komputer pergi untuk besar panjang untuk membuat instruksi yang luas tapi terpisah dan Bantuan dokumen untuk menyelamatkan pengguna yang bingung dengan atau yang mengalami kondisi kesalahan pada komputer mereka. Hari-hari ini, Anda sangat jarang melihat, apalagi berkonsultasi, halaman Bantuan terpisah di web, dan pengunjung yang kehilangan kesabaran hanya meninggalkan situs tersebut dan pindah ke yang lebih mudah satu. Akibatnya, sering bijaksana untuk menghabiskan usaha Anda untuk menciptakan intuitif dan mudah digunakan situs daripada petunjuk, bantuan, dan penanganan kesalahan yang luas.

Prinsip Dukungan pengunjung

Mari kita mengingatkan diri sendiri tentang prinsip-prinsip dasar dukungan pengunjung sebelum kita melanjutkan untuk spesifik.

a.       Praktik defensif desain. desain yang baik biasanya menghasilkan masukan yang baik. membaca bahwa kalimat lagi, perlahan-lahan, dan internalisasi artinya : Bentuk intuitif struktur dan instruksi membantu dapat pergi jauh ke arah membimbing pengunjung untuk menggunakan formulir dengan benar, sehingga meminimalkan kebingungan pengunjung dan penggantinya logis, kesalahan pengunjung (atau sedih dan hanya sebagai hasil logis - situs ditinggalkan).

b.      Cope anggun. Jangan membiarkan masalah dan kesalahan membawa Anda dengan kejutan atau entah bagaimana menyinggung perasaan Anda dengan keberadaan mereka. Kita harus menghadapi kenyataan bahwa isu-isu, meskipun upaya terbaik kami, pasti muncul. Kita akan berbicara lebih banyak tentang itu dalam bagian Penanganan Kesalahan mendatang.

c.       Kurang lebih. Terlalu banyak informasi hanya melayani untuk membingungkan pengunjung. Jika Anda telah satu potong informasi penting dimakamkan di sebuah paragraf panjang yang tidak perlu bulu, kemungkinan sebagian besar pengunjung tidak akan membaca semua itu, dan informasi penting akan tetap diperhatikan. Oleh karena itu, mencoba untuk menjadi singkat dan menonjol, mengatakan pengunjung hanya
apa yang mereka benar-benar perlu tahu untuk menyelesaikan tugas mereka.

d.      Menyediakan dokumentasi yang jelas untuk probabilitas, bukan kemungkinan. Ketika membangun kedua instruksi dan dokumen Bantuan, kita perlu untuk membedakan antara probabilitas dan kemungkinan. Sebuah probabilityis sesuatu yang sering terjadi. Memberikan bantuan yang jelas dan instruksi untuk setiap kemungkinan, mereka hal yang terjadi secara teratur, dapat bermanfaat.

Kemungkinan, di sisi lain, situasi yang muncul jarang, hanya karena ada kemungkinan bahwa hal itu mungkin terjadi tidak berarti ada banyak kesempatan akan. Untuk Misalnya, ada kemungkinan bahwa pengunjung mungkin sengaja masukkan hanya angka ke dalam
kolom nama pertama. Tapi apakah kita secara eksplisit perlu pesan kesalahan yang unik, hanya untuk menangani nomor di bidang nama? Mungkin tidak. Sebaliknya, pesan kesalahan umum seperti "Masukkan hanya huruf abjad di bidang nama depan" akan cukup untuk semua jenis entri yang tidak valid.

Meskipun sebagai web designer kami cukup mampu membuang-buang banyak tidur a malam memikirkan setiap kontingensi, kita harus berkonsentrasi pada pembuatan kemungkinan terlihat, bukan kemungkinan. Jika tidak, kami menjalankan risiko membingungkan
pengunjung dengan terlalu banyak informasi. Meskipun kita mungkin masih memutuskan untuk memasukkan beberapa kemungkinan tersebut, mereka harus ditempatkan keluar dari mainstream sehingga
pengunjung normal tidak dipaksa untuk tersandung atas mereka.

Kita sekarang akan melihat elemen-elemen utama dukungan pengunjung : instruksi, Bantuan halaman, penanganan umpan balik, dan kesalahan.

Instruksi

Instruksi dapat sesederhana petunjuk tentang format input field, seperti menunjukkan "MM/DD/YYYY" berdekatan dengan field tanggal, atau serumit beberapa kalimat menjelaskan field input tunggal. Di sini, kita akan berasumsi bahwa instruksi pada halaman yang sama dengan bidang yang mereka lihat.

Instruksi harus:

a.       akurat label setiap kontrol form. ( Karena kita sudah membahas seluk-beluk memilih label yang baik di bagian Arsitektur Site dari Bab 2, kita tidak akan pengulangan topik di sini.)

b.      Jadilah di dekat dan secara visual terhubung ke ladang mereka menjelaskan. untuk Misalnya, menjelaskan format kontrol tanggal beberapa baris di bawah kontrol sendiri tidak akan konstruktif.

c.       Jadilah mengganggu, tinggal keluar dari jalan pengunjung ketika tidak diperlukan. Sebagai contoh, kita tidak boleh secara otomatis pop up jendela terpisah dengan instruksi bahwa Pengunjung belum diminta. Hanya pengunjung pertama kali membaca pesan tersebut pula, dan pengunjung veteran akan terganggu oleh dipaksa untuk mengabaikan (terjemahan : Gunakan kosakata yang konsisten. Jangan menggambarkan proses tunggal dalam berbagai cara, seperti sebagai "Masukkan nomor yang diinginkan" di satu tempat, "Ketik nomor Anda" di tempat lain, dan "Tekan pilihan numerik Anda" di lain. Jika Anda tidak konsisten, pengunjung mungkin berpikir bahwa setiap frase yang berbeda mengacu pada proses yang berbeda.

d.      Jadilah ringkas dan to the point. Seperti yang kita bahas sebelumnya, TMI (terlalu banyak informasi) adalah mengabaikan atau berfungsi untuk membanjiri pengunjung. Mengedit semua instruksi turun ke inti kritis.

e.       Sertakan titleattribute pada elemen form untuk memberikan petunjuk lebih lanjut tentang rollover, jika diperlukan.

Dokumen Bantuan

Jika kita memberikan petunjuk yang memadai pada halaman, pengunjung kami harus memerlukan bantuan halaman jarang yang terpisah. Namun, beberapa halaman mungkin memiliki tugas yang rumit untuk melakukan. Ini, kemudian, adalah halaman tertentu yang berteriak untuk bantuan dokumen bermakna, terutama bagi pengunjung yang baru atau yang mampir hanya sesekali. Perlu diingat bahwa pengunjung yang berkonsultasi Bantuan sering sudah pada titik krisis. Oleh karena itu, kami
perlu sebagai "bermanfaat" dan ringkas mungkin, untuk menghindari iritasi lebih lanjut. Sistem Bantuan bisa sesederhana halaman Bantuan terintegrasi untuk hanya beberapa tugas situs, atau serumit yang ekstensif diindeks, situs yang terpisah dalam situs yang terdiri dari puluhan, bahkan ratusan, dari halaman. Bantuan dapat berbasis tindakan, seperti
tutorial yang membawa pengunjung langkah demi langkah melalui melakukan tugas-tugas tertentu, atau mungkin berbasis referensi, di mana pengunjung kasus hanya disajikan dengan penjelasannya bangsa topik yang diminta.

Dalam kasus apapun, Bantuan dapat diakses oleh link pada sistem menu utama, seperti pada Amazon menu atas horizontal (Gambar 8.24), atau dengan link kontekstual pada titik krisis itu sendiri, seperti pada "Lihat tarif pengiriman dan kebijakan" link di samping berat pengiriman pada halaman buku Amazon (Gambar 8.25). Bantuan kontekstual biasanya lebih, baik, membantu, karena pengunjung tidak perlu khawatir tentang browsing atau mencari seluruh bantuan sistem untuk menemukan apa yang mereka butuhkan, juga tidak perlu khawatir tentang apa yang
frase pencarian untuk digunakan. Bantuan kontekstual berarti Anda harus membangun halaman Anda untuk menjadi cukup pintar untuk membedakan mana dokumen Bantuan akan sesuai, tergantung
pada apa pengunjung mencoba untuk melakukan.

Jika dokumentasi Bantuan terdiri dari lebih dari hanya beberapa halaman, memberikan meja panas - terkait isi atau peta situs dapat menjadi penyelamat. Untuk sistem Bantuan yang lebih besar, fitur pencarian hampir wajib.

Berkala meninjau log server Anda untuk melihat dokumen Bantuan mengakses paling sering, dan apa yang pengguna sedang berusaha untuk melakukan pada saat bantuan dikonsultasikan. Jika Anda melihat bahwa beberapa tugas menghasilkan banyak permintaan Bantuan, Anda harus Redesign halaman tersebut untuk membuat mereka lebih mudah digunakan.

Tanggapan (Umpan Balik)

Pengunjung menghargai umpan balik yang memberitahu mereka bahwa mereka berada di jalur yang benar atau bahwa mereka sudah
mengalami kesalahan (meskipun tentu saja mereka menghargai kedua kurang!). Sebagai contoh, jika pengunjung memasukkan informasi pengiriman pada satu halaman dan informasi kartu kredit pada
selanjutnya, situs harus menampilkan kembali semua informasi ini pada halaman konfirmasi sebelum mengirimkan pesanan. Akibatnya, pengunjung diyakinkan bahwa sistem menerima Data karena mereka dimaksudkan untuk memasukinya. Selain itu, jika kesalahan muncul, umpan balik kesalahan dapat memberitahukan pengunjung sesegera mungkin, sementara kesalahan masih mudah diperbaiki.

Apakah pesan itu positif atau negatif, ada dua jenis umum dari umpan balik : modal dan modeless. Umpan balik modal membutuhkan respon dari pengunjung sebelum aliran kegiatan dapat dilanjutkan, seperti kotak dialog yang mengharuskan pengunjung klik "OK" untuk mengabaikan kotak sebelum bergerak maju ( seperti pada gambar 8.26 ) .

Sebaliknya, modeless umpan balik membutuhkan apa-apa dari pengunjung. Contohnya termasuk menggunakan CSS adalah : link untuk menunjukkan bahwa klik telah diakui, atau menyediakan animasi kecil yang menunjukkan kemajuan sebagai sebuah file download. Pengunjung tidak perlu memberhentikan window ketika aktivitas selesai, aliran transaksi bergerak ke halaman berikutnya secara otomatis. Terutama ketika aktivitas memerlukan menunggu lama, umpan balik seperti ini meyakinkan pengunjung bahwa ada sesuatu yang memang terjadi. Jenis serupa umpan balik, tetapi tidak memerlukan animasi, mungkin untuk menunjukkan seberapa jauh proses langkah demi langkah telah berkembang, seperti "Anda sekarang telah selesai Page Three dari lima halaman.

Karena umpan balik modal mengganggu aliran kegiatan dan membutuhkan ekstra upaya respon dari pengunjung, menghindarinya bila memungkinkan. Misalnya, Anda harus biasanya menghindari muncul kotak dialog untuk melaporkan kondisi normal, seperti pengakuan dari password yang valid. Sebaliknya, hanya melanjutkan tugas. Gunakan umpan balik modal ketika Anda perlu mengganggu aliran dari suatu kegiatan, baik untuk periksa tindakan ("Apakah Anda yakin ingin menghapus file ini?") Atau untuk memberitahukan kondisi kesalahan kritis
("Kartu kredit Anda telah kedaluwarsa. Silahkan hubungi perusahaan kartu kredit Anda.").

Penanganan Kesalahan

Kita harus merancang situs kami untuk mengatasi kesalahan anggun ketika mereka lakukan terjadi, process disebut desain kontingensi, atau "ketika hal-hal buruk terjadi pada orang baik ."

Pesan kesalahan harus:

a.       Jadilah membantu. Negara dengan apa kesalahannya, apa implikasinya, dan tepat apa pengunjung harus Anda lakukan untuk memperbaiki masalah.

b.      Jadilah yang jelas dan bernada dalam bahasa non-teknis yang diakui oleh para pengunjung. Kesalahan Kode sendiri yang kurang bermanfaat bagi pengunjung, meskipun mereka mungkin berguna untuk staf pendukung Anda. Bahkan jika kita menampilkan kode kesalahan untuk penggunaan internal, kita harus menjelaskan kesalahan dengan cara yang dapat dipahami oleh masyarakat umum. "kami UNIX server tidak mengenali URL dengan spasi tertanam" tidak hanya mengacaukan, tapi sama sekali tidak membantu. "Silakan gunakan hanya huruf abjad, angka, dan garis bawah" frame kesalahan yang sama dalam terminologi bahwa siapa pun dapat memahami
dan memanfaatkan. (Lebih baik lagi, memberitahu mereka sebelum mereka memasukan data.)

c.       Menjadi ringkas. Seperti yang telah kita bahas, informasi asing hanya mengaburkan informasi penting.

d.      Bersikaplah sopan, bijaksana, tidak menuduh, dan minta maaf. Pesan kesalahan harus tidak pernah, menyalahkan pengguna untuk masalah ini, bahkan halus. Sebaliknya, situs harus
memikul kesalahan. Setelah semua, itu arah kami sudah cukup jelas, kesalahan mungkin tidak akan terjadi sama sekali.

e.       Hindari menjadi lucu, imut, atau menjengkelkan. Seorang pengunjung pada titik krisis jarang menghargai humor.

f.       Menonjol pada halaman, dengan bidang atau item dalam kesalahan disorot entah bagaimana. Metode Khas menyoroti termasuk kode warna, tanda bintang berwarna, tebal muka, atau ikon error, seperti tanda seru di segitiga kuning yang digunakan oleh banyak aplikasi Windows. GAMBAR 8.27shows formulir dengan kesalahan yang ditunjukkan dengan tanda bintang merah.

Jika, setelah penyerahan ke server, aplikasi server-side menemukan bahwa data entah bagaimana dalam kesalahan, ada dua cara untuk mengatasi situasi tersebut :

a.       Hadir seluruh formulir kepada pengunjung lagi, mempertahankan dan redisplaying yang valid
bidang sementara menyoroti bidang yang tidak valid. Pengunjung masuk  kembali hanya sah yang data dan menyampaikan kembali formulir.

b.      Hadir, bentuk baru disingkat kepada pengunjung, hanya berisi bidang-bidang yang berada dalam kesesatan. Bentuk seperti disingkat sangat bermanfaat untuk pengunjung ketika
bentuk aslinya panjang atau rumit. Dengan demikian, pengunjung berurusan dengan hanya lapangan atau dua, bukan seluruh bentuk.

Apapun metode yang Anda pilih, yang penting adalah untuk tidak mengharuskan pengunjung untuk memasukkan kembali setiap bidang pada formulir hanya karena satu bidang adalah kesalahan. Kecuali mereka
sangat termotivasi ("mobil gratis jika Anda mengisi formulir ini!"), sebagian besar pengunjung akan menolak, terutama pada bentuk-bentuk yang lebih panjang.

Hindari menampilkan pesan error pada halaman yang berbeda dari bidang yang perlu dikoreksi, memaksa pengunjung untuk pergi bolak-balik antara halaman kesalahan dan halaman masukan karena ia memilah apa sebenarnya yang salah. Pesan kesalahan dan bidang yang membutuhkan koreksi harus pada halaman yang sama.

Terlepas dari jenis masalah pengunjung bertemu di situs, berita mengejutkan adalah bahwa resolusi sukses dari masalah membangun loyalitas pelanggan lebih cepat daripada memberikan produk yang melakukan sempurna. Tampaknya sulit untuk percaya, tetapi strategi penyelesaian masalah ceria dan anggun dapat membangun loyalitas kepada organisasi lebih cepat daripada tidak ada masalah sama sekali. Katakanlah ada masalah dengan mobil Anda setelah garansi berakhir.

Jika perusahaan riang menawarkan untuk kesulitan mobil Anda, gratis, Anda baru saja memiliki pengalaman positif yang membangun loyalitas pelanggan. Memecahkan masalah secepatnya dan sopan dapat semen pengunjung akan baik .

7. Desain Visual Controls Form

Suatu bentuk yang dirancang tidak hanya sangat bermanfaat, itu juga menarik secara visual dan cohesive dengan desain situs secara keseluruhan. Semua pedoman desain kita telah melihat di dalam bab sebelumnya-layout, warna, grafis, dan tipografi-berlaku untuk bentuk seperti yang mereka lakukan kepada elemen lain di situs. Tapi bagaimana kita benar-benar menerapkan mereka panduan untuk bentuk dan bentuk kontrol?

Ada banyak properti CSS yang dapat dimanipulasi untuk mengkoordinasikan formulir dengan sisa situs. Gambar 8.28 menunjukkan bentuk yang menampilkan baik unstyled dan gaya contoh bentuk kontrol. HTML untuk formulir ini ditampilkan di sidebar; memeriksa
hati-hati sehingga Anda memahami bagaimana format diterapkan

Perhatikan bahwa bentuk khusus ini tidak dimaksudkan untuk menjadi cantik, melainkan untuk menunjukkan kemungkinan luas untuk styling elemen form. Bahkan, ia berfungsi sebagai pengingat grafis
bahwa hanya karena kita mengubah setiap kemungkinan karakteristik elemen form tidak berarti bahwa kita harus. Selain itu, kita tidak harus mengubah default styling dari kontrol bentuk begitu banyak sehingga tidak lagi menyerupai kontrol sama sekali. Sebagai contoh, input teks yang ditata pada Gambar 8.28 sekarang mulai menyerupai tombol, dan gaya tombol radio tidak lagi terlihat seperti tombol radio sama sekali.

Dalam kasus apapun, itu harus jelas dari bab-bab sebelumnya bahwa perubahan apapun yang kita buat warna atau perbatasan atau atribut lain harus berkoordinasi dengan keseluruhan tampilan, merasa,
dan suasana hati dari situs secara keseluruhan.

Karakteristik visual elemen bentuk dan deskripsi teks yang terkait dapat membantu untuk memandu pengunjung melalui formulir. Sebagai contoh, kita mungkin menggunakan kontras yang warna untuk deskripsi berikutnya untuk semua bidang yang diperlukan dalam formulir. Warna, bagaimanapun, adalah tidak cukup arah saja, karena warnanya yang mungkin tidak terlihat oleh pengunjung yang buta warna. Oleh karena itu, beberapa isyarat tambahan harus digunakan, seperti - familiar pernah tanda bintang di sebelah deskripsi lapangan.

Contoh lain tentang bagaimana styling dapat membantu mengumpulkan data yang akurat ditunjukkan pada Gambar 8.29. Di sini, warna latar belakang yang berbeda adalah petunjuk visual yang meningkatkan nilai asosiasi deskripsi teks.

8. Bentuk masukan dan Aksesibilitas

Ini diluar cakupan buku ini untuk menggali ke dalam politik, kebijakan, dan gila - dan - baut membuat bentuk sepenuhnya dapat diakses di situs Anda, tetapi bab tentang bentuk tidak akan lengkap tanpa termasuk informasi tentang aksesibilitas.

Disini, kemudian, adalah pedoman untuk membuat bentuk masukan diakses :

a.       Bila mungkin, tempat label di sebelah kiri elemen input sehingga layar yang pembaca membaca label pertama, dan kemudian lapangan memerlukan masukan.

b.      Jika label harus ditempatkan di tempat lain selain di sebelah kiri elemen bentuk, atau ketika unsur-unsur lain datang antara label dan elemen bentuk, menghubungkan label
dan elemen bentuk seperti ini :

<input type="text" name="firstName" id="firstName" />
Nama <label for="firstName"> Pertama < / label >
Layar pembaca untuk tunanetra kemudian akan membaca label bersama dengan membentuk elemen.

c.       Untuk membuat kategori visual yang chunking eksplisit untuk pembaca layar, mengelilingi terkait bentuk elemen dengan tag <fi eldset>, dan menyertakan tag <LEGEND> untuk pelabelan.

d.       Jangan mengisi kontrol dengan teks instruksional sebagai nilai default, karena teks yang membuatnya bahkan lebih sulit untuk akses-gangguan pengunjung untuk menghapus petunjuk sebelum melanjutkan. Gunakan label yang tepat dan instruksi pada membentuk gantinya.

e.       Hindari menggunakan daftar kotak yang menggunakan multiple attribute tersebut; kotak centang yang lebih
option diakses.

f.       Jangan mengatur nilai default untuk satu ya/tidak kotak centang untuk "ya".

g.      Gunakan titleattribute untuk memberikan tooltips pada rollover.

9.      Ringkasan

Formulir dapat menyakitkan atau menyakitkan bagi pengunjung. Perlu diingat bahwa pengunjung ingin mendapatkan tugas mereka dilakukan secepat mungkin, dan dengan sedikit usaha.
Perencanaan dan desain yang tepat dapat memaksimalkan efisiensi tugas.
Daftar periksa berikut memiliki dua fungsi : untuk meringkas poin utama dan "Aturan" yang disajikan dalam bab ini, dan sebagai checklist sebelum menyelesaikan situs web Anda ciptakan.

Usability - Tahukah Anda :

a.       Lakukan segala yang mungkin untuk mengurangi pengunjung upaya-visual, kognitif, dan fisik ?

b.      Minimalkan klik pengunjung, penekanan tombol, gerakan mouse, dan bergulir?

c.       Hindari meminta data sampai setelah pengunjung menyadari manfaat?

d.      Hindari meminta data yang tidak perlu atau berlebihan?

e.       Menunjukkan elemen yang diperlukan dan yang opsional?

f.       kontrol input Hadir dalam urutan yang diharapkan?

g.      Gunakan penyihir dan panel kontrol yang tepat?

h.      Jika menggunakan panel kontrol, potongan elemen input dengan kategori?

i.        Tentukan urutan tab yang sesuai dan fokus awal, jika diperlukan?

Seleksi Controls - Tahukah Anda :

a.       Gunakan <input type="radio" /> , <input type="checkbox" /> , atau <select> untuk sejumlah pilihan?

b.      Menyaring orang-orang pilihan yang menjadi tidak relevan karena pilihan sebelumnya?

c.       Gunakan <input type="radio" /> untuk daftar pendek pilihan yang saling eksklusif?

d.      Gunakan <input type="checkbox" /> untuk daftar pendek yang memungkinkan beberapa pilihan?

e.       Sejajarkan kotak centang dan tombol radio vertikal?

f.       potongan visual terkait radio button dan checkbox?

g.      Gunakan <select> untuk daftar panjang yang akan menutupi terlalu banyak layar real estat jika semua pilihan yang ditampilkan sekaligus?

h.      Putuskan apakah atau tidak untuk menempatkan pilihan yang paling umum di bagian atas daftar?

i.        Gunakan size = "1" untuk daftar drop-down, dan size with nilai yang lebih besar dari 1 untuk daftar digulir?

j.        Gunakan <optgroup> ke pilihan potongan terkait dalam kotak pilih?

Text Input Controls - Tahukah Anda :

a.       Gunakan <input type="text" /> untuk input teks satu baris, atau < input type = "password"/ > Untuk input teks satu baris dengan karakter yang dimasukkan disembunyikan oleh tanda bintang?

b.      Tentukan sizeand maxlengththat kira-kira sesuai?

c.       Tampilan format bidang yang relevan dan tanda baca, seperti tanda hubung dalam tanggal?

d.      Gunakan valueattribute untuk menentukan nilai default jika 80 % atau lebih dari audi - ence dapat menggunakan default?

e.       Hindari menggunakan valueattribute untuk menampilkan instruksi untuk lapangan?

f.       Gunakan tag <textarea> untuk input teks multi -line?

g.      Gunakan wrap = "lunak", "keras", atau "off" untuk menentukan apakah tombol kembali adalah digunakan dan apakah mereka diselamatkan dengan bidang <textarea>?

h.      Gunakan <textarea> untuk menampilkan teks informasi yang perlu gulir?

Form Submission - Tahukah Anda :

a.       Gunakan kontrol yang tepat untuk mengirimkan formulir?

b.      Hindari memberitahu pengunjung tidak mengklik sebuah tombol Submit dua kali?

c.       Hindari penggunaan ulang tombol?

d.      Jika Anda menggunakan tombol Reset, memverifikasi bahwa pengguna dimaksudkan untuk klik?

e.       Posisi tombol di dekat dan secara visual terhubung dengan unsur-unsur bentuk mereka?

f.       Posisi tombol tindakan yang lebih aman atau lebih positif di sebelah kiri, dan berisiko atau Tombol tindakan yang lebih negatif di sebelah kanan , memastikan bahwa tanah fokus standar pada lebih aman dari dua tindakan?

g.      Setelah penyerahan, meyakinkan pengunjung dengan halaman respon yang Menampilkan kembali yang memasukkan informasi?

h.      Verifikasi kelengkapan dan format semua entri sebanyak mungkin sebelum sub - mitting bentuk ke server?

Dukungan Pengunjung - Apakah Anda :

a.       Praktek desain defensif, sehingga bentuk yang sangat intuitif dan mudah digunakan yang dukungan tambahan sedikit diperlukan?

b.      Cobalah untuk menjadi singkat dan menonjol, mengatakan pengunjung hanya apa yang mereka benar-benar perlu
tahu untuk menyelesaikan tugas-tugas mereka?

c.       Menyediakan dokumentasi yang jelas untuk probabilitas, bukan kemungkinan?

Instruksi - Tahukah Anda :

a.       Memberikan petunjuk yang memadai sehingga bantuan yang terpisah jarang diperlukan?

b.      akurat label setiap kontrol bentuk, dan tempat masing-masing di dekat dan visual yang koneksi ke bidang itu menjelaskan?

c.       Membuat dokumentasi jelas tetapi tidak mengganggu?

d.      Gunakan kosakata yang konsisten?

e.       Sertakan titleattribute pada elemen form untuk memberikan petunjuk singkat pada rollover?

Bantuan - Tahukah Anda :

a.       Gunakan bantuan kontekstual bila memungkinkan?

b.      Menyediakan meja panas - terkait isi atau peta situs, dan fungsi pencarian untuk Bantuan sistem yang lebih besar?

Feedback - Tahukah Anda :

a.       Memberikan umpan balik, terutama untuk menunggu lama dan kesalahan?

b.      Gunakan modeless, bukan modal, umpan balik bila memungkinkan?

Penanganan Kesalahan - Tahukah Anda :

a.       Memberikan pesan kesalahan yang membantu, jelas, non-teknis, singkat, sopan, bijaksana, non - menuduh, minta maaf, dan terlihat?

b.      Ketika kesalahan server-side ditemui, baik menampilkan kembali seluruh formulir atau hanya subset dari kontrol yang berada dalam kesalahan?

c.       Tampilan pesan kesalahan pada halaman yang sama sebagai bidang yang perlu diperbaiki?

d.      Ingatlah bahwa resolusi sukses dari masalah membangun pelanggan yang kuat loyalitas dari memberikan produk yang melakukan dengan sempurna?

Aksesibilitas - Tahukah Anda :

a.       Bila mungkin, tempat label di sebelah kiri kontrol, atau mengasosiasikan label dan kontrol dengan tag <label>?

b.      Surround terkait bentuk elemen dengan <fi tag eldset> dan termasuk <LEGEND> yang tag untuk label?

c.       Hindari mengisi kontrol dengan teks instruksional sebagai nilai default?

d.      Hindari menggunakan kotak daftar ketika beberapa pilihan yang mungkin (yaitu, menggunakan multiple attribute)?

e.       Hindari pengaturan nilai default untuk satu ya/tidak kotak centang untuk "ya"?

f.       Gunakan title attribute untuk memberikan tooltips pada rollover?