แตะและเมาส์

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

Chris Wilson
Chris Wilson
X
Paul Kinlan

บทนำ

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

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

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

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

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

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

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

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: เหตุการณ์ Mousemove ไม่ได้เริ่มทำงานด้วยการแตะ

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

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

#3: Touchmove และ MouseMove ไม่เหมือนกัน

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

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

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

#4: การแตะและ :hover

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

แต่สิ่งที่น่าสนใจคือคลาสเทียม :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: ความแม่นยำของการแตะเทียบกับเมาส์

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

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

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

#6: Keep touch handlers contained, or they’ll jank your scroll

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

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

#7: มัลติทัช

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

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

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

กำลังปรับแต่ง

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

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