แตะและเมาส์

พบปะกันอีกครั้งเป็นครั้งแรก

คริส วิลสัน

Paul Kinlan

เกริ่นนำ

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

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

สถานการณ์ของการสัมผัสในแพลตฟอร์มเว็บ

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

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

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

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

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

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

การรองรับเมาส์และการแตะร่วมกัน

#1 - การคลิกและแตะ - ลำดับของสรรพสิ่ง "ธรรมชาติ"

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

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

1. เริ่มการสัมผัส
2. ขยับสัมผัส
3. Touchend
4. เมาส์โอเวอร์
5. mousemove
6. เมาส์ดาวน์
7. เมาส์อัพ
8. click

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

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

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

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

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

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

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

#2: เหตุการณ์ Mousemove ไม่เริ่มทำงานด้วยการแตะ

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

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

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

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

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

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

#4: แตะ และ :วางเมาส์

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

แต่สิ่งที่น่าสนใจก็คือ CSS :hover pseudoclass สามารถทริกเกอร์โดยอินเทอร์เฟซการสัมผัสได้ในบางกรณี การแตะองค์ประกอบทำให้องค์ประกอบ :ทำงานในขณะที่วางนิ้วลง และยังได้รับสถานะ :วางเมาส์ด้วย (เมื่อใช้ 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 จะแก้ไขเหตุการณ์เมาส์ดาวน์/ย้ายเมาส์/เมาส์ ด้วยก็ตาม)

#6: เก็บเครื่องจัดการการแตะไว้ ไม่เช่นนั้นจะเลื่อนม้วนกระดาษ

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

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

#7: มัลติทัช

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

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

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

ตกแต่ง

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

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