แตะและเมาส์

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

Chris Wilson
Chris Wilson
X
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 - การคลิกและแตะ - ลำดับของสิ่งต่างๆ "ธรรมชาติ"

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

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

  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 เพื่อช่วยทดสอบอินเทอร์เฟซการสัมผัสในระบบที่ไม่ใช่ระบบสัมผัส

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

Chrome สำหรับแอนดรอยด์ เบราว์เซอร์ Android Opera Mobile สำหรับ Android) Firefox สำหรับ Android Safari สำหรับ iOS
วิวพอร์ตที่ปรับขนาดไม่ได้ ไม่มีการหน่วงเวลา 300 มิลลิวินาที 300 มิลลิวินาที ไม่มีการหน่วงเวลา 300 มิลลิวินาที
ไม่มีวิวพอร์ต 300 มิลลิวินาที 300 มิลลิวินาที 300 มิลลิวินาที 300 มิลลิวินาที 300 มิลลิวินาที

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

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

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

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

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

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

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

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

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

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

#7: มัลติทัช

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

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

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

การแก้ไข

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

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