แตะและเมาส์

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

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 - การคลิกและการแตะ - ลําดับ "ตามปกติ" ของสิ่งต่างๆ

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

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

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 การควบคุมดังกล่าวอาจไม่ทํางานกับอุปกรณ์ที่มีการสัมผัส เว้นแต่คุณจะเพิ่มตัวแฮนเดิลการแตะโดยเฉพาะด้วย

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