การแก้ไขข้อความบนมือถือ: ปัญหาที่มองไม่เห็น

 (jenson.org)
2 คะแนน โดย GN⁺ 2023-09-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การแก้ไขข้อความบน Android และ iOS ยืมธรรมเนียมจากเดสก์ท็อปมาใช้ แต่บนมือถือไม่มี ตัวชี้ที่แม่นยำ และแถบเมนู ทำให้การแตะครั้งเดียวต้องรับบททั้งการวางเคอร์เซอร์ การเลือก และการเรียกเมนู
  • แก่นของปัญหาไม่ใช่การป้อนข้อความ แต่คือการแก้ไข โดยในการศึกษาผู้ใช้ 10 คน ผู้เข้าร่วมทุกคนประสบปัญหาการเล็งตำแหน่ง การใช้คลิปบอร์ด และความผิดพลาดซ้ำๆ
  • text handle, แว่นขยาย, double-tap·long-press และเมนูป๊อปอัป ต่างก็เป็นวิธีชดเชยที่สมเหตุสมผลในตัวเอง แต่ยิ่งใช้ร่วมกันมากเท่าไร ความกำกวมในการตีความการแตะก็ยิ่งเพิ่มขึ้น
  • ต้นแบบ Eloquent ตีความการแตะเป็นการวางเคอร์เซอร์เสมอ และทำให้โฟลว์การแก้ไขง่ายขึ้นด้วยการย้ายแบบยึดการลากเป็นศูนย์กลาง แว่นขยายแบบรวมศูนย์ การเลือกด้วย Drag Press และเมนูแบบปัด
  • อุปสรรคของการปรับปรุงอยู่ใกล้กับเรื่องการนำไปใช้และลำดับความสำคัญขององค์กรมากกว่าเรื่องเทคนิค และหากต้องการยกระดับผลิตภาพบนมือถือ ก็จำเป็นต้องมีโมเดลการแก้ไขที่เหมาะกับการสัมผัส มากกว่าการแฮ็กเลียนแบบเดสก์ท็อป

ทำไมปัญหาการแก้ไขข้อความบนมือถือถึงไม่ค่อยถูกมองเห็น

  • Android และ iOS นำวิธีแก้ไขข้อความแบบเดสก์ท็อปมาใช้บนมือถือ แต่บนมือถือไม่มี เมาส์พอยน์เตอร์ที่แม่นยำ และ แถบเมนู/ปุ่มคำสั่ง
  • ผลคือ gesture การแตะเพียงอย่างเดียวต้องแบกรับหลายหน้าที่
    • วางเคอร์เซอร์
    • ย้ายเคอร์เซอร์
    • เลือกข้อความ
    • เรียกเมนูป๊อปอัป
  • ในข้อความสั้นๆ หรือคอมเมนต์บนโซเชียลมีเดีย ปัญหาอาจเห็นไม่ชัดนัก แต่เมื่อแก้ไขข้อความยาวอย่างอีเมลหลายประโยค กระบวนการแก้ไขจะน่าเบื่อและเกิดข้อผิดพลาดมาก

ความล้มเหลวของการแก้ไขที่เผยให้เห็นจากงานวิจัยผู้ใช้ปี 2017

  • ระหว่างทำงานกับ Android ในปี 2017 ผู้เขียนพยายามหางานวิจัยผู้ใช้เดิมเกี่ยวกับการแก้ไขข้อความบนมือถือ แต่แม้จะไล่ดูงานวิจัยย้อนหลัง 7 ปีก็ไม่พบงานที่เกี่ยวข้อง
  • ให้ผู้เข้าร่วม 10 คนทำ งานแก้ไขข้อความ ง่ายๆ เช่น ลบตัวอักษรหนึ่งตัว หรือย้ายคำไปไว้ท้ายประโยค
  • ผู้เข้าร่วมทุกคนพบความยากลำบากร่วมกัน
    • แตะตำแหน่งที่ต้องการได้อย่างแม่นยำยาก
    • การใช้คลิปบอร์ดทำได้ลำบาก
    • เกิดข้อผิดพลาดซ้ำๆ มาก
  • ผู้เข้าร่วมแสดงความหงุดหงิดกับข้อความที่ซับซ้อน เช่น อีเมลหลายประโยค มากกว่าในแอปแชตหรือโซเชียล
  • มากกว่าครึ่งตอบว่าการ เลือกทั้งหมด ลบ แล้วพิมพ์ใหม่ ง่ายกว่าการแก้ไขข้อความเดิม
  • จุดสำคัญของปัญหาอยู่ที่การแก้ไข ไม่ใช่การป้อนข้อความ
    • ด้วยคีย์บอร์ด การถอดเสียงพูด และคีย์บอร์ดจริงบนแท็บเล็ต การป้อนข้อความดีขึ้นกว่าในอดีต
    • แต่กระบวนการกลับมาแก้ประโยคที่พิมพ์ไปแล้วก็ยังจำเป็นอยู่เสมอ
  • งานวิจัยเน้นที่การปรับปรุง Android แต่ iOS ก็มีปัญหาประเภทเดียวกันจำนวนมาก แม้รายละเอียดพฤติกรรมจะแตกต่างกัน

มือถือเก่งเรื่องการเสพคอนเทนต์ แต่เปราะบางเรื่องการแก้ไข

  • อุปกรณ์พกพามีจุดแข็งด้าน การเสพคอนเทนต์ระหว่างเดินทาง เช่น วิดีโอ รูปภาพ โซเชียลมีเดีย และการส่งข้อความ
  • iPhone รุ่นแรกเริ่มยังไม่รองรับคลิปบอร์ดด้วยซ้ำ
  • ความคาดหวังว่าแท็บเล็ตจะมาแทนเดสก์ท็อปถูกพูดถึงซ้ำๆ แต่ในฐานะตัวแทนเดสก์ท็อปก็ไม่เคยประสบความสำเร็จมากนัก
    • Apple เคยออกโฆษณา “What’s a computer?”
    • Google เคยลองแคมเปญ “Tablet Tuesdays” ในปี 2013 เพื่อให้พนักงานใช้แท็บเล็ตตลอดทั้งวัน
  • ปัญหา UX เชิงลึกที่ขวางผลิตภาพบนแท็บเล็ต ได้แก่ การแก้ไขข้อความและการจัดการไฟล์
  • เป้าหมายไม่ใช่การกลับไปใช้เดสก์ท็อป แต่คือการพัฒนามือถือให้เร็วและทำงานได้มีประสิทธิภาพเทียบเท่าเดสก์ท็อป

จุดอ้างอิงของการแก้ไขข้อความบนเดสก์ท็อป

  • หลังปี 2000 เป็นต้นมา การแก้ไขข้อความบนเดสก์ท็อปมีโครงสร้างที่ค่อนข้างเสถียร
  • องค์ประกอบพื้นฐานของเดสก์ท็อปมี 3 อย่าง
    • ตัวชี้ที่แม่นยำ ที่ควบคุมด้วยเมาส์หรือแทร็กแพด
    • การเลือกข้อความที่เรียบง่ายผ่านการคลิกแล้วลาก
    • เมนู Edit ที่มี Cut/Copy/Paste และปุ่มคำสั่ง X/C/V
  • ชุดองค์ประกอบนี้ทำให้การแก้ไขข้อความเป็นงานที่มีความผิดพลาดน้อยและกำกวมน้อยพอสมควร
  • แม้จะไม่สมบูรณ์แบบ แต่ก็เป็นเส้นฐานสำหรับเทียบกับการแก้ไขข้อความบนมือถือ

วิธีชดเชย 4 แบบที่เกิดขึ้นเมื่อนำแนวทางเดสก์ท็อปมาปรับใช้กับมือถือ

  • 1. text handle

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

  • 2. แว่นขยาย

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

  • 3. การเลือกข้อความ

    • บนเดสก์ท็อป การกดคลิกค้างแล้วลากนำไปสู่การเลือกข้อความอย่างเป็นธรรมชาติ
    • บนมือถือ วิธีเดียวกันทำได้ยาก จึงเพิ่ม double-tap และ long-press เป็น gesture สำหรับการเลือก
    • การตีความ double-tap ต้องรอว่าการแตะครั้งที่สองจะมาหรือไม่ จึงอาจทำให้การตอบสนองของการแตะครั้งเดียวล่าช้า
    • หากต้องการเลือกมากกว่าหนึ่งคำ ต้องเลือกคำก่อน แล้วลาก handle ที่ปลายทั้งสองด้าน

  • 4. เมนูป๊อปอัป

    • มือถือไม่มีแถบเมนู จึงต้องมีวิธีอื่นในการเรียกคำสั่งคลิปบอร์ด
    • เมื่อเลือกข้อความ เมนูจะปรากฏเหนือช่วงที่เลือก ซึ่งทำงานได้ค่อนข้างดีสำหรับการตัด/คัดลอก
    • แต่การวางมักไม่ได้เริ่มจากการเลือกข้อความ จึงถูกซ่อนไว้มากกว่า
    • การเปิดเมนูเดียวกันต้องแตะ text handle ดังนั้นผู้ใช้ต้องเรียนรู้สอง gesture ที่ต่างกัน
    • บน Android หากไม่มีการป้อนข้อมูลเป็นเวลา 4 วินาที text handle จะหายไป
      • เพราะ handle บดบังข้อความด้านล่างเล็กน้อย
      • หากต้องการเปิดเมนู ผู้ใช้ต้องแตะอีกครั้งเพื่อให้ handle กลับมา และแตะที่ handle อีกครั้ง
    • บนมือถือไม่มีปุ่มคำสั่งที่เทียบเท่ากับการตัด/คัดลอก/วาง ทำให้ทั้งมือใหม่และผู้ใช้ชำนาญต้องใช้วิธีผ่านเมนูแบบเดียวกัน

โครงสร้างที่ทำให้การแตะครั้งเดียวถูกเข้าใจได้หลายความหมาย

  • การแก้ไขข้อความบนมือถือสร้างความเป็นไปได้ในการตีความการแตะหลายแบบ ระหว่างกระบวนการยัดฟังก์ชันเดสก์ท็อปมาไว้บนมือถือ
  • เมื่อผู้ใช้แตะหนึ่งครั้ง ระบบอาจตีความเป็นอย่างใดอย่างหนึ่งต่อไปนี้
    • วางเคอร์เซอร์
    • เรียกเมนูเมื่อมีเคอร์เซอร์อยู่แล้ว
    • เริ่มการลาก
    • เริ่ม double-tap
    • เริ่ม long-press
  • แม้จะสามารถแยกแต่ละอย่างได้หากใช้อย่างระมัดระวัง แต่ตัวโครงสร้างเองก็เปราะบาง
  • ข้อผิดพลาดที่ปรากฏในการทดสอบผู้ใช้มีดังนี้
    • พลาดตำแหน่งที่ต้องการเพราะ ปัญหานิ้วอ้วน
    • แตะข้างๆ เพื่อแก้เคอร์เซอร์ แต่กลับไปโดน handle จนเมนูเด้งขึ้นมา
    • แทนที่จะเป็นเมนู กลับถูกตีความเป็นการลากเล็กน้อยมากจนเหมือนไม่มีอะไรเกิดขึ้น
    • พยายามทำ double-tap แต่ไปแตะข้างๆ หรือโดน handle จนไม่เกิดอะไรขึ้น
    • หากต้องการวางในช่องว่าง ต้องแตะช่องว่างก่อนเพื่อสร้างเคอร์เซอร์ แล้วแตะเคอร์เซอร์อีกครั้งเพื่อเรียกเมนู
    • หลังวางเคอร์เซอร์แล้วเผลอหันสายตาไปชั่วครู่ handle ก็หายไป ทำให้ผู้ใช้สับสน
  • ในการศึกษากับผู้ใช้ 10 คน ต้องใช้ความพยายามเฉลี่ย 5 ครั้งเพื่อวางเคอร์เซอร์ให้ตรงตำแหน่ง และมีผู้ใช้หนึ่งคนแตะถึง 19 ครั้ง
  • ความฝืดและข้อผิดพลาดเหล่านี้อธิบายได้ว่าทำไมผู้ใช้จำนวนมากจึงเลือกพิมพ์ใหม่ทั้งหมดแทนการแก้ไขจริง

ข้อจำกัดของฟีเจอร์ชดเชยที่มีอยู่

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

แนวทางของต้นแบบ Eloquent

  • ผู้เขียนสร้างต้นแบบ Eloquent ร่วมกับ Olivier Bau และงานนี้ถูกนำเสนอที่ UIST 2021
  • Eloquent เป็นความพยายามที่จะจัดการปัญหาการใช้การแตะ การเลือก แว่นขยาย และเมนูที่ชนกันไปพร้อมกัน

  • การวางเคอร์เซอร์แบบเรียบง่าย

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

  • แว่นขยายแบบรวมศูนย์

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

  • การเลือกข้อความด้วย Drag Press

    • ความกำกวมของการแก้ไขบนมือถือในปัจจุบันเกิดจากการยัดหลายฟังก์ชันไว้ใน gesture แตะครั้งเดียว
    • Eloquent เริ่มการเลือกข้อความด้วย gesture Drag Press ซึ่งคือการกดแรงขึ้นระหว่างลาก
    • ใช้เซ็นเซอร์ความกดอากาศของโทรศัพท์ที่มีอยู่ในฮาร์ดแวร์ขณะนั้นเพื่อตรวจจับแรงกด
      • รักษาค่าอ้างอิงด้วยค่าเฉลี่ยเคลื่อนที่ระยะยาว
      • หากค่าเฉลี่ยเคลื่อนที่ระยะสั้นสูงกว่าค่าเฉลี่ยระยะยาว ก็จะเกิดเหตุการณ์ drag-press
      • แม้ค่าจากเซ็นเซอร์จะผันผวนพอสมควร แต่การทำงานก็ยังทนทานมาก
    • กลไกที่ล้ำหน้ากว่าอย่าง 3D Touch hardware ของ Apple ที่ยุติไปแล้ว อาจเป็นทางออกที่ดีกว่า
    • Drag Press จะเลือกทั้งคำที่อยู่ด้านล่าง ดังนั้นการสั่นเล็กน้อยตอนกดจึงไม่กลายเป็นความผิดพลาดในการเล็งเป้าหมายครั้งใหญ่

  • เมนูที่ปรับปรุงใหม่

    • Eloquent ต้องการให้ผู้ใช้ชำนาญทำงานคลิปบอร์ดอย่างคัดลอก/วางได้เร็วขึ้น
    • เมนูข้อความปัจจุบันของ Android และ iOS ส่วนใหญ่เป็นแบบลำดับชั้น จึงพยายามทำให้เมนูแบนลง
    • ในการทดสอบผู้ใช้ ผู้เข้าร่วมทุกคนหาเมนูนี้เจอได้ง่ายและชอบใช้งานมัน
    • หลังเริ่มการเลือกด้วย Drag Press แล้ว สามารถใช้ Drag Press ครั้งที่สองเพื่อเปิดเมนู ทำให้การเล็งเป้า การเลือก และการเรียกเมนูถูกจัดไว้ในโฟลว์เดียว
    • สำหรับผู้ใช้ชำนาญ สามารถใช้ gesture flick แบบรวดเร็วเพื่อสั่งรายการเมนูได้
    • T-Menu ของ Eloquent ใช้ gesture ปัดสำหรับการตัดและวาง และเลื่อนหลุดออกนอกหน้าจอโดยไม่มีลำดับชั้น

  • แอนิเมชันแบบเกม

    • Eloquent เพิ่มแอนิเมชันภาพเล็กๆ เพื่อช่วยให้ผู้ใช้เรียนรู้และเข้าใจการเปลี่ยนสถานะ
    • เคอร์เซอร์จะ “scoot” ระหว่างตำแหน่งต่างๆ และเมื่อถึงที่แล้ว handle จะ “wobble”
    • การเคลื่อนไหวเหล่านี้ช่วยตอกย้ำความรู้สึกว่าเคอร์เซอร์มีอยู่เสมอและลากได้ทุกเมื่อ
    • เมื่อแตะ เคอร์เซอร์จะ “dimple” และเรียกแว่นขยายขึ้นมาชั่วครู่ เพื่อชักชวนให้ผู้ใช้ลองลากมากกว่าการแตะแบบง่ายๆ
    • หาก Force Press เกิดขึ้นเหนือคำ ไฮไลต์จะ “inflate”
    • gesture เมนูแบบปัดจะทำให้ช่วงข้อความที่เลือกเกิดแอนิเมชันไปตามทิศทางการปัด
      • ปัดขึ้นเพื่อตัด ช่วงที่เลือกจะหายขึ้นด้านบน
      • ปัดลงเพื่อวาง ช่วงที่เลือกใหม่จะตกลงมาด้านล่าง

  • ความเข้ากันได้สำหรับผู้ใช้เดิม

    • Eloquent พยายามคง gesture ปัจจุบันไว้ให้มากที่สุด เพื่อสร้างความต่อเนื่องกับพฤติกรรมเดิม
    • หากตีความการแตะและลากทั้งหมดเป็นการลากเคอร์เซอร์เสมอ จะเกิดปัญหาในช่องข้อความแนวตั้งยาวที่ต้องเลื่อนมากๆ
    • หากช่วงพิกเซลแรกของการเริ่มลากเป็นแนวตั้ง ก็จะตีความเป็นการเลื่อนแนวตั้งตามปกติ
    • นอกเหนือจากนั้น การลากจะถูกตีความเป็นการวางเคอร์เซอร์และการลากเคอร์เซอร์

ทำไมจึงยากที่จะปล่อยใช้งานจริง

  • การเปลี่ยนแปลงแบบ Eloquent ปล่อยใช้งานจริงได้ยาก
  • หลายคนมองการแก้ไขข้อความผิดไปว่าเป็นปัญหาที่ “แก้เสร็จแล้ว” จึงมีแรงจูงใจน้อยในการปรับปรุง
  • ผู้ใช้ปรับตัวเข้ากับวิธีปัจจุบันที่ผิดพลาดสูงมานานกว่าสิบปีแล้ว จึงยากที่จะเรียกร้องให้เปลี่ยนตอนนี้
  • ในการแข่งขันระหว่าง Android และ iOS การปรับปรุงการแก้ไขข้อความไม่ถูกมองว่าเป็นฟีเจอร์หวือหวาที่ขยับ Net Promoter Score ได้
  • การเปลี่ยนแปลงพื้นฐานอย่างการแก้ไขข้อความอาจทำให้ผู้ใช้ใช้โทรศัพท์ได้สบายขึ้น แต่ผลลัพธ์จะปรากฏช้าและต้องอาศัยความพยายามต่อเนื่องหลายปี
  • อุปสรรคนี้ใกล้เคียงกับปัญหาทางการเมืองมากกว่าปัญหาทางเทคนิค
  • หากแนวโน้มยังเป็นแบบปัจจุบัน ก็เป็นไปได้ว่าเราจะยังแก้ไขข้อความบนมือถือด้วยวิธีเดิมไปอีกอย่างน้อย 20 ปี

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-25
ความคิดเห็นจาก Hacker News

  • บนมือถือ เรามักเขียน ข้อความสั้น ๆ ที่ใช้เวลานานกว่าแต่ผิดพลาดมากกว่า ดังนั้นจึงพยายามเลี่ยงสถานการณ์ที่ต้องพิมพ์บนมือถือ และถ้าเปิดโน้ตบุ๊กอยู่ ก็ใช้ WhatsApp หรือ Signal จากตรงนั้นด้วย
    ถ้าต้องใช้คีย์บอร์ดมือถือ ก็ต้องยอมรับไปเลยว่าจะมีพิมพ์ผิด ละตัวพิมพ์ใหญ่ หรือละคำที่ไม่จำเป็น โทรศัพท์ส่วนใหญ่ไม่ใช่อุปกรณ์สำหรับป้อนข้อความยาว ๆ แต่ใกล้เคียงกับอุปกรณ์สำหรับเสพข่าว/สื่อและถ่ายรูปมากกว่า
    แค่เห็นว่าเคสคีย์บอร์ดบน iPad ยังเป็นที่นิยม ก็ชี้ให้เห็นข้อจำกัดของคีย์บอร์ดสัมผัสแล้ว iPad ยังมีคีย์บอร์ดกับสไตลัสให้เลือกบ้าง แต่ iPhone แทบไม่มีตัวเลือกแบบนั้น และคิดถึงโทรศัพท์ที่มี คีย์บอร์ดฮาร์ดแวร์ ดี ๆ แบบ Nokia หรือ BlackBerry สมัยก่อน

    • สำหรับโทรศัพท์ยุคนี้ ด้วย การป้อนแบบปัดนิ้ว ทำให้พิมพ์บน iPhone หรือ Android ได้ง่ายกว่าบน iPad มาก แม้จะไม่ได้มีประสิทธิภาพเท่าคนชำนาญพิมพ์บนคีย์บอร์ดจริง แต่หลายครั้งก็เร็วพอจนไม่จำเป็นต้องหยิบโน้ตบุ๊กออกมา
      สุดท้าย iPad แย่กว่า เพราะต้องกดคีย์บอร์ดสัมผัส QWERTY ที่ไม่ดีทีละตัวอักษร ถ้ามีผังแป้นพิมพ์ที่เหมาะกับการปัดนิ้วก็คงดี และเคยมีบทความที่คำนวณผังซึ่งพยายามวางสระให้ห่างกันมากที่สุดด้วย: https://sangaline.com/post/finding-an-optimal-keyboard-layou...
    • ถ้าพูดถึง iPhone ก็ยากจะเข้าใจว่าทำไม การป้อนด้วยการรู้จำเสียงพูด ถึงแย่ขนาดนี้ การใส่ข้อความด้วยการพูดเองทำได้ค่อนข้างดี แต่พอลบหรือแก้คำที่ผิดทันทีไม่ได้ สุดท้ายก็ต้องใช้มือแตะเพื่อแก้ไขอยู่ดี
      ถ้าจะใส่ข้อความระหว่างขับรถ ตราบใดที่มันถอดคำพูดได้ไม่สมบูรณ์แบบตั้งแต่ครั้งแรก ก็ต้องใช้มือ จึงเหมือนเกือบจะดีแล้ว แต่พังเพราะ UI สำหรับแก้ไข
    • คิดถึงยุคที่มี การป้อนแบบ T9 และปุ่มจริง เราสัมผัสปุ่มด้วยปลายนิ้วและพิมพ์ข้อความมือเดียวระหว่างเดินได้ และผลลัพธ์ก็คาดเดาได้มากกว่าระบบข้อความคาดเดา
      ทุกวันนี้จะพิมพ์บนจอสัมผัสก็ต่อเมื่อเลี่ยงไม่ได้จริง ๆ และแม้ใช้โน้ตบุ๊กไม่ได้ ถ้านั่งได้ก็มักจะวางโทรศัพท์บนขาตั้งแล้วใช้คีย์บอร์ด Bluetooth แบบพับได้ขนาดเล็ก
    • ช่วงที่ใช้โทรศัพท์ที่มีคีย์บอร์ดจริงได้ดีกว่ามาก ความแม่นยำของการป้อนแบบปัดนิ้วบน Android เพิ่งจะเริ่มเข้าใกล้ความเร็วของการพิมพ์ด้วยคีย์บอร์ดจริงเมื่อไม่นานมานี้ แต่ความแม่นยำยังตามไม่ทัน
      อุตสาหกรรมสมาร์ตโฟนทั้งหมดค่อย ๆ กลายเป็นแบบ iPhone ทำให้เราสูญเสียตัวเลือกแบบนั้นไป
    • เรื่องนี้ค่อนข้างย้อนแย้ง เดิมทีในคีย์โน้ตเปิดตัว iPhone Steve Jobs ชี้ว่า คีย์บอร์ดจริง เป็นประสบการณ์ผู้ใช้ที่ไม่ดี และข้อดีของ iPhone คือทั้งอุปกรณ์สามารถเปลี่ยนไปตามแอปที่ใช้อยู่ได้
      ถึงอย่างนั้นก็เห็นด้วยว่า การพิมพ์บน iOS ยังปรับปรุงได้: https://youtu.be/x7qPAY9JqE4?si=9_jnM2Ys8JiTXGqC

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

    • ผมสงสัยว่าวิธีอย่าง เคอร์เซอร์ออฟเซ็ตคงที่ ที่มีตัวชี้จริงอยู่เหนือจุดสัมผัสของนิ้ว 1 ซม. จะเป็นอย่างไร การขยับนิ้วใช้ควบคุมตำแหน่ง และใช้ระยะเวลาที่กดค้างเพื่อเปิดโหมดอื่น ๆ
      มีการใช้งานแบบที่ทำให้จอสัมผัสเป็นเหมือนทัชแพดจริง ๆ เช่น วิธีที่ TeamViewer จัดการเซสชันรีโมตเดสก์ท็อป Windows บนสมาร์ตโฟน ถ้า Android เองมีเป็นโหมดที่เปิด/ปิดได้ก็คงดี และการเลือกข้อความด้วยนิ้วที่เป็นข้ออักเสบนั้นเจ็บปวดตามตัวอักษรจริง ๆ
    • การเปรียบว่าสมาร์ตโฟนเป็นเมาส์ปุ่มเดียวไม่ได้ถูกต้องทั้งหมด จอสัมผัสสามารถตรวจจับหลายนิ้วและหลายเจสเจอร์ได้
      ปัญหาคือศักยภาพนั้นแทบไม่ถูกใช้เลย นอกจาก pinch เพื่อซูมและการเลื่อนด้วยสองนิ้ว
    • 3D Touch แก้ปัญหาบางส่วนของอินเทอร์เฟซสัมผัสได้ แต่น่าเสียดายที่ Apple ตัดมันทิ้งไป แปลกที่มันยังอยู่ใน Magic Trackpad
    • โทรศัพท์ Android รุ่นแรก ๆ บางรุ่นมี แทร็กแพดแบบออปติคัล ใต้หน้าจอ บางอันก็แย่ แต่ตัวที่ดีสามารถเลื่อนเคอร์เซอร์ได้แม่นยำกว่าจอสัมผัสมาก
      มันเป็นฟีเจอร์ที่ดีมากสำหรับการแก้ไขข้อความ เลยอยากให้ยังคงอยู่
    • จอสัมผัสไม่สามารถกลายเป็นคีย์บอร์ดได้ แต่ก็ไม่ได้หมายความว่ามันจะดีขึ้นกว่าตอนนี้ไม่ได้

  • บางครั้งก็คิดว่า เวลาอ่านหรือแก้ไขข้อความยาว ๆ บนอุปกรณ์จอสัมผัส การแก้ไขแบบโมดัลสไตล์ Vim อาจเป็นแนวทางที่ดีหรือไม่
    การย้ายวิธีใช้คีย์บอร์ด·เมาส์มาไว้บนอุปกรณ์จอสัมผัสตรง ๆ ดูเหมือนเป็นโอกาสที่พลาดไป แม้แต่เลย์เอาต์คีย์บอร์ดเองก็ไม่ได้มีข้อดีมากนักสำหรับการใช้นิ้วโป้งสองข้างแตะหน้าจอ
    แนวทางที่พึ่งพาการอนุมานจากตัวอักษรอย่างมาก พร้อมกับปรับอินเทอร์เฟซให้เข้ากับการป้อนข้อมูลด้วยมือเดียวหรือนิ้วเดียวก็น่าสนใจ Dasher เป็นตัวอย่างของแนวทางนี้: https://www.inference.org.uk/dasher/dashersummary.html
    https://en.m.wikipedia.org/wiki/Dasher_(software)

    • บน iPhone ถ้ากดแป้นเว้นวรรคค้างไว้ คีย์บอร์ดทั้งแผงจะกลายเป็น แทร็กแพด แบบหนึ่งให้เลื่อนเคอร์เซอร์ได้
      ถ้าเป็นโหมดที่ตัวอักษรบนปุ่มหายไปแล้ว การเพิ่มฟังก์ชันให้ทำงานเหมือนปุ่มเมาส์เพื่อรองรับการเลือกข้อความหรือวางลงตำแหน่งเฉพาะก็ดูไม่เกินไปนัก ตอนนี้การเลือกข้อความน่าหงุดหงิดเกินไป
    • ผมใช้ nvim ของ Termux บนโทรศัพท์พับได้อยู่ เพื่อให้เข้าถึงสัญลักษณ์พิเศษได้เร็วขึ้นเลยใช้ Unexpected Keyboard เป็นคีย์บอร์ด ซึ่งใช้งานได้ค่อนข้างดี
      ดีพอสำหรับเขียนโปรแกรมระหว่างเดินทาง
    • ใน Gboard มี หน้าแบบโมดัล อยู่แล้ว เช่น แป้นตัวเลข อีโมจิ และอักขระพิเศษ
      ถ้าเพิ่มอีกหน้าสำหรับแก้ไขเคอร์เซอร์ โดยมีปุ่มลูกศร, Ctrl+ลูกศร, Home/End, Page Up/Down, สลับโหมดเลือก, Delete และเมนูคลิกขวา ก็น่าจะเป็นธรรมชาติ มันก็แค่เอาส่วนที่เหลือของคีย์บอร์ดเดสก์ท็อปมาไว้บนคีย์บอร์ดมือถือ จึงยังไม่ถึงขั้นเป็นนวัตกรรม
    • ถ้าติดตั้ง Blink Shell, Panic Prompt หรือไคลเอนต์ SSH บน iPhone ที่กำลังนิยมในช่วงนั้น ๆ แล้ว SSH เข้าเดสก์ท็อป ก็จะพอเห็นล่วงหน้าได้ว่าวิธีแบบนี้ทำงานอย่างไร
      ถ้าใช้คู่กับคีย์บอร์ด Bluetooth ก็ใช้ได้ดี แค่หน้าจอเล็กไปหน่อย งานสั้น ๆ พอไหว แต่ถ้าเป็นเซสชันยาว ๆ ก็อดกังวลเรื่องสุขภาพตาไม่ได้
    • การแก้ไขแบบโมดัลมี ภาระทางความคิด สูงเกินไปสำหรับผู้ใช้สมาร์ตโฟนทั่วไป

  • ปัญหานี้ อย่างน้อยสำหรับผม ไม่ใช่ปัญหาที่มองไม่เห็นเลย ไม่กี่เดือนก่อนก็เคยยกการแก้ไขข้อความเป็นตัวอย่างว่า iOS ยังไม่พร้อมสำหรับ การใช้งานทำงาน
    การสร้างและแก้ไขข้อความเป็นหัวใจของการใช้งานเพื่อทำงาน ไม่ใช่การบริโภคคอนเทนต์ ดังนั้น Apple ควรยอมรับปัญหาแล้วแก้ไข หรือยอมรับว่าแก้ไม่ได้และไม่ควรผลักดันเรื่องเล่าแบบนั้น
    การที่ Apple เปิดตัว 3D Touch โดยไม่มีกรณีใช้งานที่มีน้ำหนัก แล้วหลายปีต่อมาก็ยังหาไม่เจอจนต้องเลิกไป ก็เป็นสัญลักษณ์ที่ชัดเจน
    Tablet Tuesdays ของ Google ก็น่าสนใจ แต่ถ้าใช้แท็บเล็ตแค่หนึ่งวันต่อสัปดาห์ ก็อาจพอทนปัญหาแล้วผ่านไปได้ ควรเป็น Tablet Teams ที่ทั้งทีมใช้แต่แท็บเล็ตมากกว่า ปัญหาถึงจะไม่ถูกซ่อนไว้
    Eloquent ดูเหมือนเป็นหลักฐานเชิงมีอยู่จริงว่าวิธีที่ดีกว่านั้นเป็นไปได้ การทดลองแก้ปัญหาคัดลอก·วางหรือการเลือกข้อความด้วยเจสเจอร์มัลติทัชก็น่าลอง

    • คอมเมนต์ที่หาอยู่คืออันนี้หรือเปล่า? <https://news.ycombinator.com/item?id=36536203>
    • พนักงานใช้งาน Gmail หรือ Google Docs จริง และมันสำคัญอย่างยิ่งต่อ productivity
      ในทางกลับกัน ผลิตภัณฑ์โซเชียลอย่าง Google+ แม้จะมีพนักงานบางส่วนใช้อยู่ แต่ก็คงไม่มาก และไม่ได้ต้องการฟังก์ชันแบบเดียวกับผู้ใช้ภายนอก ต่อให้มีเสียงบ่นภายใน มันก็ไม่ใช่หัวใจของงาน จึงยากที่จะได้ feedback loop แบบเดียวกัน
    • คำว่า “มองไม่เห็น” ในชื่อเรื่องอาจเป็นการเล่นคำจากการที่เคอร์เซอร์และเมนูถูกบังหรือมองเห็นยากในสถานการณ์ที่เป็นปัญหา

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

    • ไม่รู้บน iPhone เป็นอย่างไร แต่บน Android การวางข้อความระหว่างคำสองคำแทบเป็นไปไม่ได้เลย มันไม่ได้วางที่ตำแหน่งเคอร์เซอร์ แต่เหมือนแทนที่ข้อความที่เลือกด้วยข้อความที่วาง
      นี่คือปัญหาใหญ่ที่สุด และก็เข้าใจยากว่าทำไมคีย์บอร์ดมือถือถึงไม่มี ปุ่มคัดลอก/วาง
    • บน iOS สามารถกดแป้นเว้นวรรคค้างไว้เพื่อใช้เหมือนแทร็กแพดได้ และแตะที่อื่นเพื่อเลือกก็ได้
      แม้จะดูเก้ ๆ กัง ๆ แต่ก็ใช้งานได้
    • การแก้ไข URL นั้นทรมานจริง ๆ ถ้าจัดการ URL ใน ตัวแก้ไขหลายบรรทัด ได้ก็คงดี

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

    • ถ้ากดแป้นเว้นวรรคค้างไว้ บน Android ก็สามารถเลื่อนเคอร์เซอร์ไปยังตำแหน่งที่ต้องการได้เหมือนกัน น่าแปลกที่มีคนจำนวนมากไม่รู้ฟีเจอร์นี้
    • สิ่งที่ดีในระบบเลือกข้อความของ N9 คือเวลาลากเคอร์เซอร์ จะมี ฟีดแบ็กแฮปติกเป็นจังหวะติ๊ก ๆ ทุกครั้งที่ผ่านตัวอักษรหนึ่งตัว
      อธิบายได้ไม่หมดว่าทำไมมันถึงช่วยได้มาก แต่ทำให้จัดเคอร์เซอร์ให้ตรงตำแหน่งที่ต้องการได้ง่ายกว่ามาก
    • เมื่อก่อนสามารถย้ายเคอร์เซอร์ได้อย่างแม่นยำสูง และอยากให้ตอนนี้ยังมีตัวเลือกแบบนั้นเหลืออยู่
    • ในช่องป้อนข้อความทั่วไปของ iOS มีสามวิธีในการกำหนดตำแหน่งเคอร์เซอร์: แตะค้าง, แตะแป้นเว้นวรรคค้าง, และเลื่อนสองนิ้วพร้อมกันบนคีย์บอร์ดเสมือนของ iPad
      คีย์บอร์ด iOS มีจุดน่าหงุดหงิดมากมาย แต่จริง ๆ แล้วก็ค่อนข้างดี ปัญหาที่แท้จริงมักเกิดจาก เครื่องมือ JavaScript ของบุคคลที่สาม อย่าง CodeMirror รุ่นเก่า

  • บน BlackBerry เคยพิมพ์ได้ 55 คำต่อนาที โดยไม่ต้องมอง แป้นพิมพ์บนหน้าจอต้องคอยมองและแก้อยู่ตลอด จึงดึงความสนใจไปมากและฆ่าความเร็วในการพิมพ์
    บน BlackBerry ความผิดพลาดคืออักขระผิดเพียงตัวเดียว แต่บนแป้นพิมพ์หน้าจอที่มีการปัดและแก้อัตโนมัติ อาจมีคำแปลก ๆ หลุดเข้ามา 1–2 คำได้ วันฝนตกแป้นพิมพ์หน้าจอก็ใช้งานได้ไม่ดี
    บนอุปกรณ์ Android รุ่นเก่า แป้นพิมพ์ในตัวหนักเกินไปจนบางครั้งต้องพิมพ์ช้าลงเหลือระดับ 1 ตัวอักษรต่อวินาที และการสลับระหว่างการปัดกับการแตะก็ไม่ลื่นไหล การพยายามลากสเปซบาร์เพื่อย้ายเคอร์เซอร์แล้วดันแทรกคำเข้ามาตั้งแต่ครั้งแรกก็น่าหงุดหงิด

    • การพิมพ์เป็นอีกปัญหาหนึ่งต่างหาก ถ้าต้องการคีย์บอร์ดจริงบนอุปกรณ์มือถือ ก็มีของที่ใช้ได้จริง แต่ถึงอย่างนั้นก็ยังแก้ ปัญหาการแก้ไขข้อความ ไม่ได้
      การแก้ไขข้อความบน BlackBerry ก็ใช้แค่ปุ่มเคอร์เซอร์ จึงหยาบกว่าการควบคุมด้วยการสัมผัสที่พูดถึงในบทความนี้เสียอีก ประเด็นไม่ใช่แค่การแก้คำผิด แต่คือการทำให้อุปกรณ์มือถือสามารถแก้ข้อความเดิมในปริมาณมากและขัดเกลาเอกสารได้
    • BlackBerry Bold 9000 ใช้อยู่ช่วงสั้น ๆ แต่ไม่มีอุปกรณ์ใดตามความเร็วในการพิมพ์นั้นได้ทัน
      บนคีย์บอร์ดสไลด์ของ Droid 4 ช้าลงเล็กน้อย และเมื่อย้ายมาเป็นหน้าจอสัมผัสก็ช้าลงอย่างมหาศาล บน BlackBerry สามารถจัดการอีเมลได้เร็วเกือบเท่าแล็ปท็อป แต่ตอนนี้แม้จะฝึกใช้การปัดและการป้อนข้อความคาดเดามานาน อีเมลความยาวปานกลางก็ยังรู้สึกทรมานเมื่อเทียบกับความเร็วของความคิด
      ถ้าพยายามถอดความเนื้อหาพอดแคสต์ด้วยโทรศัพท์ ก็มักต้องกรอกลับบ่อย ๆ และลดความเร็วลงเหลือ 0.7x แต่บนแล็ปท็อปสามารถพิมพ์นำคำพูดเร็ว ๆ ได้ด้วยซ้ำ ถ้าเป็น BlackBerry Bold ก็คงจดการบรรยายสดแบบเรียลไทม์ได้ และพิมพ์ได้เร็วเท่าความคิด
    • การแก้อัตโนมัติถูกประเมินค่าสูงเกินไป และกลับทำให้กระบวนการพิมพ์น่าหงุดหงิดยิ่งขึ้น ลองทดสอบ monkeytype.com บน iPhone แล้ว แม้ไม่ใช้การแก้อัตโนมัติก็ได้ 80 wpm โดยผิดพลาด 0 ครั้ง
    • ต้นปีนี้ลองใช้ Unihertz Titan Pocket ที่มีคีย์บอร์ดจริง พบว่าให้ประสบการณ์พิมพ์ดีกว่าสมาร์ตโฟนอื่นมาก
    • ถ้าปิดการแก้อัตโนมัติ ก็ทำให้มันทำงานเหมือนเมื่อก่อนได้ ปัญหาคำแปลก ๆ หลุดเข้ามาแก้ได้ด้วยวิธีนั้น และสิ่งที่เหลืออยู่มีแค่การสัมผัสปุ่มด้วยมือไม่ได้เท่านั้น

  • ความแตกต่างระหว่างการแก้ไขบน MicroPC ที่มีทัชแพดกับคีย์บอร์ดจริง กับการแก้ไขบนโทรศัพท์นั้นมหาศาล
    อาจพิมพ์หรือสำรวจ UI บนโทรศัพท์จอสัมผัสแบบ capacitive ได้เร็วขึ้นก็จริง แต่ความหงุดหงิดจากการเล็งเคอร์เซอร์และการพิมพ์ยังหนักอยู่ แม้จะใช้สมาร์ตโฟนมานานกว่า 10 ปีแล้ว
    เข้าใจได้ว่าทำไมผู้คนถึงไม่ค่อยรู้สึกว่านี่เป็นปัญหา เพราะเมื่อเวลาผ่านไป เราได้เรียนรู้นิสัยที่จะไม่แก้ไขข้อความบนมือถือไปแล้ว ระบบปฏิบัติการมือถือสมัยใหม่มีชุดออฟฟิศที่ทรงพลังพอสมควรด้วยซ้ำ แต่คนส่วนใหญ่ทำแค่ส่งข้อความกับจดโน้ต และแทบไม่ต้องลากเคอร์เซอร์
    บน Squeekboard ของ PinePhone ฟีเจอร์ย้ายเคอร์เซอร์ด้วยการลากสเปซบาร์และการป้อนแบบปัดยังน่าเสียดายอยู่มาก แต่ข้อเท็จจริงที่ว่า แม้การแก้ไขข้อความของ Phosh จะขัดเกลาน้อยกว่า Android หรือ iOS มาก แต่ก็ไม่ได้เพิ่มความยากในการใช้งานจริงขึ้นมากนักนั้นบอกอะไรได้หลายอย่าง

    • ทุกครั้งที่หยิบ PinePhone ขึ้นมา ก็รู้สึกผิดหวังมากกับรูปแบบการโต้ตอบที่อุปกรณ์ส่วนใหญ่ในตอนนี้ถูกกักไว้ เพราะมันแสดงให้เห็นว่าแพลตฟอร์มเปิดอย่าง PinePhone สามารถทำทางเลือกอื่นได้ง่าย
      ถ้าดูเฉพาะการแก้ไขข้อความ เมื่อมีตัวเลข สัญลักษณ์ที่จำเป็น และปุ่มปรับแต่งอยู่ในเลเยอร์หลัก Vim กับ Emacs ก็ใช้งานกับคีย์บอร์ดสัมผัสได้ดีกว่าที่คิด
      ปัญหาการชี้ตำแหน่งอย่างแม่นยำและนิ้วใหญ่แก้ได้โดยใช้หน้าจอสัมผัสเป็น อินพุตสัมพัทธ์ เหมือนทัชแพด ทำได้ด้วยโปรแกรม user space ง่าย ๆ ที่ต่อเข้ากับ evdev และ uinput โดยตรง และทำให้การรันซอฟต์แวร์เดสก์ท็อปเป็นมากกว่าของเล่นง่าย ๆ: https://gitlab.com/CalcProgrammer1/TouchpadEmulator
      การป้อนแบบปัดใน wvkbd ที่รองรับแบบทดลองทำงานได้ค่อนข้างดี เหมาะเป็นพิเศษกับคำยาวหรือพจนานุกรมแบบย่อ และยังมีความเป็นไปได้อย่างการเขียน zsh completions ออกเป็นไฟล์เพื่อนำมาใช้: https://git.sr.ht/~proycon/wvkbd
      latency ของ sxmo_inputhandler.sh เข้าใจได้ยาก การจัดการ gesture ของ shell ระบบปฏิบัติการแบบง่าย ๆ ด้วยสคริปต์ shell ยาว ๆ และบนแพลตฟอร์มที่แค่มี grep pipeline เดียวก็เพิ่มดีเลย์จนสังเกตได้ ดูไร้ประสิทธิภาพมาก

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

    • การที่ผู้เขียนเคยทำงานที่ Google อาจเป็นเบาะแส บริษัทโฆษณาอย่าง Google ต้องการให้โทรศัพท์และแท็บเล็ตเหนือกว่าเดสก์ท็อปกับแล็ปท็อป
      เพราะอุปกรณ์เหล่านั้นมอบประสบการณ์คอมพิวติ้งที่แย่กว่า ปิดกั้นกว่า และเน้นการบริโภคมากกว่า แนวคิดแบบนี้ดูเหมือนจะถูกปลูกฝังให้พนักงานด้วย
    • อย่างที่บทความที่ลิงก์ไว้ก็กล่าว อุปกรณ์มือถือเดิมทีถูกออกแบบมาเพื่อ การบริโภค และต่อไปก็จะยังเป็นอุปกรณ์เพื่อการบริโภค
      เหมือนกับที่โทรทัศน์ไม่ใช่สิ่งทดแทนแล็ปท็อป
    • ไม่เข้าใจว่าการพามือถือเดินหน้าไปข้างหน้ากลายเป็นการให้สิทธิพิเศษแก่มือถือได้อย่างไร
      และก็ไม่ชัดเจนด้วยว่าทำแบบนั้นแล้วประสบการณ์เดสก์ท็อปเสียหายอย่างไร
    • การนอนบนเตียงหรือนั่งบนโซฟาใช้โทรศัพท์ สบายกว่าการนั่งเก้าอี้ใช้แล็ปท็อปหรือ PC เทอะทะมาก
      เขียนโค้ดใน Termux มากเกินไปจนตอนนี้ใช้แล็ปท็อปเฉพาะตอนแก้ไข OpenStreetMap เท่านั้น กำลังหาวิธี build แอป Android ใหม่ภายใน Termux เอง

  • บนมือถือ ไม่มีอะไรที่โอเคเลย ทุกคนชอบสมาร์ตโฟน แต่ถ้าไม่นับเรื่องพกพาสะดวกแล้ว มันคือ คอมพิวเตอร์ที่แย่ ในทุกด้าน
    ถ้าต้องการทำอะไรจริง ๆ ก็ต้องใช้คอมพิวเตอร์ ส่วนสมาร์ตโฟนเป็นอุปกรณ์ที่ใช้เฉพาะตอนที่ใช้คอมพิวเตอร์จริง ๆ ไม่ได้เท่านั้น

    • เรามักมีเรื่องต้องทำระหว่างเดินทางอยู่บ่อยมาก ดังนั้นสมาร์ตโฟนจึงหลีกเลี่ยงไม่ได้ที่จะถูกใช้งานบ่อยจริง ๆ
      นั่นทำให้บทความแบบนี้สำคัญ ไม่ใช่เรื่องที่ควรยอมแพ้ แต่ควรปรับปรุง และก็ไม่มีเหตุผลให้คิดว่าการแก้ไขข้อความบนมือถือมาถึงรูปแบบสุดท้ายแล้ว
    • การได้อ่าน The Simplicity Shift ของ Jenson เมื่อนานมาแล้ว เป็นหนึ่งในจุดเปลี่ยนสำคัญในอาชีพของผม
      เป็นงานเขียนก่อนยุค iPhone ที่ว่าด้วยความจำเป็นอันโหดร้ายในการลดทอนประสบการณ์ผู้ใช้บนมือถือให้เหลือเฉพาะสิ่งสำคัญที่สุด เรื่องนี้กลับมาทำให้ผมนึกถึงอีกครั้งตอนสร้างแอป Apple Watch: https://jenson.org/The-Simplicity-Shift.pdf
    • หากไม่นับ Android ระดับล่างสุด สมาร์ตโฟนดี ๆ ในปัจจุบันมีราคาใกล้เคียงกับคอมพิวเตอร์ decent เครื่องหนึ่ง
      เป็นเรื่องยากจะยอมรับได้ที่อุปกรณ์ซึ่งเก็บเงินระดับนั้นกลับให้ ประสบการณ์ผู้ใช้ที่ย่ำแย่ โดยให้ความสำคัญกับการติดตามและลูกเล่นโฆษณามากกว่าประโยชน์ใช้สอย
    • ถ้าคีย์บอร์ดแบบสไลด์ยังมีอยู่ มันคงไม่แย่ขนาดนี้ แต่เพราะสิ่งที่สำคัญที่สุดในโลกคือการทำให้เครื่องบางลง มันเลยถูกตัดทิ้งไป
    • ช่วงหลังผมซื้อ PineTab2 มา แม้จะยังค่อนข้างหยาบอยู่ แต่เมื่อใช้กับเคสคีย์บอร์ดแล้ว มันดีกว่าสำหรับการเขียนมาก
      แม้จะไม่เท่าเดสก์ท็อป แต่ก็ดีกว่าอุปกรณ์มือถือส่วนใหญ่มาก และถ้าต้องเขียนเกินหนึ่งหรือสองประโยค ผมก็มักใช้ WhatsApp Web หรือแอปเดสก์ท็อปของ Signal บนเดสก์ท็อป
      ถ้าต้องเขียนข้อความที่ยาวแม้เพียงเล็กน้อยบนโทรศัพท์ ก็ควรซื้อคีย์บอร์ด คีย์บอร์ด Bluetooth ขนาดเล็กก็ยังดีกว่ามาก และผมก็รู้สึกสนใจ BlackBerry รุ่นเก่า ๆ หรือโทรศัพท์ Android ที่มีคีย์บอร์ดในรูปแบบคล้ายกันด้วย