Driver.js: ไลบรารี Vanilla JS สำหรับทัวร์ผลิตภัณฑ์ ไฮไลต์ และความช่วยเหลือตามบริบท

 (driverjs.com)
4 คะแนน โดย GN⁺ 2023-07-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นไลบรารี JavaScript แบบน้ำหนักเบาที่สามารถเพิ่ม ทัวร์ผลิตภัณฑ์ และไฮไลต์ให้กับหน้าจอที่ต้องการแนะนำผู้ใช้ภายในผลิตภัณฑ์
  • ทำงานบนพื้นฐานของ Vanilla JavaScript โดยไม่มี dependency และรองรับเบราว์เซอร์หลักรวมถึงอุปกรณ์มือถือ
  • เป็นโอเพนซอร์สภายใต้ MIT License ที่เขียนด้วย TypeScript พร้อมชูจุดเด่นด้านการปรับแต่งและการรองรับการเข้าถึง
  • ออกแบบมาสำหรับโฟลว์การแนะนำภายในผลิตภัณฑ์ เช่น การ onboarding ผู้ใช้ การดึงความสนใจ ความช่วยเหลือตามบริบท และการผลักดัน การยอมรับฟีเจอร์ใหม่
  • มียอดดาวน์โหลดหลายล้านครั้งและมี GitHub Star 26K โดยสามารถดูตัวอย่างเริ่มต้นและเอกสารได้จากเอกสารทางการ

ลักษณะของไลบรารีและขอบเขตการรองรับ

  • Driver.js เป็น ไลบรารี JavaScript แบบน้ำหนักเบา ที่ช่วยให้ผู้ใช้เข้าใจผลิตภัณฑ์ผ่านทัวร์ผลิตภัณฑ์ ไฮไลต์ และความช่วยเหลือตามบริบท
  • พัฒนาบนพื้นฐานของ Vanilla JavaScript จึงใช้งานได้โดยไม่ต้องมี dependency เพิ่มเติม และเขียนด้วย TypeScript
  • คุณลักษณะด้านการรองรับและการตั้งค่ามีดังนี้
    • รองรับเบราว์เซอร์หลักและอุปกรณ์มือถือ
    • ปรับแต่งได้สูง
    • โครงสร้างเบาและฟีเจอร์ครบถ้วน
    • MIT License
    • API ที่ใช้งานง่าย
    • รองรับการเข้าถึง
    • พร้อมใช้งานกับเฟรมเวิร์ก

วิธีการใช้งานภายในผลิตภัณฑ์

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

เอกสารและข้อมูลโครงการ

  • ตัวอย่างเพิ่มเติมและวิธีเริ่มต้นมีให้ที่เอกสาร
  • รีโพซิทอรีบน GitHub คือ kamranahmedse/driver.js และแสดงจำนวน GitHub Star ที่ 26K

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

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

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

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

    • คำว่า “Apple แทบไม่ทำอะไรแบบนี้บน iPhone” กลับฟังดูใกล้เคียงกับฝ่ายที่บอกว่าจำเป็นต้องมี ทัวร์แนะนำผลิตภัณฑ์ มากกว่า
      ความใช้งานง่ายของ iOS นั้นเละเทะ ขาด affordance และค้นพบฟีเจอร์ได้ยาก
      มีวิธีป้อนข้อมูล โดยเฉพาะ gesture จำนวนมากที่ถ้าไม่มีใครบอกหรือไม่ค้นหาก็จะไม่รู้ และยังไม่สอดคล้องกันระหว่างแอปต่าง ๆ แม้แต่แอปพื้นฐานของ Apple เอง
      บางครั้ง “ปัดแถวไปทางซ้าย” คือ “ลบ” แต่บางครั้งคือ “การทำงานเพิ่มเติม” มั่วไปหมด
      ถ้าดูผู้ใช้ที่ไม่ใช่สายเทคนิคใช้ iPhone มักพบว่าพวกเขาไม่รู้ฟังก์ชันที่ทำได้ถึงครึ่งหนึ่งด้วยซ้ำ เช่น เคยเห็นใครใช้ “เขย่าเพื่อเลิกทำ” ไหม?
    • นั่นอาจเป็นเหตุผลที่ผู้ใช้ iPhone ครึ่งหนึ่งยังไม่รู้ว่าสามารถ กดคีย์บอร์ดหรือสเปซบาร์ค้างไว้เพื่อควบคุมเคอร์เซอร์ ได้ นี่เป็นเพียงตัวอย่างเดียวเท่านั้น
    • วิธีนี้ไม่ได้เหมาะกับทุกอย่าง โทรศัพท์ควรใช้งานได้โดยสัญชาตญาณ และที่สำคัญกว่านั้นคือเราไม่จำเป็นต้องรู้วิธีทำทุกอย่างตั้งแต่แรก สามารถค่อย ๆ เรียนรู้ไปตามเวลาได้
      แต่เมื่อเร็ว ๆ นี้ผมลองสมัครใช้ HubSpot ในฐานะ CRM แม้จะรู้สึกว่าโดยรวมเป็นผลิตภัณฑ์ที่จัดระเบียบดีและค่อนข้างใช้งานง่าย แต่การทำให้ใช้งานได้โดยสัญชาตญาณเท่าสมาร์ตโฟนนั้นยากมากหรือแทบเป็นไปไม่ได้ ในกรณีแบบนี้ ทัวร์แนะนำผลิตภัณฑ์ช่วยได้มากทีเดียว
    • เห็นด้วยว่าเราต้องการ usability และ discoverability อยู่เสมอ แต่การอ้างว่าทุกอย่างควรถูกค้นพบได้เองเสมอฟังดูเหมือนการถกเถียงเรื่อง คอมไพเลอร์ที่ฉลาดพอ ในตำนาน
      หมายถึงเป็นอุดมคติที่แทบเป็นไปไม่ได้และไม่มีอยู่จริงในทางปฏิบัติ
      ด้วยระดับประสบการณ์ผู้ใช้ในปัจจุบัน ผมไม่มั่นใจว่าเราจะสร้าง UI ที่ไม่ต้องมีทัวร์ผลิตภัณฑ์ เอกสาร หรือวิดีโอสอนได้เลย โดยเฉพาะกับผลิตภัณฑ์ที่มีความซับซ้อนระดับหนึ่งขึ้นไป
    • ถ้าเป็นแอปสำหรับผู้บริโภคทั่วไป ผมคิดว่าโดยมากก็ถูก
      แต่ แอป B2B ที่มักใช้เดโมสอนผลิตภัณฑ์นั้นต่างออกไป ทิวทอเรียลผลิตภัณฑ์ที่ดีมีประโยชน์สำหรับให้ฝ่ายขายพาลูกค้าเดินดูแอปและขายให้ผู้มีโอกาสเป็นลูกค้าได้อย่างเหมาะสม
      ถ้ามูลค่าสัญญาอยู่ที่หลักหมื่นถึงหลายแสนดอลลาร์ และผลิตภัณฑ์ก็ค่อนข้างซับซ้อน นี่เป็นทางออกที่ดีกว่าการให้ทีมขายและซัพพอร์ตคอยดับไฟไปเรื่อย ๆ

  • มีแค่ผมหรือเปล่าที่รีบปิดของพวกนี้ให้เร็วที่สุดแล้วก็บ่นว่ารำคาญ?

    • ผมก็เป็นแบบนั้น แต่ถ้าว่ากันอย่างเป็นธรรม ผู้ใช้สายเทคนิค อย่างพวกเราใน HN น่าจะไม่ใช่กลุ่มเป้าหมายหลักของผลิตภัณฑ์ที่ผสานของพวกนี้เข้าไป
    • ถ้าข้ามได้และกลับมาทำใหม่ทีหลังได้ ผมว่าก็โอเค
      ปกติมักข้ามได้ แต่พอตัดสินใจว่าจะลองเรียนรู้แอปจริง ๆ แล้ว แทบจะหาวิธีเริ่มใหม่ไม่เจอ
    • ขึ้นอยู่กับกรณีใช้งาน ตอนออนบอร์ดผู้ใช้ มันช่วยลด อีเมลขอความช่วยเหลือ ที่มาจากการไม่รู้ว่าควรทำงานพื้นฐานอย่างไร
      และยังดีสำหรับการแสดงฟีเจอร์ใหม่ที่มีคนขอมา แต่ยังไม่ถึงขั้นต้องใช้พื้นที่บนหน้าหลัก
      ที่น่ารำคาญคือเวลาชี้ให้ดูอะไรที่ชัดเจนอยู่แล้ว
    • โดยทั่วไปมันรู้สึกเหมือนไม้ค้ำสำหรับชดเชยการออกแบบที่ไม่ดี แต่ผลิตภัณฑ์บางอย่างก็มี ความซับซ้อน อย่างหลีกเลี่ยงไม่ได้
    • ในบริบทของ UI ผมเคยเห็นคนเรียกสิ่งแบบนี้ ป๊อปอัปให้ดาวน์โหลดแอป ป๊อปอัปสมัครเมลลิงลิสต์ แล้วก็ให้ดาวน์โหลดแอปอีก ให้ติดตามโซเชียลมีเดีย แล้วก็ให้ดาวน์โหลดแอปอีก ว่าเป็น การจู้จี้ หลายครั้ง อาจเพราะคำว่า “ไปตายซะ” มีตัวอักษรมากเกินไป
      เส้นแบ่งระหว่างสิ่งที่เป็นประโยชน์กับสิ่งที่เป็นปฏิปักษ์ไม่ได้บางเฉียบ แต่มันเป็นเส้นใหญ่ชัดเจนพร้อมไฟกะพริบและไซเรน

  • ในฐานะผู้ใช้ผลิตภัณฑ์ ผมไม่ชอบทัวร์แนะนำผลิตภัณฑ์ แต่ในฐานะนักพัฒนาผลิตภัณฑ์ ผมก็มักอยากได้ ทางเลือกโอเพนซอร์ส อยู่เสมอ
    ไลบรารีนี้ดูค่อนข้างเจ๋ง เพราะเอฟเฟกต์ดูลื่นไหล
    จากที่ผมทำผลิตภัณฑ์มาหลายตัว โดยส่วนตัวเห็นว่าแม้แต่ทัวร์แนะนำผลิตภัณฑ์ที่ออกแบบมาดีที่สุด ในผลิตภัณฑ์สำหรับ SMB/ผู้บริโภค ก็ยังถูกปิดทิ้งประมาณ 90%

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

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

  • ทัวร์แนะนำผลิตภัณฑ์ไม่ได้แย่เสมอไป แต่บ่อยครั้ง การนำไปใช้ยังไม่ดี เพราะมีขั้นตอนที่ไม่มีความหมายต่อผู้ใช้มากเกินไป
    ออนบอร์ดดิ้งที่เข้ากับบริบทเหมือนทิปแบบฝังในหน้า เกี่ยวข้องกับผู้ใช้เหมือนการออนบอร์ดแบบปรับตาม persona หรือเน้นการลงมือทำเหมือนเช็กลิสต์ โดยทั่วไปจะดีกว่า
    หลังจากนำทีม onboarding และการให้ความรู้ในแอปที่ Dropbox ผมก็เริ่มทำ Dopt [0] ซึ่งเป็นไลบรารี React components และ SDK เพื่อให้สร้างประสบการณ์ onboarding ที่มีบริบทมากขึ้นและรบกวนน้อยลงได้ง่าย ไม่ใช่แค่ทัวร์ แต่รวมถึงทิปแบบฝังในหน้าและเช็กลิสต์ด้วย
    ด้วย Dopt หากจำเป็นก็สร้างทัวร์ 2 ขั้นตอนสำหรับแนะนำฟีเจอร์ใหม่ได้เช่นกัน แต่เราอยากมอบกล่องเครื่องมือที่ใหญ่กว่าและดีกว่าสำหรับ onboarding และการให้ความรู้ทุกรูปแบบ
    [0] https://dopt.com/

    • สงสัยว่าทำไมเว็บไซต์ถึงต้องเก็บคุกกี้ สิ่งแรกที่เจอคือ หน้าการแจ้งเตือนคุกกี้ เลยทำให้อยากรู้ว่าติดตามอะไรอยู่
      แล้วก็สงสัยเรื่อง “Hybrid work” ด้วย
      มองจากภายนอก การระบุไว้ล่วงหน้าก็เป็นเรื่องดี แต่ในเมื่อมีงานวิจัย[0] ที่บอกว่าการทำงานแบบรีโมต 100% นำไปสู่พนักงานที่มี productivity สูงกว่า ทำไมถึงกำหนดให้ไฮบริดเป็นคำตอบ
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • ดูน่าสนใจดี เมื่อเทียบกับ Shepherd[0] แล้วต่างกันอย่างไร?
    [0]: https://github.com/shipshapecode/shepherd

    • มีข้อมูลจากชุมชนที่ใช้เปรียบเทียบทั้งสองตัวได้
      https://devboard.gitsense.com/shipshapecode/shepherd
      https://devboard.gitsense.com/kamranahmedse/driver.js
      ในช่วงไม่กี่สัปดาห์ที่ผ่านมา ความนิยมของ driver.js เพิ่มขึ้นอย่างมาก แต่ไม่ค่อยแน่ใจว่าเพราะอะไร
      อนึ่ง นี่เป็นเครื่องมือที่ผมสร้างเอง
    • ถ้าเป็น Driver, Shepherd ก็น่าจะพอเดาได้ว่าชื่อต่อไปจะไปทางไหน

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

  • ผมสร้างไลบรารี https://github.com/Evernote/Aquaman เพื่อทำงานคล้าย ๆ กันในแอป Redux เคยทำแบบเดียวกันสำหรับ React context ด้วย แต่ไม่ได้ปล่อยเป็นโอเพนซอร์ส
    สิ่งที่ตรงนี้ยังขาดคือ 1) สถานะของแอปอาจต้องเป็นตัวกระตุ้นทัวร์แบบมีไกด์, 2) สักวันหนึ่งมีโอกาสสูงที่จะต้องใช้ โฟลว์หลายขั้นตอน, และ 3) ลอจิกการเปลี่ยนสถานะของโฟลว์นั้นควรแยกออกจากลอจิกการเรนเดอร์
    ทุกขั้นตอนของโฟลว์ควรอยู่รวมกัน Aquaman ทำสิ่งนั้นได้

  • ในฐานะผู้ใช้ผมไม่ชอบ แต่ในฐานะนักพัฒนา นี่เป็นไลบรารีที่ดีสำหรับตอบสนอง ความต้องการของทีมผลิตภัณฑ์

  • วันนี้ได้ดูเดโม Walnut.io [1] สำหรับผลิตภัณฑ์อื่น ส่วนใหญ่ผมกดข้าม และแทบไม่เข้าใจผลิตภัณฑ์นั้นเลย
    ผมคิดว่ามันขึ้นอยู่กับว่า การจัดทำทัวร์ผลิตภัณฑ์ ทำโดยใครและทำอย่างไรมากกว่าตัวเครื่องมือเอง
    ผลิตภัณฑ์บางอย่างซับซ้อนจนต้องมีคำอธิบาย หรือการแนะนำจาก solution engineer หรือ account manager ไม่มีผลิตภัณฑ์ใดที่ยอดเยี่ยมจนไม่ต้องการความช่วยเหลือหรือทัวร์ผลิตภัณฑ์เลย
    [1] https://walnut.io