แตะและเมาส์

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

กลับมารวมตัวกันอีกครั้งเป็นครั้งแรก

Chris Wilson

Paul Kinlan

บทนำ

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

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

สถานะของ Touch ในแพลตฟอร์มเว็บ

iPhone เป็นแพลตฟอร์มยอดนิยมแพลตฟอร์มแรกที่มี API การสัมผัสเฉพาะในตัวเว็บเบราว์เซอร์ ผู้ให้บริการเบราว์เซอร์รายอื่นๆ อีกหลายรายได้สร้างอินเทอร์เฟซ API ที่คล้ายกันซึ่งสร้างขึ้นเพื่อให้ใช้งานร่วมกับการใช้งาน iOS ได้ ซึ่งตอนนี้อธิบายไว้ในข้อกําหนด"เหตุการณ์การสัมผัสเวอร์ชัน 1" Chrome และ Firefox บนเดสก์ท็อป, Safari บน iOS และ Chrome รวมถึงเบราว์เซอร์ Android บน Android รวมถึงเบราว์เซอร์อื่นๆ ในอุปกรณ์เคลื่อนที่ เช่น เบราว์เซอร์ Blackberry รองรับเหตุการณ์การสัมผัส

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

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

สำคัญที่สุด: ผู้ใช้อาจมีแท็บเล็ตและเม้าส์

นักพัฒนาซอฟต์แวร์จํานวนมากสร้างเว็บไซต์ที่ตรวจจับแบบคงที่ว่าสภาพแวดล้อมรองรับเหตุการณ์การสัมผัสหรือไม่ จากนั้นจึงคาดการณ์ว่าต้องรองรับเฉพาะเหตุการณ์การสัมผัส (ไม่ใช่เมาส์) ความเชื่อนี้ไม่ถูกต้องแล้ว การที่เหตุการณ์การแตะปรากฏขึ้นไม่ได้หมายความว่าผู้ใช้ใช้อุปกรณ์อินพุตการสัมผัสนั้นเป็นหลัก อุปกรณ์อย่าง Chromebook Pixel และแล็ปท็อป Windows 8 บางรุ่นรองรับทั้งวิธีการป้อนข้อมูลด้วยเมาส์และการสัมผัสแล้ว และอุปกรณ์อื่นๆ จะรองรับด้วยเช่นกันในอนาคตอันใกล้ ในอุปกรณ์เหล่านี้ ผู้ใช้อาจใช้ทั้งเมาส์และหน้าจอสัมผัสเพื่อโต้ตอบกับแอปพลิเคชันอย่างเป็นธรรมชาติ ดังนั้น "รองรับการสัมผัส" จึงไม่ได้หมายความว่า "ไม่จําเป็นต้องรองรับเมาส์" คุณไม่สามารถคิดว่าปัญหาคือ "ฉันต้องเขียนรูปแบบการโต้ตอบ 2 แบบและสลับใช้" แต่ต้องพิจารณาว่าทั้ง 2 รูปแบบจะทํางานร่วมกันและทำงานแยกกันได้อย่างไร ใน Chromebook Pixel ฉันใช้แทร็กแพดบ่อยครั้ง แต่ก็เอื้อมมือขึ้นไปแตะหน้าจอด้วย ในแอปพลิเคชันหรือหน้าเว็บเดียวกัน ฉันจะใช้วิธีใดก็ได้ที่รู้สึกเป็นธรรมชาติที่สุดในขณะนั้น ในทางกลับกัน ผู้ใช้แล็ปท็อปหน้าจอสัมผัสบางรายแทบจะไม่ได้ใช้หน้าจอสัมผัสเลย ดังนั้นการมีอินพุตการสัมผัสไม่ควรปิดใช้หรือขัดขวางการควบคุมด้วยเมาส์

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

การรองรับเมาส์และหน้าจอสัมผัสร่วมกัน

#1 - การคลิกและการแตะ - ลําดับ "ตามปกติ" ของสิ่งต่างๆ

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

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

1. touchstart
2. touchmove
3. touchend
4. เมาส์โอเวอร์
5. mousemove
6. mousedown
7. mouseup
8. click

ซึ่งหมายความว่าหากคุณประมวลผลเหตุการณ์การสัมผัส เช่น touchstart คุณต้องตรวจสอบว่าคุณไม่ได้ประมวลผลเหตุการณ์ mousedown และ/หรือ click ที่เกี่ยวข้องด้วย หากยกเลิกเหตุการณ์การแตะได้ (เรียกใช้ preventDefault() ภายในตัวแฮนเดิลเหตุการณ์) ระบบจะไม่สร้างเหตุการณ์เมาส์สำหรับการแตะ กฎข้อสําคัญที่สุดอย่างหนึ่งของตัวแฮนเดิลการสัมผัสคือ

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

ประการที่ 2 เมื่อผู้ใช้แตะองค์ประกอบในหน้าเว็บบนอุปกรณ์เคลื่อนที่ หน้าเว็บที่ไม่ได้ออกแบบมาเพื่อการโต้ตอบบนอุปกรณ์เคลื่อนที่จะมีความล่าช้าอย่างน้อย 300 มิลลิวินาทีระหว่างเหตุการณ์ touchstart กับการประมวลผลเหตุการณ์เมาส์ (mousedown) ทำได้โดยใช้ Chrome โดยเปิด"จําลองเหตุการณ์การสัมผัส" ในเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ Chrome เพื่อช่วยทดสอบอินเทอร์เฟซการสัมผัสในระบบที่ไม่ใช่ระบบสัมผัส

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

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

<meta name="viewport" content="width=device-width,user-scalable=no">

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

#2: เหตุการณ์การเลื่อนเมาส์ไม่ทริกเกอร์ด้วยการสัมผัส

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

โดยทั่วไปเบราว์เซอร์จะใช้การโต้ตอบที่เหมาะสมกับการโต้ตอบด้วยการสัมผัสในการควบคุม HTML โดยอัตโนมัติ เช่น การควบคุมช่วง HTML5 จะใช้งานได้เมื่อคุณใช้การโต้ตอบด้วยการสัมผัส อย่างไรก็ตาม หากคุณใช้ตัวควบคุมของคุณเอง ตัวควบคุมเหล่านั้นอาจไม่ทำงานกับการโต้ตอบแบบคลิกและลาก อันที่จริงแล้ว ไลบรารีที่ใช้กันโดยทั่วไปบางรายการ (เช่น jQueryUI) ยังไม่รองรับการโต้ตอบด้วยการสัมผัสในลักษณะนี้โดยกำเนิด (แม้ว่า jQueryUI จะมีวิธีแก้ไขแบบ Monkey Patch หลายวิธีสำหรับปัญหานี้) นี่เป็นปัญหาแรกๆ ที่เราพบเมื่ออัปเกรดแอปพลิเคชัน Web Audio Playground ให้ทำงานร่วมกับการสัมผัสได้ เนื่องจากแถบเลื่อนใช้ jQueryUI จึงใช้การโต้ตอบด้วยการคลิกและลากไม่ได้ ฉันเปลี่ยนไปใช้ตัวควบคุมช่วง HTML5 แล้วและใช้งานได้ หรือจะเพิ่มตัวแฮนเดิลการแตะเพื่ออัปเดตแถบเลื่อนก็ได้ แต่วิธีนี้มีข้อเสียอยู่อย่างหนึ่ง

#3: Touchmove และ MouseMove ไม่ใช่สิ่งเดียวกัน

ข้อผิดพลาดที่เราเห็นว่านักพัฒนาแอปบางรายพบคือแฮนเดิล touchmove และ mousemove เรียกใช้เส้นทางโค้ดเดียวกัน ลักษณะการทํางานของเหตุการณ์เหล่านี้คล้ายกันมาก แต่แตกต่างกันเล็กน้อย โดยเฉพาะอย่างยิ่งเหตุการณ์การแตะจะกําหนดเป้าหมายไปยังองค์ประกอบที่การแตะนั้นเริ่มต้นเสมอ ขณะที่เหตุการณ์เมาส์จะกําหนดเป้าหมายไปยังองค์ประกอบที่อยู่ใต้เคอร์เซอร์เมาส์ในขณะนี้ ด้วยเหตุนี้ เราจึงมีเหตุการณ์ mouseover และ mouseout แต่ไม่มีเหตุการณ์ touchover และ touchout ที่เกี่ยวข้อง มีเพียง touchend เท่านั้น

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

แน่นอนว่าคุณสามารถหลีกเลี่ยงปัญหานี้ได้โดยหลีกเลี่ยงการนำองค์ประกอบที่มี (หรือมีบรรพบุรุษที่มี) แฮนเดิลการแตะออกขณะที่การแตะทำงานอยู่ หรือคำแนะนำที่ดีที่สุดคือแทนที่จะลงทะเบียนตัวแฮนเดิล touchend/touchmove แบบคงที่ ให้รอจนกว่าจะได้รับเหตุการณ์ touchstart แล้วเพิ่มตัวแฮนเดิล touchmove/touchend/touchcancel ลงในtarget ของเหตุการณ์ touchstart (และนําออกเมื่อสิ้นสุด/ยกเลิก) วิธีนี้จะช่วยให้คุณได้รับเหตุการณ์การแตะต่อไปแม้ว่าจะมีการย้าย/นําองค์ประกอบเป้าหมายออก คุณลองเล่นกับสิ่งนี้ได้ที่นี่ - แตะกล่องสีแดงและกดแป้น Escape ค้างไว้เพื่อนำออกจาก DOM

#4: แตะและวางเมาส์เหนือ

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

แต่ที่น่าสนใจคืออินเทอร์เฟซการสัมผัสอาจทริกเกอร์คลาสจำลอง :hover ของ CSS ได้ ในบางกรณี การแตะองค์ประกอบจะทำให้องค์ประกอบนั้นอยู่ในสถานะ :active ขณะที่นิ้วกดอยู่ และรับสถานะ :hover ด้วย (ใน Internet Explorer :hover จะมีผลเฉพาะในขณะที่นิ้วของผู้ใช้วางอยู่บนแป้นพิมพ์หรือเมาส์เท่านั้น ส่วนเบราว์เซอร์อื่นๆ จะใช้ :hover จนกว่าจะมีการแตะหรือเลื่อนเมาส์ครั้งถัดไป) วิธีนี้เป็นแนวทางที่ดีในการทำให้เมนูแบบป๊อปอัปทำงานในอินเทอร์เฟซแบบสัมผัส ข้อเสียของการทำให้องค์ประกอบทำงานอยู่คือระบบจะใช้สถานะ :hover ด้วย เช่น

<style>
img ~ .content {
  display:none;
}

img:hover ~ .content {
  display:block;
}
</style>

<img src="/awesome.png">
<div class="content">This is an awesome picture of me</div>

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

วิธีข้างต้นใช้ได้กับอินเทอร์เฟซที่ใช้เคอร์เซอร์เมาส์ รวมถึงอินเทอร์เฟซแบบสัมผัส ซึ่งแตกต่างจากการใช้แอตทริบิวต์ "title" เมื่อวางเมาส์เหนือ ซึ่งจะไม่แสดงเมื่อเปิดใช้งานองค์ประกอบ

<img src="/awesome.png" title="this doesn't show up in touch">

#5: ความแม่นยำของหน้าจอสัมผัสเทียบกับเมาส์

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

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

ผู้ให้บริการเบราว์เซอร์จํานวนมากที่จัดการอินเทอร์เฟซแบบสัมผัสได้นําตรรกะมาไว้ในเบราว์เซอร์เพื่อช่วยกําหนดเป้าหมายองค์ประกอบที่ถูกต้องเมื่อผู้ใช้สัมผัสหน้าจอและลดโอกาสที่การคลิกจะไม่ถูกต้องด้วย แม้ว่าโดยปกติแล้วการแก้ไขนี้จะแก้ไขเฉพาะเหตุการณ์การคลิก ไม่ใช่การเคลื่อนไหว (แม้ว่า Internet Explorer จะแก้ไขเหตุการณ์ mousedown/mousemove/mouseup ด้วยก็ตาม)

#6: ควบคุมตัวแฮนเดิลการแตะให้อยู่ภายในขอบเขต ไม่เช่นนั้นการเลื่อนจะกระตุก

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

คำแนะนำหนึ่งที่ควรทำเพื่อหลีกเลี่ยงปัญหานี้คือการยืนยันว่าหากคุณจัดการเหตุการณ์การแตะเฉพาะในส่วนเล็กๆ ของ UI ให้แนบตัวแฮนเดิลการแตะไว้ในส่วนนั้นเท่านั้น (ไม่ใช่ใน <body> ของหน้าเว็บ) กล่าวโดยย่อคือ จำกัดขอบเขตของตัวแฮนเดิลการแตะให้มากที่สุด

#7: มัลติทัช

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

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

W3C Touch API ที่ใช้งานอยู่ในปัจจุบันไม่มี API เพื่อระบุจํานวนจุดสัมผัสที่ฮาร์ดแวร์รองรับ คุณจึงต้องใช้การประมาณที่ดีที่สุดเกี่ยวกับจํานวนจุดสัมผัสที่ผู้ใช้ต้องการ หรืออาจสังเกตจํานวนจุดสัมผัสที่เห็นในทางปฏิบัติและปรับให้เหมาะสม ตัวอย่างเช่น ในแอปพลิเคชันเปียโน หากไม่เคยเห็นจุดสัมผัสมากกว่า 2 จุด คุณอาจต้องเพิ่ม UI "คอร์ด" PointerEvents API มี API ในการระบุความสามารถของอุปกรณ์

การทัชอัป

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

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