เริ่มจากแบบฟอร์มลงทะเบียนกันก่อน บริษัทส่วนใหญ่ต้องการความสัมพันธ์ระยะยาวกับผู้ใช้ของตน ในการทำเช่นนั้น ผู้ใช้ต้องลงชื่อสมัครใช้ และในการทำเช่น นั้น พวกเขาต้องให้คุณค่าแก่ผู้ใช้เป็นการตอบแทน ไม่มีใครอยากสมัครใช้บริการของคุณ พวกเขาแค่ต้องการเข้าถึงสิ่งที่คุณเสนอ หรือคำมั่นสัญญาว่าจะได้รับประสบการณ์ที่รวดเร็วยิ่งขึ้นในครั้งต่อไปที่พวกเขาไปใช้บริการ

แม้จะมีรูปลักษณ์พื้นฐานของแบบฟอร์มการลงทะเบียน แต่ก็มีหลายสิ่งที่ต้องพิจารณา: องค์ประกอบดั้งเดิมที่ประกอบเป็นแบบฟอร์ม (ป้ายกำกับ ปุ่ม และอินพุต) วิธีลดความพยายาม (แม้ในรูปแบบขนาดเล็กเช่นนี้) ไปจนถึงแบบฟอร์ม การตรวจสอบ

ในการเลือกรูปแบบง่ายๆ ดังกล่าว เราสามารถขยายคุณสมบัติพื้นฐานที่พบในรูปแบบที่ออกแบบมาอย่างดี

## มันจะดูเป็นอย่างไร

แบบฟอร์มประกอบด้วยสี่ช่องและปุ่มส่ง แต่ละฟิลด์ประกอบด้วยตัวควบคุม (อินพุต) และป้ายกำกับที่เกี่ยวข้อง

นี่คือ HTML:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

ป้ายกำกับคือจุดเริ่มต้นของการสนทนา

## ป้าย

ในการช่วย การเข้าถึงสำหรับทุกคน Laura Kalbag ได้กำหนดพารามิเตอร์กว้างๆ สี่ประการที่ช่วยปรับปรุงประสบการณ์ผู้ใช้สำหรับทุกคน:

• Visual : ทำให้มองเห็นได้ง่าย
• การได้ยิน : ทำให้ง่ายต่อการได้ยิน
• มอเตอร์ : ทำให้ง่ายต่อการโต้ตอบด้วย
• Cognitive : ทำให้เข้าใจง่าย

เมื่อดูป้ายกำกับจากจุดยืนแต่ละด้าน เราจะเห็นได้ว่าป้ายกำกับมีความสำคัญเพียงใด ผู้ใช้ที่มองเห็นสามารถอ่านได้ ผู้ใช้ที่มีความบกพร่องทางสายตาสามารถได้ยินได้โดยใช้โปรแกรมอ่านหน้าจอ และผู้ใช้ที่มีความบกพร่องทางการเคลื่อนไหวสามารถตั้งโฟกัสไปที่สนามได้ง่ายขึ้นด้วยพื้นที่การชนที่ใหญ่ขึ้น นั่นเป็นเพราะการคลิกป้ายกำกับจะกำหนดโฟกัสไปที่องค์ประกอบแบบฟอร์มที่เกี่ยวข้อง

ด้วยเหตุผลเหล่านี้ ทุกการควบคุมที่รับอินพุตควรมี <label> เสริม ปุ่มส่งไม่รับอินพุต ดังนั้นจึงไม่จำเป็นต้องมีป้ายกำกับเสริม เนื่องจากแอตทริบิวต์ value ซึ่งแสดงข้อความภายในปุ่ม จะทำหน้าที่เป็นป้ายกำกับที่เข้าถึงได้

ในการเชื่อมต่ออินพุตกับป้ายกำกับ id ของอินพุตและป้ายกำกับ for แอตทริบิวต์ควรตรงกันและไม่ซ้ำกันในเพจ ในกรณีของฟิลด์อีเมล ค่าคือ “อีเมล”:

 html < label for = "email" > Email address </ label > < input id = "email" >

การไม่ใส่ป้ายกำกับหมายถึงการเพิกเฉยต่อความต้องการของผู้ใช้จำนวนมาก รวมถึงผู้ที่มีความบกพร่องทางร่างกายและสติปัญญา ด้วยการมุ่งเน้นไปที่อุปสรรคที่เป็นที่ยอมรับสำหรับคนพิการ เราสามารถทำให้แบบฟอร์มของเราง่ายขึ้นและแข็งแกร่งขึ้นสำหรับทุกคน

ตัวอย่างเช่น พื้นที่การตีที่ใหญ่ขึ้นเป็นสิ่งสำคัญสำหรับผู้ใช้ที่มีความบกพร่องทางการเคลื่อนไหว แต่จะง่ายกว่าสำหรับผู้ที่ไม่มีความบกพร่องเช่นกัน

## ตัวยึด

แอตทริบิวต์ placeholder มีไว้เพื่อเก็บคำใบ้ ซึ่งจะให้คำแนะนำเพิ่มเติมแก่ผู้ใช้เมื่อกรอกฟิลด์ — มีประโยชน์อย่างยิ่งสำหรับฟิลด์ที่มีกฎที่ซับซ้อน เช่น ฟิลด์รหัสผ่าน

เนื่องจากข้อความตัวแทนไม่ใช่ค่าจริง ข้อความดังกล่าวจึงเป็นสีเทา เพื่อให้สามารถแยกความแตกต่างจากค่าที่ผู้ใช้ป้อนได้

ต่างจากป้ายกำกับ คำใบ้เป็นทางเลือกที่ไม่บังคับและไม่ควรใช้เป็นหลัก เพียงเพราะแอตทริบิวต์ placeholder มีอยู่ไม่ได้หมายความว่าเราต้องใช้งาน คุณไม่จำเป็นต้องมีตัวยึดตำแหน่ง "ป้อนชื่อของคุณ" เมื่อป้ายกำกับเป็น "ชื่อจริง" ซึ่งไม่จำเป็นต้องทำซ้ำ

ตัวยึดตำแหน่งมีความน่าสนใจเนื่องจากมีความสวยงามน้อยที่สุดและประหยัดพื้นที่ เนื่องจากข้อความตัวยึดตำแหน่งจะอยู่ ภายใน ฟิลด์ แต่นี่เป็นวิธีที่มีปัญหาในการให้คำแนะนำแก่ผู้ใช้

อันดับแรก จะหายไปเมื่อผู้ใช้พิมพ์ ข้อความที่หายไปนั้นจำยาก ซึ่งอาจทำให้เกิดข้อผิดพลาดได้ ตัวอย่างเช่น หากผู้ใช้ลืมปฏิบัติตามกฎของรหัสผ่านข้อใดข้อหนึ่ง ผู้ใช้มักเข้าใจผิดว่าเป็นข้อความตัวแทนสำหรับค่า ซึ่งทำให้ฟิลด์ถูกข้าม ซึ่งอาจทำให้เกิดข้อผิดพลาดอีกครั้งในภายหลัง ข้อความสีเทาบนพื้นขาวไม่มีคอนทราสต์เพียงพอ ทำให้อ่านยากโดยทั่วไป และเหนือสิ่งอื่นใด เบราว์เซอร์บางตัวไม่รองรับตัวยึดตำแหน่ง โปรแกรมอ่านหน้าจอบางตัวไม่ประกาศ และข้อความคำใบ้แบบยาวอาจถูกตัดออก

นั่นเป็นปัญหามากมายสำหรับสิ่งที่เป็นเพียงแค่ข้อความเท่านั้น เนื้อหาทั้งหมด โดยเฉพาะอย่างยิ่งคำใบ้แบบฟอร์ม ไม่ควรถือว่าดีที่จะมี ดังนั้น แทนที่จะใช้ตัวยึดตำแหน่ง ควรวางข้อความคำใบ้ไว้เหนือตัวควบคุมดังนี้:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

คำใบ้ถูกวางไว้ภายในฉลากและภายใน <span> เพื่อให้สามารถจัดรูปแบบให้แตกต่างออกไปได้ โดยวางไว้ในป้ายกำกับ โปรแกรมอ่านหน้าจอจะอ่านออก และขยายพื้นที่ Hit ให้ใหญ่ขึ้น

เช่นเดียวกับการออกแบบส่วนใหญ่ นี่ไม่ใช่วิธีเดียวที่จะบรรลุฟังก์ชันนี้ เราสามารถใช้แอตทริบิวต์ ARIA เพื่อเชื่อมโยงคำใบ้กับอินพุต:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

แอตทริบิวต์ aria-describedby ใช้เพื่อเชื่อมต่อคำใบ้ด้วย id — เช่นเดียวกับแอตทริบิวต์ for สำหรับป้ายกำกับ แต่ในทางกลับกัน โดยจะต่อท้ายป้ายกำกับของตัวควบคุมและอ่านข้อมูลหลังจากหยุดชั่วขณะสั้นๆ ในตัวอย่างนี้ “รหัสผ่าน [หยุดชั่วคราว] ต้องมีอักขระบวกแปดตัวพร้อมตัวเลขอย่างน้อยหนึ่งตัวและตัวพิมพ์ใหญ่หนึ่งตัว”

มีความแตกต่างอื่น ๆ ด้วย ขั้นแรก การคลิกคำใบ้ (a <p> ในกรณีนี้) จะไม่เน้นการควบคุม ซึ่งจะลดพื้นที่ที่โจมตี ประการที่สอง แม้ว่า ARIA จะได้รับการสนับสนุนเพิ่มขึ้น แต่ก็ไม่เคยได้รับการสนับสนุนเป็นอย่างดีเท่าองค์ประกอบดั้งเดิม ในกรณีนี้ Internet Explorer 11 ไม่สนับสนุน aria-describedby นี่คือเหตุผลที่กฎข้อแรกของ ARIA คือไม่ใช้ ARIA:

“หากคุณสามารถใช้องค์ประกอบหรือแอตทริบิวต์ HTML ดั้งเดิมที่มีความหมายและพฤติกรรมที่คุณต้องการ อยู่แล้วใน แทนที่จะกำหนดองค์ประกอบใหม่และเพิ่มบทบาท สถานะ หรือคุณสมบัติ ARIA เพื่อให้สามารถเข้าถึงได้ ให้ ทำอย่าง นั้น”

ป้ายลอย

รูปแบบฉลากลอยโดย Matt Smith เป็นเทคนิคที่ใช้ฉลากเป็นตัวยึดตำแหน่ง เลเบลเริ่มต้น ภายใน คอนโทรล แต่ลอยอยู่เหนือคอนโทรลเมื่อผู้ใช้พิมพ์ ดังนั้นชื่อ เทคนิคนี้มักเป็นที่ยกย่องสำหรับคุณสมบัติที่แปลกตา เรียบง่าย และประหยัดพื้นที่

ขออภัย วิธีนี้มีปัญหาหลายประการ ประการแรก ไม่มีที่ว่างสำหรับคำใบ้เนื่องจากป้ายกำกับและคำใบ้เป็นหนึ่งเดียวกัน ประการที่สอง พวกเขาอ่านยาก เนื่องจากคอนทราสต์และข้อความขนาดเล็กที่ไม่ค่อยดี เนื่องจากโดยทั่วไปแล้วจะได้รับการออกแบบ (คอนทราสต์ที่ต่ำกว่าเป็นสิ่งจำเป็นเพื่อให้ผู้ใช้มีโอกาสแยกความแตกต่างระหว่างค่าจริงและตัวยึดตำแหน่ง) ประการที่สาม เช่นเดียวกับตัวยึดตำแหน่ง ค่าเหล่านี้อาจถูกเข้าใจผิดว่าเป็นค่าหนึ่งและอาจถูกตัดออก

และโฟลตเลเบลไม่ได้ช่วยประหยัดพื้นที่จริงๆ ป้ายกำกับต้องการพื้นที่เพื่อย้ายเข้าในตอนแรก แม้ว่าพวกเขาจะประหยัดพื้นที่ แต่ก็ไม่ใช่เหตุผลที่ดีที่จะลดความสามารถในการใช้งานแบบฟอร์ม

“ดูเหมือนว่าจะใช้ความพยายามอย่างมากเมื่อคุณสามารถใส่ป้ายกำกับไว้เหนืออินพุตและรับประโยชน์ทั้งหมด/ไม่มีปัญหาใดๆ เลย”
— Luke Wroblewski บนฉลากลอย

อินเทอร์เฟซที่เล่นโวหารและเรียบง่ายไม่ได้ทำให้ผู้ใช้รู้สึกยอดเยี่ยม — อินเทอร์เฟซที่ชัดเจน ครอบคลุม และมีประสิทธิภาพทำให้ การลดความสูงของแบบฟอร์มในลักษณะนี้ทำให้ดูไม่น่าสนใจและเป็นปัญหา

คุณควรจัดลำดับความสำคัญของการจัดพื้นที่สำหรับป้ายกำกับที่พร้อมใช้งานตลอดเวลา (และบอกใบ้หากจำเป็น) ก่อนเริ่มกระบวนการออกแบบ ด้วยวิธีนี้ คุณจะไม่ต้องบีบเนื้อหาลงในพื้นที่ขนาดเล็ก

เราจะหารือเกี่ยวกับเทคนิคต่างๆ ที่ประดิษฐ์น้อยลงเพื่อลดขนาดของแบบฟอร์มในไม่ช้า

## โปรโตคอลคำถาม

วิธีหนึ่งที่มีประสิทธิภาพและ เป็นธรรมชาติ ในการลดขนาดของแบบฟอร์มคือการใช้โปรโตคอลคำถาม ช่วยให้แน่ใจว่าคุณรู้ว่าทำไมคุณถึงถามคำถามทุกข้อหรือรวมฟิลด์แบบฟอร์ม

แบบฟอร์มลงทะเบียนต้องรวบรวมชื่อ นามสกุล อีเมล และรหัสผ่านหรือไม่? มีวิธีที่ดีกว่าหรือทางเลือกอื่นในการขอข้อมูลนี้ที่ทำให้ประสบการณ์ง่ายขึ้นหรือไม่

คุณไม่จำเป็นต้องขอชื่อและนามสกุลของผู้ใช้เพื่อลงทะเบียนในทุกกรณี หากคุณต้องการข้อมูลนั้นในภายหลัง ไม่ว่าจะด้วยเหตุผลใดก็ตาม ให้ถามมันในตอนนั้น การลบฟิลด์เหล่านี้จะทำให้ขนาดของแบบฟอร์มลดลงครึ่งหนึ่ง ทั้งหมดโดยไม่ต้องใช้รูปแบบที่แปลกใหม่และมีปัญหา

### ไม่มีรหัสผ่านลงชื่อเข้าใช้

วิธีหนึ่งในการหลีกเลี่ยงการขอรหัสผ่านจากผู้ใช้คือการใช้รูปแบบ การลงชื่อเข้าใช้แบบไม่มีรหัสผ่าน ทำงานโดยใช้ความปลอดภัยของอีเมล (ซึ่งต้องใช้รหัสผ่านอยู่แล้ว) ผู้ใช้ป้อนเฉพาะที่อยู่อีเมล และบริการจะส่งลิงก์พิเศษไปยังกล่องจดหมายของตน การติดตามผู้ใช้เข้าสู่บริการทันที

สิ่งนี้ไม่เพียงลดขนาดของแบบฟอร์มให้เหลือเพียงฟิลด์เดียว แต่ยังช่วยให้ผู้ใช้ไม่ต้องจำรหัสผ่านอื่นอีกด้วย แม้ว่าวิธีนี้จะทำให้แบบฟอร์มแยกจากกันได้ง่ายขึ้น แต่ในอีกทางหนึ่งก็เพิ่มความซับซ้อนเป็นพิเศษให้กับผู้ใช้

ประการแรก ผู้ใช้อาจไม่ค่อยคุ้นเคยกับแนวทางนี้ และหลายคนกังวลเรื่องความปลอดภัยออนไลน์ ประการที่สอง จำเป็นต้องย้ายออกจากแอปไปยังบัญชีอีเมลของคุณเป็นเวลานาน โดยเฉพาะอย่างยิ่งสำหรับผู้ใช้ที่รู้รหัสผ่านของตนหรือใช้เครื่องมือจัดการรหัสผ่าน

ไม่ใช่ว่าเทคนิคหนึ่งดีกว่าอีกเทคนิคหนึ่งเสมอไป เป็นโปรโตคอลคำถามกระตุ้นให้เราคิดเกี่ยวกับสิ่งนี้ซึ่งเป็นส่วนหนึ่งของกระบวนการออกแบบ มิฉะนั้น คุณจะต้องเพิ่มฟิลด์รหัสผ่านลงในแบบฟอร์มและดำเนินการให้เสร็จสิ้น

### ข้อความรหัสผ่าน

รหัสผ่านโดยทั่วไปจะสั้น จดจำยาก และถอดรหัสได้ง่าย ผู้ใช้มักจะต้องสร้างรหัสผ่านที่มีอักขระมากกว่าแปดตัว ซึ่งประกอบด้วยตัวพิมพ์ใหญ่และตัวพิมพ์เล็กหนึ่งตัวและตัวเลขอย่างน้อยหนึ่งตัว การโต้ตอบแบบไมโครนี้แทบจะไม่เหมาะ

“ขออภัย แต่รหัสผ่านของคุณต้องมีตัวพิมพ์ใหญ่ ตัวเลข ไฮกุ ป้ายแก๊ง อักษรอียิปต์โบราณ และเลือดของสาวพรหมจารี”
— Meme อินเทอร์เน็ตที่ไม่ระบุชื่อ

แทนที่จะใช้รหัสผ่าน เราสามารถขอรหัสผ่านจากผู้ใช้ ข้อความรหัสผ่านคือชุดของคำต่างๆ เช่น "monkeysinmygarden" (ขออภัย นั่นเป็นสิ่งแรกที่นึกถึง) โดยทั่วไปจะจดจำได้ง่ายกว่ารหัสผ่าน และปลอดภัยกว่าเนื่องจากความยาว — วลีรหัสผ่านต้องมีความยาวอย่างน้อย 16 อักขระ

ข้อเสียคือข้อความรหัสผ่านมักไม่ค่อยใช้ ดังนั้นจึงไม่คุ้นเคย ซึ่งอาจทำให้เกิดความวิตกกังวลสำหรับผู้ใช้ที่กังวลเกี่ยวกับความปลอดภัยออนไลน์อยู่แล้ว

ไม่ว่าจะเป็นรูปแบบการลงชื่อเข้าใช้แบบไม่มีรหัสผ่านหรือข้อความรหัสผ่าน เราควรย้ายออกจากแบบแผนเมื่อเราได้ทำการวิจัยผู้ใช้อย่างละเอียดถี่ถ้วนและหลากหลายแล้ว คุณคงไม่อยากแลกเปลี่ยนปัญหาชุดหนึ่งกับอีกชุดหนึ่งโดยไม่รู้ตัว

## การออกแบบสนาม

วิธีที่คุณจัดรูปแบบส่วนประกอบแบบฟอร์มของคุณ อย่างน้อยส่วนหนึ่ง จะถูกกำหนดโดยผลิตภัณฑ์หรือแบรนด์ของบริษัทของคุณ อย่างไรก็ตาม ตำแหน่งป้ายกำกับและรูปแบบการโฟกัสยังเป็นข้อพิจารณาที่สำคัญ

### ตำแหน่งป้าย

การทดสอบการติดตามดวงตาของ Matteo Penzo แสดงให้เห็นว่าการวางตำแหน่งฉลากด้านบน (ตรงข้ามกับด้านข้าง) การควบคุมแบบฟอร์มทำงานได้ดีที่สุด

“การวางป้ายกำกับไว้เหนือช่องป้อนข้อมูลทำให้ผู้ใช้สามารถจับภาพทั้งสององค์ประกอบได้ด้วยการเคลื่อนไหวของตาข้างเดียว”

แต่มีเหตุผลอื่นที่ต้องติดฉลากไว้เหนือสนาม บนวิวพอร์ตขนาดเล็กไม่มีที่ว่างข้างตัวควบคุม และในวิวพอร์ตขนาดใหญ่ การซูมเข้าจะเพิ่มโอกาสที่ข้อความจะหายไปจากหน้าจอ

นอกจากนี้ ป้ายกำกับบางป้ายยังมีข้อความจำนวนมาก ซึ่งทำให้ต้องตัดเป็นหลายบรรทัด ซึ่งจะขัดขวางจังหวะการมองเห็นหากวางไว้ข้างตัวควบคุม

แม้ว่าคุณควรตั้งเป้าที่จะรักษาป้ายกำกับให้กระชับ แต่ก็ไม่สามารถทำได้เสมอไป การใช้รูปแบบที่รองรับเนื้อหาที่หลากหลาย — โดยการวางตำแหน่งป้ายกำกับเหนือการควบคุม — เป็นกลยุทธ์ที่ดี

### รูปลักษณ์ ขนาด และช่องว่าง

ฟิลด์ฟอร์มควรมีลักษณะเหมือนฟิลด์ฟอร์ม แต่นั่นหมายความว่าอย่างไร?

หมายความว่ากล่องข้อความควรมีลักษณะเหมือนกล่องข้อความ กล่องเปล่ามีความหมายว่า “เติมฉันเข้าไป” โดยอาศัยความว่างเปล่า เหมือนสมุดระบายสี สิ่งนี้เกิดขึ้นเพื่อเป็นส่วนหนึ่งของเหตุผลที่ตัวยึดตำแหน่งไม่มีประโยชน์ พวกเขาลบความสามารถในการรับรู้ว่ากล่องข้อความเปล่าจะมีให้

นอกจากนี้ยังหมายความว่าพื้นที่ว่างควรอยู่ในกล่อง (มีขอบ) การเอาเส้นขอบออก หรือมีเฉพาะเส้นขอบล่าง เช่น ลบค่าที่รับรู้ ในตอนแรกเส้นขอบด้านล่างอาจดูเหมือนเป็นตัวคั่น แม้ว่าคุณจะรู้ว่าคุณต้องกรอกข้อมูลบางอย่าง ค่าที่อยู่เหนือเส้นตรงหรือต่ำกว่าเส้นนั้นหรือไม่?

ในเชิงพื้นที่ ป้ายชื่อควรอยู่ใกล้กับตัวควบคุมแบบฟอร์มมากที่สุด ไม่ใช่ตัวควบคุมของเขตข้อมูลก่อนหน้า สิ่งที่ปรากฏใกล้กันแสดงว่าเป็นของคู่กัน การมีระยะห่างที่เท่ากันอาจช่วยปรับปรุงความสวยงาม แต่จะทำให้เสียความสามารถในการใช้งาน

สุดท้าย ป้ายกำกับและกล่องข้อความควรมีขนาดใหญ่พอที่จะอ่านและแตะได้ นี่อาจหมายถึงขนาดตัวอักษรอย่างน้อย 16 พิกเซล และเป้าหมายการแตะโดยรวมอย่างน้อย 44px

### โฟกัสสไตล์

รูปแบบโฟกัสเป็นโอกาสที่ง่ายกว่า ตามค่าเริ่มต้น เบราว์เซอร์จะวางโครงร่างรอบๆ องค์ประกอบเพื่อให้ผู้ใช้ โดยเฉพาะอย่างยิ่งผู้ที่ใช้แป้นพิมพ์จะรู้ว่าตนอยู่ที่ไหน ปัญหาของสไตล์เริ่มต้นคือมักจะเลือนลางและมองเห็นได้ยาก และค่อนข้างน่าเกลียด

ในกรณีนี้ อย่าพยายามลบออก เพราะการทำเช่นนี้จะลดประสบการณ์ของผู้ใช้อย่างมากสำหรับผู้ที่เลื่อนดูหน้าจอด้วยแป้นพิมพ์ เราสามารถแทนที่สไตล์เริ่มต้นเพื่อให้ชัดเจนและสวยงามยิ่งขึ้น

 input:focus { outline: 4px solid #ffbf47; }

## ฟิลด์อีเมล

แม้จะมีรูปลักษณ์ที่เรียบง่าย แต่ก็มีรายละเอียดที่สำคัญบางอย่างที่เข้าสู่การก่อสร้างสนามซึ่งส่งผลต่อประสบการณ์

ตามที่ระบุไว้ก่อนหน้านี้ บางฟิลด์มีคำใบ้เพิ่มเติมจากเลเบล ซึ่งเป็นสาเหตุที่เลเบลอยู่ภายในช่วงชายด์ คลาส field-label ช่วยให้เราจัดรูปแบบผ่าน CSS

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

ป้ายกำกับคือ "ที่อยู่อีเมล" และใช้ตัวพิมพ์ประโยค ใน “การทำตัวพิมพ์ใหญ่สำหรับตัวพิมพ์เล็ก” จอห์น ไซโตะอธิบายว่าตัวพิมพ์ประโยค (ซึ่งต่างจากตัวพิมพ์ใหญ่) โดยทั่วไปจะอ่านง่ายกว่า เป็นมิตรกว่า และทำให้มองเห็นคำนามได้ง่ายขึ้น ไม่ว่าคุณจะฟังคำแนะนำนี้หรือไม่ก็ขึ้นอยู่กับคุณ แต่สไตล์ที่คุณเลือก อย่าลืมใช้อย่างสม่ำเสมอ

แอตทริบิวต์ type ของอินพุตถูกตั้งค่าเป็น email ซึ่งจะเรียกใช้แป้นพิมพ์บนหน้าจอเฉพาะอีเมลบนอุปกรณ์เคลื่อนที่ สิ่งนี้ทำให้ผู้ใช้เข้าถึง @ และ . (จุด) สัญลักษณ์ที่ทุกที่อยู่อีเมลต้องมี

ผู้ที่ใช้เบราว์เซอร์ที่ไม่รองรับจะเห็นการป้อนข้อความมาตรฐาน ( <input type="text"> ) นี่คือรูปแบบหนึ่งของการปรับปรุงแบบก้าวหน้า ซึ่งเป็นรากฐานที่สำคัญของการออกแบบประสบการณ์ที่ครอบคลุม

### การเพิ่มประสิทธิภาพแบบก้าวหน้า

การเพิ่มประสิทธิภาพแบบก้าวหน้านั้นเกี่ยวกับผู้ใช้ มันทำให้ชีวิตของเราในฐานะนักออกแบบและนักพัฒนาง่ายขึ้นเช่นกัน แทนที่จะติดตามชุดของเบราว์เซอร์และอุปกรณ์ (ซึ่งเป็นไปไม่ได้!) เราสามารถมุ่งเน้นไปที่คุณลักษณะเท่านั้น

ประการแรกและสำคัญที่สุด การปรับปรุงแบบก้าวหน้าคือการมอบประสบการณ์ที่เหมาะสมแก่ผู้ใช้เสมอ ไม่ว่าเบราว์เซอร์ อุปกรณ์ หรือคุณภาพของการเชื่อมต่อจะเป็นอย่างไร เมื่อมีสิ่งผิดปกติเกิดขึ้น ผู้ใช้ไม่ต้องทนทุกข์เพราะยังทำสิ่งต่างๆ ให้เสร็จสิ้นได้

มีหลายวิธีที่ประสบการณ์สามารถผิดพลาดได้ อาจไม่สามารถโหลดสไตล์ชีตหรือสคริปต์ได้ อาจโหลดทุกอย่างได้ แต่เบราว์เซอร์ของผู้ใช้ไม่รู้จัก HTML, CSS หรือ JavaScript บางตัว ไม่ว่าจะเกิดอะไรขึ้น การใช้การเพิ่มประสิทธิภาพแบบก้าวหน้าเมื่อออกแบบประสบการณ์จะหยุดผู้ใช้ที่มีช่วงเวลาที่เลวร้ายเป็นพิเศษ

มันเริ่มต้นด้วย HTML สำหรับโครงสร้างและเนื้อหา ถ้า CSS หรือ JavaScript ไม่โหลด ก็ไม่เป็นไรเพราะมีเนื้อหาอยู่ที่นั่น

หากทุกอย่างโหลดได้ปกติ ระบบอาจไม่รู้จักองค์ประกอบ HTML ต่างๆ ตัวอย่างเช่น บางเบราว์เซอร์ไม่เข้าใจ <input type="email"> ไม่เป็นไรเพราะผู้ใช้จะได้รับกล่องข้อความ ( <input type="text"> ) แทน ผู้ใช้ยังสามารถป้อนที่อยู่อีเมลได้ พวกเขาไม่ได้รับคีย์บอร์ดเฉพาะอีเมลบนมือถือ

บางทีเบราว์เซอร์อาจไม่เข้าใจ CSS แฟนซีและจะไม่สนใจมัน ในกรณีส่วนใหญ่ นี่ไม่ใช่ปัญหา สมมติว่าคุณมีปุ่มที่มี border-radius: 10px เบราว์เซอร์ที่ไม่รู้จักกฎนี้จะแสดงปุ่มที่มีมุมเป็นมุม เห็นได้ชัดว่าความสามารถในการจ่ายของปุ่มลดลง แต่ผู้ใช้จะไม่ได้รับอันตราย ในกรณีอื่นๆ การใช้การสืบค้นข้อมูลคุณลักษณะอาจเป็นประโยชน์

จากนั้นก็มี JavaScript ซึ่งซับซ้อนกว่า เมื่อเบราว์เซอร์พยายามแยกวิเคราะห์เมธอดที่ไม่รู้จัก เบราว์เซอร์จะดูยุ่งเหยิง ซึ่งอาจทำให้สคริปต์อื่นๆ (ที่ถูกต้องและรองรับ) ของคุณล้มเหลว หากสคริปต์ของคุณไม่ตรวจสอบก่อนว่ามีเมธอด (การตรวจหาคุณลักษณะ) และทำงาน (การทดสอบคุณลักษณะ) ก่อนใช้งาน ผู้ใช้อาจได้รับอินเทอร์เฟซที่ใช้งานไม่ได้ ตัวอย่างเช่น หากตัวจัดการการคลิกของปุ่มเรียกใช้วิธีการที่ไม่รู้จัก ปุ่มจะไม่ทำงาน เลวร้าย.

นั่นเป็นวิธีที่คุณปรับปรุง แต่สิ่งที่ดีกว่าคือไม่ต้องการการปรับปรุงเลย HTML ที่มี CSS เพียงเล็กน้อยสามารถให้ประสบการณ์ที่ยอดเยี่ยมแก่ผู้ใช้ เป็นเนื้อหาที่มีความสำคัญและคุณไม่จำเป็นต้องมี JavaScript สำหรับสิ่งนั้น ยิ่งคุณสามารถพึ่งพาเนื้อหา (HTML) และสไตล์ (CSS) ได้มากเท่าไหร่ก็ยิ่งดีเท่านั้น ฉันไม่สามารถเน้นย้ำได้มากพอ บ่อยครั้งที่ประสบการณ์พื้นฐานดีที่สุดและมีประสิทธิภาพมากที่สุด มันไม่มีประโยชน์ที่จะปรับปรุงบางสิ่ง หากไม่ เพิ่มมูลค่า (ดูหลักการออกแบบที่รวม 7)

แน่นอนว่า มีบางครั้งที่ประสบการณ์พื้นฐานไม่ดีเท่าที่ควร — นั่นคือเวลาที่ควรจะปรับปรุง แต่ถ้าเราปฏิบัติตามแนวทางข้างต้น เมื่อชิ้นส่วนของ CSS หรือ JavaScript ไม่เป็นที่รู้จักหรือดำเนินการ สิ่งต่างๆ จะยังคงทำงานอยู่

การเพิ่มประสิทธิภาพแบบก้าวหน้าทำให้เรานึกถึงสิ่งที่จะเกิดขึ้นเมื่อสิ่งต่างๆ ล้มเหลว มันช่วยให้เราสามารถสร้างประสบการณ์ที่มีความยืดหยุ่น แต่ก็ทำให้เราคิดได้ว่าจำเป็นต้องมีการเพิ่มประสิทธิภาพหรือไม่ และถ้าเป็นเช่นนั้นควรทำอย่างไรดี

## ช่องรหัสผ่าน

เราใช้มาร์กอัปเดียวกันกับช่องอีเมลที่กล่าวถึงก่อนหน้านี้ หากคุณกำลังใช้ภาษาของเทมเพลต คุณจะสามารถสร้างส่วนประกอบที่รองรับฟิลด์ทั้งสองประเภทได้ ซึ่งจะช่วยในการบังคับใช้หลักการออกแบบที่ครอบคลุม 3 มีความสอดคล้องกัน

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

ฟิลด์รหัสผ่านมีคำใบ้ หากไม่มี ผู้ใช้จะไม่เข้าใจข้อกำหนด ซึ่งอาจทำให้เกิดข้อผิดพลาดได้เมื่อพยายามดำเนินการต่อ

แอตทริบิวต์ type="password" ปิดบังค่าของอินพุตโดยแทนที่สิ่งที่ผู้ใช้พิมพ์ด้วยจุดสีดำขนาดเล็ก นี่เป็นมาตรการรักษาความปลอดภัยที่จะหยุดไม่ให้ผู้อื่นเห็นสิ่งที่คุณพิมพ์หากพวกเขาอยู่ใกล้ๆ

### การเปิดเผยรหัสผ่าน

การปกปิดค่าในขณะที่ผู้ใช้พิมพ์ทำให้ยากต่อการแก้ไขข้อผิดพลาด ดังนั้นเมื่อมีการสร้างรายการ มักจะง่ายกว่าที่จะลบรายการทั้งหมดแล้วเริ่มใหม่อีกครั้ง สิ่งนี้น่าผิดหวังเนื่องจากผู้ใช้ส่วนใหญ่ไม่ได้ใช้คอมพิวเตอร์โดยมีคนมองข้ามไหล่

เนื่องจากมีความเสี่ยงในการพิมพ์ผิดมากขึ้น แบบฟอร์มการลงทะเบียนบางรูปแบบจึงมีฟิลด์ "ยืนยันรหัสผ่าน" เพิ่มเติม นี่เป็นมาตรการป้องกันที่กำหนดให้ผู้ใช้พิมพ์รหัสผ่านเดียวกันสองครั้ง เพิ่มความพยายามเป็นสองเท่าและทำให้ประสบการณ์ของผู้ใช้แย่ลง เป็นการดีกว่าที่จะให้ผู้ใช้เปิดเผยรหัสผ่าน ซึ่งพูดถึงหลักการที่ 4 และ 5 ให้การควบคุม และ เสนอทางเลือก ตามลำดับ วิธีนี้ผู้ใช้สามารถเลือกเปิดเผยรหัสผ่านเมื่อรู้ว่าไม่มีใครกำลังดูอยู่ ซึ่งจะช่วยลดความเสี่ยงในการพิมพ์ผิด

Internet Explorer และ Microsoft Edge เวอร์ชันล่าสุดมีพฤติกรรมนี้โดยกำเนิด ขณะที่เราจะสร้างโซลูชันของเราเอง เราควรระงับคุณลักษณะนี้โดยใช้ CSS ดังนี้:

 input[type=password]::-ms-reveal { display: none; }

ขั้นแรก เราต้องใส่ปุ่มที่อยู่ถัดจากอินพุต <button> องค์ประกอบควรเป็นองค์ประกอบ go-to ของคุณสำหรับการเปลี่ยนแปลงอะไรก็ตามด้วย JavaScript – ยกเว้น นั่นคือ สำหรับการเปลี่ยนตำแหน่ง ซึ่งเป็นสิ่งที่ลิงก์มีไว้เพื่อ เมื่อคลิกแล้ว ควรสลับแอตทริบิวต์ type ระหว่าง password และ text และป้ายกำกับของปุ่มระหว่าง "แสดง" และ "ซ่อน"

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### ไวยากรณ์ JavaScript และหมายเหตุทางสถาปัตยกรรม

เนื่องจาก JavaScript มีหลายรสชาติและหลากหลายวิธีในการสร้างส่วนประกอบ เราจะพูดถึงตัวเลือกที่ใช้ในการสร้างองค์ประกอบการเปิดเผยรหัสผ่าน และส่วนประกอบที่จะเกิดขึ้นทั้งหมดในหนังสือ

ขั้นแรก เราใช้ตัวสร้าง คอนสตรัคเตอร์เป็นฟังก์ชันที่เขียนด้วยอักษรตัวพิมพ์ใหญ่ - PasswordReveal ไม่ใช่ passwordReveal เริ่มต้นโดยใช้คำหลัก new ซึ่งช่วยให้เราใช้รหัสเดียวกันเพื่อสร้างส่วนประกอบหลายอินสแตนซ์:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

ประการที่สอง วิธีการของส่วนประกอบถูกกำหนดบนต้นแบบ — ตัวอย่างเช่น PasswordReveal.prototype.onButtonClick ต้นแบบเป็นวิธีที่มีประสิทธิภาพมากที่สุดในการแบ่งปันวิธีการในหลายอินสแตนซ์ขององค์ประกอบเดียวกัน

ประการที่สาม jQuery ถูกใช้เพื่อสร้างและดึงองค์ประกอบ และฟังเหตุการณ์ แม้ว่า jQuery อาจไม่จำเป็นหรือไม่ต้องการ แต่การใช้หมายความว่าหนังสือเล่มนี้สามารถเน้นที่รูปแบบและไม่เกี่ยวกับความซับซ้อนของส่วนประกอบข้ามเบราว์เซอร์

หากคุณเป็นนักออกแบบที่เขียนโค้ดเล็กน้อย ความแพร่หลายของ jQuery และอุปสรรคต่ำในการเข้าร่วมน่าจะเป็นประโยชน์ ในทำนองเดียวกัน หากคุณไม่ต้องการใช้ jQuery คุณจะไม่มีปัญหาในการปรับโครงสร้างองค์ประกอบใหม่เพื่อให้เหมาะกับความต้องการของคุณ

คุณอาจสังเกตเห็นการใช้ฟังก์ชัน $.proxy นี่คือการใช้งาน Function.prototype.bind ของ jQuery ถ้าเราไม่ได้ใช้ฟังก์ชันนี้เพื่อฟังเหตุการณ์ ตัวจัดการเหตุการณ์จะถูกเรียกในบริบทขององค์ประกอบ ( this ) ในตัวอย่างข้างต้น this.button จะไม่ถูกกำหนด แต่เราต้องการให้ this เป็นวัตถุเปิดเผยรหัสผ่านแทน เพื่อให้เราสามารถเข้าถึงคุณสมบัติและเมธอดของมันได้

#### ตัวเลือกอินเทอร์เฟซทางเลือก

อินเทอร์เฟซการเปิดเผยรหัสผ่านที่เราสร้างขึ้นด้านบนจะสลับป้ายกำกับของปุ่มระหว่าง "แสดงรหัสผ่าน" และ "ซ่อนรหัสผ่าน" ผู้ใช้โปรแกรมอ่านหน้าจอบางรายอาจสับสนเมื่อเปลี่ยนป้ายกำกับของปุ่ม เมื่อผู้ใช้พบปุ่มใดปุ่มหนึ่ง พวกเขาคาดหวังว่าปุ่มนั้นจะคงอยู่ แม้ว่าปุ่ม จะ คงอยู่ แต่การเปลี่ยนป้ายกำกับจะทำให้ดูเหมือนไม่เป็นเช่นนั้น

หากการวิจัยของคุณแสดงว่าสิ่งนี้เป็นปัญหา คุณสามารถลองใช้วิธีอื่นสองวิธี

ขั้นแรก ใช้ช่องทำเครื่องหมายที่มีป้ายกำกับว่า "แสดงรหัสผ่าน" ถาวร สถานะจะถูกส่งสัญญาณโดยแอตทริบิวต์ที่ checked ผู้ใช้โปรแกรมอ่านหน้าจอจะได้ยิน “แสดงรหัสผ่าน กล่องกาเครื่องหมาย เลือกแล้ว” (หรือคล้ายกัน) ผู้ใช้ที่มองเห็นจะเห็นช่องทำเครื่องหมาย ปัญหาของวิธีนี้คือ ช่องทำเครื่องหมายมีไว้สำหรับป้อนข้อมูล ไม่ใช่ควบคุมอินเทอร์เฟซ ผู้ใช้บางคนอาจคิดว่ารหัสผ่านของพวกเขาจะถูกเปิดเผยต่อระบบ

หรืออย่างที่สอง เปลี่ยน state ของปุ่ม — ไม่ใช่ป้ายกำกับ ในการถ่ายทอดสถานะไปยังผู้ใช้โปรแกรมอ่านหน้าจอ คุณสามารถสลับแอตทริบิวต์ที่ aria-pressed ระหว่าง true (กด) และ false (ไม่ได้กด)

 <button type="button" aria-pressed="true"> Show password </button>

เมื่อโฟกัสที่ปุ่ม โปรแกรมอ่านหน้าจอจะประกาศว่า “แสดงรหัสผ่าน ปุ่มสลับ กดแล้ว” (หรือใกล้เคียง) สำหรับผู้ใช้ที่มองเห็น คุณสามารถจัดรูปแบบปุ่มให้ดูเหมือนถูกกดหรือไม่ได้กดตามนั้นโดยใช้ตัวเลือกแอตทริบิวต์ดังนี้:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

เพียงแค่ต้องแน่ใจว่ารูปแบบที่ไม่กดทับและกดทับนั้นชัดเจนและแตกต่าง มิฉะนั้น ผู้ใช้ที่มองเห็นอาจลำบากในการบอกความแตกต่างระหว่างพวกเขา

### ไมโครสำเนา

ป้ายกำกับถูกตั้งค่าเป็น "เลือกรหัสผ่าน" แทนที่จะเป็น "รหัสผ่าน" อันหลังค่อนข้างจะสับสนและอาจแจ้งให้ผู้ใช้พิมพ์รหัสผ่านที่มีอยู่แล้ว ซึ่งอาจเป็นปัญหาด้านความปลอดภัย ที่ละเอียดกว่านั้น อาจแนะนำให้ผู้ใช้ลงทะเบียนแล้ว ทำให้ผู้ใช้ที่มีความบกพร่องทางสติปัญญาคิดว่ากำลังเข้าสู่ระบบแทน

ในกรณีที่ “รหัสผ่าน” คลุมเครือ “เลือกรหัสผ่าน” จะมีความชัดเจน

## รูปแบบปุ่ม

ปุ่มอะไร? เราเรียกส่วนประกอบต่างๆ มากมายบนหน้าเว็บว่าเป็นปุ่ม อันที่จริงฉันได้กล่าวถึงปุ่มสองประเภทที่แตกต่างกันไปแล้วโดยไม่ต้องเรียกมันออกมา มาทำกันตอนนี้เลย

ปุ่มที่ส่งแบบฟอร์มคือ "ปุ่มส่ง" และโดยทั่วไปจะมีการเข้ารหัสเป็น <input type="submit"> หรือ <button type="submit"> <button> องค์ประกอบจะอ่อนกว่าเพราะคุณสามารถซ้อนองค์ประกอบอื่นๆ ไว้ข้างในได้ แต่ไม่ค่อยมีความจำเป็นเท่าไหร่ ปุ่มส่งส่วนใหญ่มีเพียงข้อความ

หมายเหตุ: ใน Internet Explorer เวอร์ชันเก่า หากคุณมี <button type="submit"> หลายรายการ แบบฟอร์มจะส่งค่าของปุ่มทั้งหมดไปยังเซิร์ฟเวอร์ ไม่ว่าจะคลิกใดก็ตาม คุณจะต้องรู้ว่ามีการคลิกปุ่มใด คุณจึงสามารถกำหนดแนวทางการดำเนินการที่ถูกต้องได้ ซึ่งเป็นเหตุผลที่ควรหลีกเลี่ยงองค์ประกอบนี้

ปุ่มอื่นๆ จะถูกใส่เข้าไปในอินเทอร์เฟซเพื่อเพิ่มประสบการณ์ในการใช้งาน JavaScript เช่นเดียวกับที่เราทำกับองค์ประกอบการเปิดเผยรหัสผ่านที่กล่าวถึงก่อนหน้านี้ นั่นก็เป็น <button> เช่นกัน แต่ type ของมันถูกตั้งค่าเป็น button (ไม่ใช่ submit )

ในทั้งสองกรณี สิ่งแรกที่ต้องรู้เกี่ยวกับปุ่มคือปุ่มเหล่านั้นไม่ใช่ลิงก์ โดยทั่วไป ลิงก์จะถูกขีดเส้นใต้ (ตามรูปแบบตัวแทนผู้ใช้) หรือจัดตำแหน่งพิเศษ (ในแถบนำทาง) เพื่อให้สามารถแยกแยะระหว่างข้อความปกติได้ เมื่อวางเมาส์เหนือลิงก์ เคอร์เซอร์จะเปลี่ยนเป็นตัวชี้ นี่เป็นเพราะว่าลิงก์มีความสามารถในการรับรู้ที่อ่อนแอซึ่งแตกต่างจากปุ่ม

ใน การออกแบบเว็บที่ยืดหยุ่น Jeremy Keith กล่าวถึงแนวคิดเรื่องความซื่อสัตย์สุจริต เขา​บอก​ว่า “วัสดุ​ชนิด​หนึ่ง​ไม่​ควร​ใช้​แทน​สิ่ง​อื่น. มิฉะนั้นผลลัพธ์สุดท้ายจะหลอกลวง” การทำลิงค์ให้ดูเหมือนปุ่มนั้นไม่ซื่อสัตย์อย่างยิ่ง โดยจะบอกผู้ใช้ว่าลิงก์และปุ่มต่างๆ จะเหมือนกันเมื่อไม่ใช่

ลิงก์สามารถทำสิ่งที่ปุ่มไม่สามารถทำได้ สามารถเปิดลิงก์ในแท็บใหม่หรือบุ๊กมาร์กไว้ใช้ภายหลังได้ เป็นต้น ดังนั้น ปุ่มต่างๆ ไม่ควรมีลักษณะเหมือนลิงก์ และไม่ควรมีเคอร์เซอร์ตัวชี้ แต่เราควรทำให้ปุ่มดูเหมือนปุ่มซึ่งมีราคาที่เอื้อมถึงโดยธรรมชาติ ไม่ว่าพวกมันจะมีมุมโค้งมน เงาตกกระทบ และเส้นขอบหรือไม่ก็ขึ้นอยู่กับคุณ แต่พวกมันควรมีลักษณะเหมือนปุ่มโดยไม่คำนึงถึง

ปุ่มยังคงสามารถให้ข้อเสนอแนะเมื่อวางเมาส์เหนือ (และเมื่อโฟกัส) ได้โดยเปลี่ยนสีพื้นหลัง เป็นต้น

### ตำแหน่ง

โดยทั่วไป ปุ่มส่งจะวางไว้ที่ด้านล่างของแบบฟอร์ม: สำหรับแบบฟอร์มส่วนใหญ่ ผู้ใช้จะกรอกข้อมูลในฟิลด์จากบนลงล่าง แล้วจึงส่ง แต่ปุ่มควรอยู่ชิดซ้าย ขวา หรือตรงกลาง? ในการตอบคำถามนี้ เราต้องพิจารณาว่าผู้ใช้จะมองหาที่ใด

ป้ายฟิลด์และตัวควบคุมฟอร์มจะจัดชิดซ้าย (ในภาษาที่อ่านจากซ้ายไปขวา) และเรียกใช้จากบนลงล่าง ผู้ใช้จะมองหาช่องถัดไปด้านล่างช่องสุดท้าย โดยปกติ ปุ่มส่งควรอยู่ในตำแหน่งนั้นด้วย: ทางด้านซ้ายและด้านล่างช่องสุดท้ายโดยตรง นอกจากนี้ยังช่วยผู้ใช้ที่ซูมเข้า เนื่องจากปุ่มที่จัดชิดขวาอาจหายไปเมื่ออยู่นอกหน้าจอได้ง่ายขึ้น

### ข้อความ

ข้อความของปุ่มมีความสำคัญพอๆ กับสไตล์ของปุ่ม ข้อความควรอธิบายการดำเนินการที่กำลังดำเนินการอย่างชัดเจน และเนื่องจากเป็นการกระทำ จึงควรเป็นคำกริยา เราควรตั้งเป้าที่จะใช้คำให้น้อยที่สุดเพราะจะอ่านได้เร็วกว่า แต่เราไม่ควรลบคำที่ต้องใช้ความชัดเจน

คำที่ตรงกันทั้งหมดสามารถจับคู่กับน้ำเสียงของแบรนด์ของคุณได้ แต่อย่าเปลี่ยนความชัดเจนเป็นความแหวกแนว

ภาษาที่เรียบง่ายและเข้าใจง่ายสำหรับทุกคนที่จะเข้าใจ คำที่แน่นอนจะขึ้นอยู่กับประเภทของบริการ สำหรับแบบฟอร์มการลงทะเบียนของเรา “ลงทะเบียน” นั้นใช้ได้ แต่ขึ้นอยู่กับบริการของคุณ “เข้าร่วม” หรือ “ลงทะเบียน” อาจเหมาะสมกว่า

## การตรวจสอบความถูกต้อง

แม้ว่าเราจะพยายามสร้างประสบการณ์การลงทะเบียนที่ครอบคลุม เรียบง่าย และปราศจากการเสียดสี เราไม่สามารถขจัดข้อผิดพลาดของมนุษย์ได้ คนเราผิดพลาดกันได้ และเมื่อทำผิดพลาด เราควรแก้ไขให้ง่ายที่สุด

เมื่อพูดถึงการตรวจสอบความถูกต้องของแบบฟอร์ม มีรายละเอียดที่สำคัญหลายประการที่ต้องพิจารณา ตั้งแต่การเลือกว่าจะให้คำติชมเมื่อใด ไปจนถึงวิธีแสดงคำติชมนั้น ไปจนถึงการกำหนดข้อความแสดงข้อผิดพลาดที่ดี สิ่งเหล่านี้จำเป็นต้องนำมาพิจารณาด้วย

### การตรวจสอบ HTML5

การตรวจสอบความถูกต้องของ HTML5 มีมาระยะหนึ่งแล้ว การเพิ่มแอตทริบิวต์ HTML เพียงไม่กี่รายการ เบราว์เซอร์ที่รองรับจะทำเครื่องหมายฟิลด์ที่ผิดพลาดเมื่อส่งแบบฟอร์ม เบราว์เซอร์ที่ไม่รองรับจะกลับไปใช้การตรวจสอบฝั่งเซิร์ฟเวอร์

โดยปกติ ฉันจะแนะนำให้ใช้ฟังก์ชันที่เบราว์เซอร์มีให้ฟรี เพราะมักจะมีประสิทธิภาพมากกว่า แข็งแกร่ง และเข้าถึงได้ง่ายกว่า ไม่ต้องพูดถึง ผู้ใช้จะคุ้นเคยมากขึ้นเมื่อมีไซต์ต่างๆ เริ่มใช้ฟังก์ชันมาตรฐานมากขึ้น

แม้ว่าการสนับสนุนการตรวจสอบความถูกต้องของ HTML5 จะค่อนข้างดี แต่ก็ไม่ได้นำมาใช้อย่างเท่าเทียมกัน ตัวอย่างเช่น แอตทริบิวต์ที่จำเป็นสามารถทำเครื่องหมายช่องว่าไม่ถูกต้องตั้งแต่เริ่มต้น ซึ่งไม่ต้องการ เบราว์เซอร์บางตัว เช่น Firefox 45.7 จะแสดงข้อผิดพลาด "Please enter an email address" แม้ว่าผู้ใช้จะป้อนบางอย่างในช่อง ในขณะที่ Chrome เช่น "Please ใส่ '@' ในที่อยู่อีเมล" ซึ่งเป็นประโยชน์มากกว่า

นอกจากนี้เรายังต้องการให้ผู้ใช้มีส่วนต่อประสานเดียวกันไม่ว่าจะตรวจพบข้อผิดพลาดบนเซิร์ฟเวอร์หรือไคลเอนต์ ด้วยเหตุผลเหล่านี้ เราจะออกแบบโซลูชันของเราเอง สิ่งแรกที่ต้องทำคือปิดการตรวจสอบ HTML5: <form novalidate>

### การจัดการการส่ง

เมื่อผู้ใช้ส่งแบบฟอร์ม เราต้องตรวจสอบว่ามีข้อผิดพลาดหรือไม่ หากมีเราต้องป้องกันไม่ให้แบบฟอร์มส่งรายละเอียดไปยังเซิร์ฟเวอร์

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

โปรดทราบว่าเรากำลังฟังเหตุการณ์การส่งของแบบฟอร์ม ไม่ใช่เหตุการณ์การคลิกปุ่ม หลังจะหยุดผู้ใช้สามารถส่งแบบฟอร์มโดยกด Enter เมื่อโฟกัสอยู่ในฟิลด์ใดฟิลด์หนึ่ง นี้เรียกอีกอย่างว่า การส่งแบบฟอร์มโดยปริยาย

### กำลังแสดงคำติชม

การตรวจจับการมีอยู่ของข้อผิดพลาดเป็นอย่างดี แต่ ณ จุดนี้ผู้ใช้ไม่มีใครฉลาดกว่า อินเทอร์เฟซมีสามส่วนที่แตกต่างกันซึ่งจำเป็นต้องได้รับการอัปเดต เราจะพูดถึงแต่ละคนในตอนนี้

#### ชื่อเอกสาร

<title> ของเอกสารคือส่วนแรกของหน้าเว็บที่โปรแกรมอ่านหน้าจอจะอ่านออก ด้วยเหตุนี้ เราจึงสามารถใช้เพื่อแจ้งให้ผู้ใช้ทราบว่ามีบางอย่างผิดพลาดในการส่ง สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อหน้าโหลดซ้ำหลังจากเซิร์ฟเวอร์ร้องขอ

แม้ว่าเราจะปรับปรุงประสบการณ์ผู้ใช้ด้วยการตรวจจับข้อผิดพลาดในไคลเอนต์ด้วย JavaScript แต่ก็ไม่สามารถตรวจจับข้อผิดพลาดทั้งหมดได้ด้วยวิธีนี้ ตัวอย่างเช่น การตรวจสอบว่ายังไม่ได้ใช้ที่อยู่อีเมล สามารถตรวจสอบได้บนเซิร์ฟเวอร์เท่านั้น และไม่ว่าในกรณีใด JavaScript มีแนวโน้มที่จะล้มเหลว ดังนั้นเราจึงไม่สามารถพึ่งพาความพร้อมใช้งานได้เพียงอย่างเดียว

ในกรณีที่ชื่อหน้าต้นฉบับอาจอ่านว่า “ลงทะเบียนสำหรับ [บริการ]” โดยผิดพลาด ควรเขียนว่า “(ข้อผิดพลาด 2 ข้อ) ลงทะเบียนสำหรับ [บริการ]” (หรือคล้ายกัน) ถ้อยคำที่แน่นอนค่อนข้างลงความเห็น

JavaScript ต่อไปนี้จะอัปเดตชื่อ:

 document.title = "(" + this.errors.length + ")" + document.title;

ดังที่กล่าวไว้ข้างต้น ฟีเจอร์นี้มีไว้สำหรับผู้ใช้โปรแกรมอ่านหน้าจอเป็นหลัก แต่โดยปกติแล้วจะมีการออกแบบที่ครอบคลุม สิ่งที่ช่วยให้ผู้ใช้ชุดหนึ่งช่วยคนอื่นๆ ได้เช่นกัน คราวนี้ ชื่อเรื่องที่อัปเดตจะทำหน้าที่เป็นการแจ้งเตือนในแท็บ

สรุปข้อผิดพลาด

เมื่อเปรียบเทียบกับองค์ประกอบชื่อแล้ว สรุปข้อผิดพลาดจะเด่นชัดกว่า ซึ่งบอกผู้ใช้ที่มองเห็นว่ามีบางอย่างผิดพลาด แต่ยังมีหน้าที่ในการให้ผู้ใช้เข้าใจว่ามีอะไรผิดพลาดและจะแก้ไขอย่างไร

อยู่ในตำแหน่งที่ด้านบนของหน้า ดังนั้นผู้ใช้จึงไม่ต้องเลื่อนลงเพื่อดูหลังจากรีเฟรชหน้า (หากมีข้อผิดพลาดเกิดขึ้นบนเซิร์ฟเวอร์) ตามอัตภาพ ข้อผิดพลาดจะเป็นสีแดง อย่างไรก็ตาม การใช้สีเพียงอย่างเดียวอาจแยกผู้ใช้ที่ตาบอดสีออกได้ หากต้องการดึงความสนใจไปที่สรุป ให้พิจารณาใช้ตำแหน่ง ขนาด ข้อความ และการยึดถือ

แผงจะมีหัวข้อ "มีปัญหา" เพื่อระบุปัญหา สังเกตว่ามันไม่ได้พูดคำว่า “ผิดพลาด” ซึ่งไม่เป็นมิตรนัก ลองนึกภาพคุณกำลังกรอกรายละเอียดเพื่อซื้อรถในโชว์รูมแล้วทำผิดพลาด พนักงานขายจะไม่พูดว่า "ผิดพลาด" - อันที่จริงมันคงแปลกถ้าพวกเขาพูดอย่างนั้น

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

คอนเทนเนอร์มี role ของ group ซึ่งใช้เพื่อจัดกลุ่มชุดองค์ประกอบอินเทอร์เฟซ: ในกรณีนี้ ส่วนหัวและลิงก์ข้อผิดพลาด แอตทริบิวต์ tabindex ถูกตั้งค่าเป็น -1 จึงสามารถโฟกัสโดยทางโปรแกรมด้วย JavaScript (เมื่อส่งแบบฟอร์มโดยมีข้อผิดพลาด) เพื่อให้แน่ใจว่าแผงสรุปข้อผิดพลาดถูกเลื่อนเข้ามาในมุมมอง มิฉะนั้น อินเทอร์เฟซจะไม่ตอบสนองและใช้งานไม่ได้เมื่อส่ง

หมายเหตุ: การใช้ tabindex="0" หมายความว่าจะสามารถโฟกัสได้ถาวรโดยใช้ปุ่ม Tab ซึ่งก็คือ 2.4.3 Focus Order WCAG ล้มเหลว หากผู้ใช้สามารถแท็บบางอย่างได้ พวกเขาก็คาดหวังว่าจะทำบางสิ่งได้จริงๆ

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

ด้านล่างมีรายการลิงก์ข้อผิดพลาด การคลิกลิงก์จะกำหนดโฟกัสไปที่ช่องที่ผิดพลาด ซึ่งช่วยให้ผู้ใช้สามารถเข้าสู่แบบฟอร์มได้อย่างรวดเร็ว แอตทริบิวต์ href ของลิงก์ถูกตั้งค่าเป็น ID ของตัวควบคุม ซึ่งในบางเบราว์เซอร์ก็เพียงพอที่จะกำหนดโฟกัสไปที่มัน อย่างไรก็ตาม ในเบราว์เซอร์อื่นๆ การคลิกลิงก์จะเป็นการเลื่อนข้อมูลเข้าในมุมมองโดยไม่ต้องเน้น ในการแก้ไขปัญหานี้ เราสามารถเน้นอินพุตได้อย่างชัดเจน

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

เมื่อไม่มีข้อผิดพลาด ควรซ่อนแผงสรุป สิ่งนี้ทำให้มั่นใจได้ว่ามีแผงสรุปเพียงแผงเดียวบนหน้า และแผงนั้นจะปรากฏขึ้นอย่างสม่ำเสมอในตำแหน่งเดียวกัน ไม่ว่าไคลเอ็นต์หรือเซิร์ฟเวอร์จะแสดงข้อผิดพลาด ในการซ่อนพาเนล เราต้องเพิ่มคลาสของ hidden .

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

หมายเหตุ: คุณสามารถใช้แอตทริบิวต์/คุณสมบัติที่ hidden เพื่อสลับการมองเห็นขององค์ประกอบได้ แต่มีการสนับสนุนน้อยกว่า การออกแบบแบบรวมเป็นเรื่องเกี่ยวกับการตัดสินใจที่คุณรู้ว่าไม่น่าจะกีดกันผู้คน การใช้ชั้นเรียนสอดคล้องกับปรัชญานี้

#### ข้อผิดพลาดในบรรทัด

เราจำเป็นต้องใส่ข้อความแสดงข้อผิดพลาดที่เกี่ยวข้องไว้เหนือฟิลด์ ซึ่งจะช่วยให้ผู้ใช้เลื่อนหน้าขึ้นและลงเพื่อตรวจสอบข้อความแสดงข้อผิดพลาด และช่วยให้ผู้ใช้เลื่อนลงไปตามแบบฟอร์ม หากข้อความถูกวางไว้ใต้ฟิลด์ เราจะเพิ่มโอกาสที่ข้อความจะถูกบดบังโดยแผงเติมข้อความอัตโนมัติของเบราว์เซอร์หรือโดยแป้นพิมพ์บนหน้าจอ

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

เช่นเดียวกับรูปแบบคำใบ้ที่กล่าวถึงก่อนหน้านี้ ข้อความแสดงข้อผิดพลาดจะถูกแทรกเข้าไปภายในฉลาก เมื่อเน้นฟิลด์ ผู้ใช้โปรแกรมอ่านหน้าจอจะได้ยินข้อความในบริบท จึงสามารถย้ายผ่านฟอร์มได้อย่างอิสระโดยไม่ต้องอ้างอิงถึงสรุป

ข้อความแสดงข้อผิดพลาดเป็นสีแดงและใช้ไอคอนคำเตือน SVG เพื่อดึงดูดความสนใจของผู้ใช้ หากเราใช้เพียงการเปลี่ยนสีเพื่อแสดงข้อผิดพลาด การดำเนินการนี้จะไม่รวมผู้ใช้ที่ตาบอดสี วิธีนี้ใช้ได้ผลดีสำหรับผู้ใช้ที่มองเห็น — แต่ผู้ใช้โปรแกรมอ่านหน้าจอล่ะ

เพื่อให้ผู้ใช้ที่มองเห็นและผู้ใช้ที่มองไม่เห็นได้รับประสบการณ์ที่เท่าเทียมกัน เราสามารถใช้แอตทริบิวต์ aria-invalid ที่ได้รับการสนับสนุนอย่างดี เมื่อผู้ใช้เน้นที่อินพุต ตอนนี้จะแจ้งว่า "ไม่ถูกต้อง" (หรือคล้ายกัน) ในโปรแกรมอ่านหน้าจอ

 <input aria-inval>

หมายเหตุ: แบบฟอร์มการลงทะเบียนประกอบด้วยการป้อนข้อความเท่านั้น ในบทที่ 3 “แบบฟอร์มการจองเที่ยวบิน” เราจะดูวิธีการใส่ข้อผิดพลาดที่เข้าถึงได้สำหรับกลุ่มของฟิลด์ เช่น ปุ่มตัวเลือก

### ส่งแบบฟอร์มอีกครั้ง

เมื่อส่งแบบฟอร์มเป็นครั้งที่สอง เราจำเป็นต้องล้างข้อผิดพลาดที่มีอยู่ออกจากมุมมอง มิฉะนั้น ผู้ใช้อาจเห็นข้อผิดพลาดซ้ำซ้อน

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### การเริ่มต้น

เมื่อกำหนดองค์ประกอบ FormValidator เสร็จแล้ว เราก็พร้อมที่จะเริ่มต้นใช้งาน ในการสร้างอินสแตนซ์ของ FormValidator คุณต้องส่งองค์ประกอบแบบฟอร์มเป็นพารามิเตอร์แรก

 var validator = new FormValidator(document.getElementById('registration'));

หากต้องการตรวจสอบความถูกต้องของฟิลด์อีเมล ให้เรียก addValidator() ดังนี้

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

พารามิเตอร์แรกคือ name ของตัวควบคุม และพารามิเตอร์ที่สองคืออาร์เรย์ของออบเจ็กต์กฎ แต่ละกฎมีคุณสมบัติสองประการ: method และ message method เป็นฟังก์ชันที่ทดสอบเงื่อนไขต่างๆ เพื่อคืนค่า true หรือ false False ทำให้ฟิลด์อยู่ในสถานะข้อผิดพลาด ซึ่งใช้เพื่อเติมอินเทอร์เฟซที่มีข้อผิดพลาดตามที่กล่าวไว้ก่อนหน้านี้

#### การให้อภัยความผิดพลาดเล็กน้อย

ใน The Design of Everyday Things ดอน นอร์แมนพูดถึงการออกแบบเพื่อหาข้อผิดพลาด เขาพูดเกี่ยวกับวิธีการสนทนาของผู้คน:

“ถ้ามีคนพูดอะไรที่เราเชื่อว่าเป็นเท็จ เราจะตั้งคำถามและโต้เถียงกัน เราไม่ออกสัญญาณเตือน เราไม่ส่งเสียงบี๊บ เราไม่แสดงข้อความแสดงข้อผิดพลาด […] ในการสนทนาปกติระหว่างเพื่อนสองคน การแสดงข้อมูลที่ขัดต่อข้อเท็จจริงถือเป็นเรื่องปกติ ใกล้เคียงกับความหมายจริงๆ”

เครื่องจักรไม่ฉลาดพอที่จะกำหนดความหมายของการกระทำส่วนใหญ่ต่างจากมนุษย์ แต่มักให้อภัยความผิดพลาดน้อยกว่าที่ควรจะเป็น Jared Spool สร้างเรื่องตลกเกี่ยวกับเรื่องนี้ใน “Is Design Metrically Opposed?” (ประมาณ 42 นาทีใน):

“ต้องใช้รหัสหนึ่งบรรทัดในการดึงหมายเลขโทรศัพท์และดึงเครื่องหมายขีดคั่น วงเล็บ และช่องว่างทั้งหมดออก และต้องใช้รหัสสิบบรรทัดในการเขียนข้อความแสดงข้อผิดพลาดที่คุณทิ้งไว้”

วิธีการ addValidator (แสดงไว้ด้านบน) สาธิตวิธีออกแบบกฎการตรวจสอบเพื่อให้พวกเขาให้อภัยข้อผิดพลาดเล็กน้อย กฎข้อแรก เช่น ตัดแต่งค่าก่อนตรวจสอบความยาว ช่วยลดภาระของผู้ใช้

### การตรวจสอบความถูกต้องอินไลน์สด

การตรวจสอบความถูกต้องแบบอินไลน์แบบสดให้คำติชมแก่ผู้ใช้ขณะที่พิมพ์หรือเมื่อออกจากฟิลด์ ( onblur ) มีหลักฐานบางอย่างที่แสดงว่าการตรวจสอบความถูกต้องแบบอินไลน์แบบสดช่วยเพิ่มความแม่นยำและลดเวลาในการดำเนินการให้เสร็จสิ้นในรูปแบบยาว ส่วนหนึ่งเกี่ยวข้องกับการให้คำติชมแก่ผู้ใช้เมื่อความต้องการของฟิลด์มีความสดใหม่ในใจของผู้ใช้ แต่การตรวจสอบความถูกต้องแบบอินไลน์แบบสด (หรือการตรวจสอบแบบสดโดยย่อ) ก่อให้เกิดปัญหาหลายประการ

สำหรับรายการที่ต้องใช้อักขระจำนวนหนึ่ง การกดแป้นพิมพ์ครั้งแรกจะถือเป็นรายการที่ไม่ถูกต้องเสมอ ซึ่งหมายความว่าผู้ใช้จะถูกขัดจังหวะตั้งแต่เนิ่นๆ ซึ่งอาจทำให้พวกเขาเปลี่ยนบริบททางจิตจากการป้อนข้อมูลเพื่อแก้ไข

อีกทางหนึ่ง เราอาจรอจนกว่าผู้ใช้จะป้อนอักขระเพียงพอก่อนที่จะแสดงข้อผิดพลาด แต่นี่หมายความว่าผู้ใช้จะได้รับคำติชมหลังจากป้อนค่าที่ถูกต้องเท่านั้น ซึ่งค่อนข้างไร้ประโยชน์

เราสามารถรอจนกว่าผู้ใช้ออกจากฟิลด์ ( onblur ) แต่นี่สายเกินไปเนื่องจากผู้ใช้ได้เตรียมใจสำหรับฟิลด์ถัดไป (และมักจะเริ่มพิมพ์) นอกจากนี้ ผู้ใช้บางคนสลับหน้าต่างหรือใช้ตัวจัดการรหัสผ่านเมื่อใช้แบบฟอร์ม การทำเช่นนั้นจะทำให้เกิดเหตุการณ์เบลอ ทำให้เกิดข้อผิดพลาดปรากฏขึ้นก่อนที่ผู้ใช้จะเสร็จสิ้น ทั้งหมดน่าผิดหวังมาก

จำไว้ว่าไม่มีปัญหาในการให้คำติชมแก่ผู้ใช้โดยไม่ต้องรีเฟรชหน้า และไม่มีปัญหาในการใส่ข้อความแสดงข้อผิดพลาดในบรรทัด (ข้างฟิลด์) — เราได้ดำเนินการเรียบร้อยแล้ว ปัญหาของฟีดแบ็คแบบสดๆ คือการรบกวนผู้ใช้ทั้งเร็วเกินไปหรือช้าเกินไป ซึ่งมักจะส่งผลให้เกิดประสบการณ์ที่สะเทือนใจ

หากผู้ใช้พบข้อผิดพลาดบ่อยครั้ง อาจมีบางอย่างผิดปกติในที่อื่น มุ่งเน้นที่การย่อแบบฟอร์มของคุณและให้คำแนะนำที่ดีขึ้น (การติดฉลากที่ดีและข้อความแนะนำ) วิธีนี้ผู้ใช้ไม่ควรเห็นมากกว่าข้อผิดพลาดคี่ เราจะดูรูปแบบที่ยาวขึ้นในบทต่อไป

### รูปแบบการยืนยันรายการตรวจสอบ

รูปแบบของการตรวจสอบความถูกต้องแบบสดเกี่ยวข้องกับการทำเครื่องหมายกฎ (ทำเครื่องหมายว่าเสร็จสมบูรณ์) ขณะที่ผู้ใช้พิมพ์ นี่เป็นการบุกรุกน้อยกว่าการตรวจสอบความถูกต้อง แต่ไม่เหมาะกับฟิลด์ทุกประเภท นี่คือตัวอย่างแบบฟอร์มลงทะเบียนของ MailChimp ซึ่งใช้เทคนิคนี้สำหรับฟิลด์รหัสผ่าน

คุณควรวางกฎไว้เหนือฟิลด์ มิฉะนั้น แป้นพิมพ์บนหน้าจออาจปิดบังความคิดเห็น ส่งผลให้ผู้ใช้อาจหยุดพิมพ์และซ่อนแป้นพิมพ์เพื่อตรวจสอบความคิดเห็น

### หมายเหตุเกี่ยวกับการปิดใช้งานปุ่มส่ง

แบบฟอร์มบางรูปแบบออกแบบมาเพื่อปิดใช้งานปุ่มส่งจนกว่าฟิลด์ทั้งหมดจะถูกต้อง มีปัญหาหลายประการเกี่ยวกับเรื่องนี้

ประการแรก ผู้ใช้มักสงสัยว่าเกิดอะไรขึ้นกับรายการของพวกเขา ประการที่สอง ปุ่มที่ปิดใช้งานจะไม่สามารถโฟกัสได้ ซึ่งทำให้ผู้ใช้ที่มองไม่เห็นปุ่มค้นพบได้ยากโดยใช้ปุ่ม Tab ประการที่สาม ปุ่มที่ปิดใช้งานนั้นอ่านยากเนื่องจากเป็นสีเทา

เนื่องจากเราให้ข้อเสนอแนะที่ชัดเจนแก่ผู้ใช้ เมื่อผู้ใช้คาดหวัง ไม่มีเหตุผลที่ดีที่จะควบคุมผู้ใช้โดยการปิดใช้งานปุ่มอยู่ดี

### การสร้างข้อความแสดงข้อผิดพลาดที่ดี

ไม่มีอะไรสำคัญไปกว่าเนื้อหา ผู้ใช้ไม่ได้มาที่เว็บไซต์ของคุณเพื่อเพลิดเพลินกับการออกแบบ พวกเขามาเพลิดเพลินกับเนื้อหาหรือผลลัพธ์ของการใช้บริการ

แม้แต่ประสบการณ์ที่ได้รับการไตร่ตรอง ครอบคลุม และออกแบบมาอย่างสวยงามที่สุดก็ไม่มีประโยชน์หากเราละเลยคำที่ใช้สร้างข้อความแสดงข้อผิดพลาด การศึกษาหนึ่งพบว่าการแสดงข้อความแสดงข้อผิดพลาดที่กำหนดเองช่วยเพิ่ม Conversion ได้ 0.5% ซึ่งเท่ากับรายได้ต่อปีมากกว่า 250,000 ปอนด์

“เนื้อหาคือประสบการณ์ของผู้ใช้”
— จินนี่ เรดิช

เช่นเดียวกับป้ายกำกับ คำใบ้ และเนื้อหาอื่นๆ ข้อความแสดงข้อผิดพลาดที่ดีจะให้ความชัดเจนโดยใช้คำไม่กี่คำเท่านั้น โดยปกติ เราควรขับเคลื่อนการออกแบบอินเทอร์เฟซตามเนื้อหา ไม่ใช่ในทางกลับกัน แต่ในกรณีนี้ การทำความเข้าใจว่าเหตุใดคุณจึงแสดงข้อความแสดงข้อผิดพลาดส่งผลต่อการออกแบบคำ นี่คือเหตุผลที่ Jared Spool กล่าวว่า "เนื้อหาและการออกแบบเป็นเพื่อนร่วมงานที่แยกกันไม่ออก"

เรากำลังแสดงข้อความในข้อมูลสรุปที่ด้านบนของหน้าจอและข้างช่องต่างๆ การรักษาข้อความเดียวกันไว้สองเวอร์ชันนั้นเป็นการขายที่ยากเพื่อให้ได้กำไรที่ไม่น่าเชื่อ ให้ออกแบบข้อความแสดงข้อผิดพลาดที่ใช้งานได้ทั้งสองที่แทน “ป้อนสัญลักษณ์ 'at'” จำเป็นต้องมีบริบทจากป้ายกำกับฟิลด์เพื่อให้สมเหตุสมผล “ที่อยู่อีเมลของคุณต้องมีสัญลักษณ์ 'at'” ใช้งานได้ดีทั้งสองที่

หลีกเลี่ยงสิ่งที่น่ายินดี เช่น การเริ่มแต่ละข้อความแสดงข้อผิดพลาดด้วยคำว่า “Please” ในแง่หนึ่งสิ่งนี้ดูสุภาพ ในทางกลับกัน มันเข้ามาขวางทางและบ่งบอกถึงทางเลือก

ไม่ว่าคุณจะใช้วิธีการใดก็ตาม จะมีความซ้ำซากจำเจเนื่องจากลักษณะของเนื้อหา และการทดสอบมักจะเกี่ยวข้องกับการส่งแบบฟอร์มโดยไม่ต้องป้อนข้อมูลใดๆ เลย สิ่งนี้ทำให้การทำซ้ำๆ ชัดเจนขึ้นซึ่งอาจทำให้เราพลิกออก แต่สิ่งนี้เกิดขึ้นบ่อยแค่ไหน? ผู้ใช้ส่วนใหญ่ไม่ได้พยายามทำลายอินเทอร์เฟซ

ข้อผิดพลาดที่แตกต่างกันต้องมีการจัดรูปแบบที่แตกต่างกัน คำแนะนำเช่น "ป้อนชื่อของคุณ" เป็นเรื่องปกติ แต่ “ป้อนชื่อที่มีความยาวไม่เกิน 35 อักขระ” นั้นยาวกว่า ใช้คำน้อยกว่า และเป็นธรรมชาติน้อยกว่าคำอธิบาย เช่น “ชื่อต้องมีความยาวไม่เกิน 35 อักขระ”

นี่คือรายการตรวจสอบ:

• กระชับ. อย่าใช้คำมากเกินความจำเป็น แต่อย่าละเลยคำเพราะต้องการความชัดเจน
• คงเส้นคงวา. ใช้น้ำเสียงเดียวกัน คำเดียวกัน และเครื่องหมายวรรคตอนเดียวกันตลอด
• เฉพาะเจาะจง. ถ้าคุณรู้ว่าเหตุใดจึงเกิดข้อผิดพลาด ให้พูดอย่างนั้น “อีเมลไม่ถูกต้อง” มีความคลุมเครือและเป็นภาระแก่ผู้ใช้ “อีเมลต้องมีสัญลักษณ์ 'at'” มีความชัดเจน
• เป็นมนุษย์หลีกเลี่ยงศัพท์แสง อย่าใช้คำเช่นไม่ถูกต้อง ต้องห้าม และบังคับ
• ใช้ภาษาธรรมดา. ข้อความแสดงข้อผิดพลาดไม่ใช่โอกาสในการส่งเสริมน้ำเสียงที่ตลกขบขันของแบรนด์ของคุณ
• ใช้เสียงที่ใช้งาน เมื่อข้อผิดพลาดคือคำสั่งและคุณบอกผู้ใช้ว่าต้องทำอย่างไร ตัวอย่างเช่น "ป้อนชื่อของคุณ" ไม่ใช่ "ต้องป้อนชื่อจริง"
• อย่าโทษผู้ใช้ ให้พวกเขารู้ว่ามีอะไรผิดพลาดและจะแก้ไขอย่างไร

## สรุป

ในบทนี้ เราได้แก้ไขความท้าทายด้านการออกแบบแบบฟอร์มพื้นฐานหลายประการที่นำไปใช้ได้นอกเหนือจากแบบฟอร์มการลงทะเบียนทั่วไป ในหลาย ๆ ด้าน บทนี้มีเนื้อหาเกี่ยวกับสิ่งที่ไม่ควรทำมากพอๆ กับที่มีเนื้อหาเกี่ยวกับสิ่งที่เราควรทำ การหลีกเลี่ยงรูปแบบการประหยัดพื้นที่แบบใหม่และแบบประดิษฐ์ขึ้นเพื่อมุ่งเน้นไปที่การลดจำนวนฟิลด์ที่เรารวมไว้ เราหลีกเลี่ยงความล้มเหลวในการใช้งานหลายอย่างในขณะเดียวกันก็ทำให้รูปแบบน่าพึงพอใจยิ่งขึ้นไปพร้อม ๆ กัน

### สิ่งที่ควรหลีกเลี่ยง

• การใช้แอตทริบิวต์ placeholder เป็นกลไกในการจัดเก็บป้ายกำกับและข้อความแนะนำ
• การใช้ประเภทอินพุตที่ไม่ถูกต้อง
• ปุ่มจัดแต่งทรงผมและลิงค์เหมือนกัน
• กำลังตรวจสอบฟิลด์ตามที่ผู้ใช้พิมพ์
• ปิดการใช้งานปุ่มส่ง
• การใช้ศัพท์แสงที่ซับซ้อนและไมโครสำเนาที่ได้รับอิทธิพลจากแบรนด์

และนั่นแหล่ะ หากคุณชอบบทแรกของ Form Design Patterns คุณสามารถรับหนังสือได้ทันที มีความสุขในการอ่าน!