Driver.js: प्रोडक्ट टूर, हाइलाइट्स और संदर्भानुसार मदद के लिए Vanilla JS लाइब्रेरी

 (driverjs.com)
4 पॉइंट द्वारा GN⁺ 2023-07-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक हल्की JavaScript लाइब्रेरी है, जिससे उन स्क्रीन पर प्रोडक्ट टूर और हाइलाइट्स जोड़े जा सकते हैं जहाँ प्रोडक्ट के भीतर उपयोगकर्ताओं को गाइड करना हो
  • यह Vanilla JavaScript पर आधारित है, किसी dependency के बिना काम करती है, और प्रमुख browsers तथा mobile devices को सपोर्ट करती है
  • यह TypeScript में लिखी गई MIT लाइसेंस वाली open source लाइब्रेरी है, जो customization और accessibility support पर ज़ोर देती है
  • यह user onboarding, ध्यान केंद्रित कराने, संदर्भानुसार मदद, और नए फीचर्स को अपनाने को बढ़ावा देने जैसे in-product guidance flows के लिए उपयुक्त है
  • इसके लाखों downloads हैं और GitHub Star 26K हैं; getting started examples और docs आधिकारिक दस्तावेज़ में देखे जा सकते हैं

लाइब्रेरी की प्रकृति और सपोर्ट का दायरा

  • Driver.js एक हल्की JavaScript लाइब्रेरी है, जो प्रोडक्ट टूर, हाइलाइट्स और संदर्भानुसार मदद के ज़रिए उपयोगकर्ताओं को प्रोडक्ट समझने में मदद करती है
  • यह Vanilla JavaScript पर आधारित है, इसलिए इसे किसी अलग dependency के बिना इस्तेमाल किया जा सकता है, और यह TypeScript में लिखी गई है
  • सपोर्ट और configuration के लिहाज़ से इसकी विशेषताएँ इस प्रकार हैं
    • प्रमुख browsers और mobile devices का सपोर्ट
    • उच्च स्तर की customization क्षमता
    • हल्का ढाँचा और समृद्ध फीचर्स
    • MIT लाइसेंस
    • इस्तेमाल में आसान API
    • accessibility support
    • framework-ready

प्रोडक्ट के भीतर उपयोग के तरीके

  • User onboarding: प्रोडक्ट के उपयोग का चरण-दर-चरण परिचय दिया जा सकता है और सामान्य सवालों के जवाब देने में मार्गदर्शन किया जा सकता है
  • ध्यान भंग कम करना: महत्वपूर्ण elements को highlight करके उपयोगकर्ता का ध्यान किसी खास हिस्से पर केंद्रित किया जा सकता है
  • संदर्भानुसार मदद: प्रोडक्ट के भीतर ज़रूरत के सही समय पर उपयोग विधि और help दी जा सकती है
  • Feature adoption: नए फीचर्स को highlight करके और उनका उपयोग समझाकर यह सुनिश्चित किया जा सकता है कि उपयोगकर्ता उन्हें नज़रअंदाज़ न करें

दस्तावेज़ और प्रोजेक्ट जानकारी

  • अधिक examples और शुरुआत करने का तरीका docs में उपलब्ध है
  • GitHub repository kamranahmedse/driver.js है, और GitHub Star 26K दिखाए गए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-25
Hacker News की राय

  • नहीं, प्रोडक्ट ऐसा डिज़ाइन होना चाहिए कि पहली बार में ही समझ आ जाए
    Apple इस मामले में iPhone पर लगभग ऐसा नहीं करने के लिए मशहूर है, जबकि Sony हर नए डिवाइस पर इस तरह की प्रक्रिया थोपता है
    onboarding का उद्देश्य usability को आगे बढ़ाना होना चाहिए; यह सहायक टूल नहीं, बल्कि इससे भी बदतर और नुकसानदेह चीज़ बन जाता है

    • “Apple iPhone पर लगभग ऐसा नहीं करता” वाली बात तो उल्टा इस पक्ष में जाती है कि प्रोडक्ट टूर की ज़रूरत है
      iOS की usability बिखरी हुई है, affordance कम है, और discoverability भी कमजोर है
      बहुत-से input तरीके, खासकर gestures, ऐसे हैं जिनके बारे में कोई बताए या आप खोजें नहीं तो पता ही नहीं चलता, और app दर app, यहाँ तक कि Apple के default apps के बीच भी consistency नहीं है
      कभी “row को बाएँ swipe करना” का मतलब “delete” होता है, तो कभी “extra actions”, यानी पूरा घालमेल है
      non-technical users को iPhone इस्तेमाल करते देखें तो अक्सर वे उपलब्ध फीचर्स के आधे भी नहीं जानते। उदाहरण के लिए, क्या आपने किसी को “shake to undo” इस्तेमाल करते देखा है?
    • इसलिए शायद iPhone उपयोगकर्ताओं में से आधे अब भी नहीं जानते कि keyboard या spacebar को लंबा दबाकर cursor control किया जा सकता है। यह तो बस एक उदाहरण है
    • यह तरीका हर चीज़ पर व्यावहारिक नहीं है। फोन intuitive होना चाहिए, और उससे भी ज़्यादा ज़रूरी यह है कि शुरुआत में हर interaction pattern जानना आवश्यक नहीं; समय के साथ सीखा जा सकता है
      लेकिन हाल में CRM के लिए HubSpot पर साइन अप किया, और भले ही मुझे वह कुल मिलाकर व्यवस्थित और intuitive प्रोडक्ट लगा, फिर भी उसे smartphone जितना intuitive बनाना मुश्किल, बल्कि लगभग असंभव है। ऐसे मामलों में प्रोडक्ट टूर काफ़ी मददगार होते हैं
    • मैं इस बात से सहमत हूँ कि usability और discoverability हमेशा चाहिए। लेकिन यह कहना कि हर चीज़ हर समय बस अपने-आप discover हो जानी चाहिए, मुझे उस काल्पनिक काफ़ी स्मार्ट compiler वाली बहस जैसा लगता है
      यानी एक ऐसा अप्राप्य आदर्श जो असल दुनिया में मौजूद नहीं है
      मौजूदा UX स्तर पर यह विश्वास करना मुश्किल है कि हम ऐसा UI बना सकते हैं जिसे प्रोडक्ट टूर, documentation, video tutorials वगैरह की बिल्कुल ज़रूरत न पड़े, और कम से कम कुछ हद तक जटिल प्रोडक्ट्स में तो और भी नहीं
    • consumer apps के लिए यह बात ज़्यादातर सही लगती है
      लेकिन B2B apps, जहाँ प्रोडक्ट demo tutorials ज़्यादा इस्तेमाल होते हैं, अलग हैं। अच्छा प्रोडक्ट tutorial sales लोगों के लिए ग्राहकों को app समझाने और prospects को ठीक से बेचने में उपयोगी होता है
      अगर deal size दसियों हज़ार से लेकर लाखों डॉलर तक है और प्रोडक्ट भी काफ़ी जटिल है, तो sales/support स्टाफ का लगातार आग बुझाने जैसा काम करने से यह बेहतर समाधान है

  • क्या सिर्फ मैं ही हूँ जो ऐसी चीज़ों को जितनी जल्दी हो सके बंद कर देता है और चिढ़ता भी रहता है?

    • मैं भी ऐसा ही हूँ, लेकिन निष्पक्ष होकर देखें तो HN पर हम जैसे technical users शायद उन प्रोडक्ट्स के मुख्य target users नहीं हैं जिनमें ये चीज़ें जोड़ी जाती हैं
    • अगर skip किया जा सके और बाद में फिर से किया जा सके, तो मुझे ठीक लगता है
      आम तौर पर skip करना तो संभव होता है, लेकिन बाद में जब आप सच में app को ठीक से सीखना चाहें, तब उसे दोबारा शुरू करने का तरीका लगभग कभी नहीं मिलता
    • यह use case पर निर्भर करता है। users को onboard करते समय इससे वे support emails कम हो जाते हैं जो लोग बुनियादी काम करना न जानने के कारण भेजते हैं
      और यह नए features दिखाने के लिए भी अच्छा है, जिनकी माँग तो थी लेकिन जो main screen की जगह घेरने लायक नहीं हैं
      बस जब यह बहुत obvious चीज़ों की ओर इशारा करता है, तब चिढ़ होती है
    • अक्सर यह खराब डिज़ाइन को सहारा देने वाली बैसाखी जैसा लगता है, लेकिन कुछ प्रोडक्ट्स में complexity तो अपरिहार्य होती है
    • UI की दुनिया में मैंने ऐसी चीज़ों, app download popups, mailing list popups, फिर app download, social media follow, फिर app download जैसी चीज़ों को कई बार nagging कहते देखा है। शायद इसलिए कि इसे “जाओ भाड़ में” कहना लिखने में ज़्यादा लंबा पड़ता
      उपयोगी और शत्रुतापूर्ण चीज़ के बीच कोई महीन रेखा नहीं होती; वहाँ चमकती बत्तियों और सायरन वाली एक बड़ी, साफ़ रेखा होती है

  • प्रोडक्ट user के रूप में मुझे प्रोडक्ट टूर पसंद नहीं, लेकिन प्रोडक्ट developer के रूप में मैं हमेशा open source alternatives चाहता हूँ
    यह लाइब्रेरी अपने effects में काफ़ी smooth लगती है, इसलिए काफ़ी बढ़िया है
    व्यक्तिगत रूप से कुछ प्रोडक्ट्स बनाते समय मैंने देखा है कि सबसे अच्छी तरह डिज़ाइन किए गए प्रोडक्ट टूर भी SMB/consumer products में लगभग 90% मामलों में बंद कर दिए जाते हैं

  • मुझे इस तरह की चीज़ें थोड़ी पसंद हैं
    बस नए users पर इन्हें थोपना नहीं चाहिए; उनसे पूछ लेना चाहिए कि वे टूर लेना चाहते हैं या नहीं
    इन्हें केवल तब बहुत सोच-समझकर इस्तेमाल करना चाहिए जब app में नए features, buttons, या changes जोड़े गए हों, और session में एक बार ही दिखाना चाहिए; prompt में “Close/Tour” जैसे विकल्प हों तो बेहतर
    app का UX intuitive होना ज़्यादा अच्छा है, लेकिन non-forced tours मददगार हो सकते हैं
    feature announcement वाले login interstitials से तो यह बेहतर है

    • काश कहीं कोई help menu हो जिसमें अच्छी documentation और टूर को फिर से चलाने का विकल्प भी मिले
      बहुत-से designers शायद मानते हैं कि जब मैं app खोलता हूँ तो मैं सोच रहा होता हूँ, “आज इन शानदार लोगों ने मेरे लिए कौन-सी नई खुशियाँ तैयार की होंगी?” और मेरे पास ढेर सारा समय है
      हक़ीक़त में ज़्यादातर बार मैं app किसी खास काम को तुरंत पूरा करने के लिए खोलता हूँ, और वही पल ऐसा होता है जब किसी के अपने प्रोडक्ट-शिशु की तस्वीरें दिखाकर मुझसे “हाँ, बहुत प्यारा है” कहलवाने की कोशिश सबसे कम स्वीकार्य लगती है
      मैं वास्तव में टूर के लिए तब खुला होता हूँ जब काम पूरा हो चुका हो, या जब मुझे अभी-अभी एहसास हुआ हो कि जो काम करना है वह कैसे करना है, यह मुझे पता नहीं

  • प्रोडक्ट टूर हमेशा बुरे नहीं होते, लेकिन अक्सर उनमें user के लिए अर्थहीन चरण बहुत ज़्यादा होते हैं, इसलिए implementation कमजोर होती है
    embedded tips जैसी context-aware onboarding, persona के हिसाब से relevant onboarding, या checklist जैसी action-oriented onboarding आम तौर पर बेहतर होती है
    Dropbox में onboarding और in-app education team को लीड करने के बाद मैंने Dopt [0] शुरू किया, जो सिर्फ tours ही नहीं बल्कि embedded tips और checklist जैसी ज़्यादा contextual और कम बाधक onboarding experiences को आसानी से बनाने के लिए React component library और SDK है
    Dopt के साथ ज़रूरत पड़ने पर आप नए feature introduce करने के लिए 2-step tour जैसी चीज़ें भी बना सकते हैं, लेकिन हम onboarding और education के हर तरह के उपयोग के लिए एक बड़ा और बेहतर toolbox देना चाहते हैं
    [0] https://dopt.com/

    • मैं यह जानना चाहता हूँ कि वेबसाइट पर cookies क्यों इकट्ठी करनी पड़ती हैं। पहली चीज़ जो दिखती है वह cookie notice screen है, इसलिए यह सवाल उठता है कि आखिर क्या track किया जा रहा है
      और “Hybrid work” को लेकर भी जिज्ञासा है
      ऊपर-ऊपर से देखें तो पहले से स्पष्ट कर देना अच्छा है, लेकिन जब ऐसी research[0] मौजूद है कि 100% remote work ज़्यादा productive employees देता है, तो hybrid को समाधान क्यों चुना गया, यह जानने की इच्छा होती है
      [0]: https://thehill.com/business/4110598-remote-employees-work-l...

  • अच्छा लग रहा है। Shepherd[0] की तुलना में इसमें क्या अलग है?
    [0]: https://github.com/shipshapecode/shepherd

    • दोनों की तुलना करने लायक community जानकारी मौजूद है
      https://devboard.gitsense.com/shipshapecode/shepherd
      https://devboard.gitsense.com/kamranahmedse/driver.js
      पिछले कुछ हफ्तों में driver.js की लोकप्रियता काफ़ी बढ़ी है, लेकिन वजह ठीक से समझ नहीं आ रही
      संदर्भ के लिए, यह मेरा बनाया हुआ टूल है
    • Driver, Shepherd के बाद अगला नाम किस दिशा में जाएगा, इसका अंदाज़ा लगाया जा सकता है

  • इस तरह के tour की समस्या यह है कि बहुत कम समय में बहुत ज़्यादा जानकारी सीधे सामने डालकर गायब हो जाती है
    कुछ मिनट बाद यूज़र पूछता है, “यह सेक्शन किस काम का था?”
    मैंने इसे पहले एक drone control platform बनाते समय इस्तेमाल किया था, और dashboard इतना जटिल था कि क्लिक करने से पहले यह जानना ज़रूरी था कि कौन-सा सेक्शन control के लिए है और कौन-सा video feed के लिए
    लेकिन यूज़र अक्सर पढ़ते भी नहीं थे, बस सिर हिलाकर Next दबाते जाते थे, इसलिए आखिर में हमने इसे हटा दिया और हर सेक्शन में info icon जोड़ दिए ताकि mouse hover पर विवरण दिख सके

  • Redux app में ऐसा ही कुछ करने के लिए मैंने https://github.com/Evernote/Aquaman लाइब्रेरी बनाई थी। React context के लिए भी यही चीज़ बनाई थी, लेकिन उसे open source के रूप में जारी नहीं किया गया
    यहाँ जो बात छूट रही है, वह यह है कि 1) app state को guided tour trigger करना पड़ सकता है, 2) कभी न कभी multi-step flow की ज़रूरत पड़ने की संभावना बहुत है, और 3) उस flow की state change logic को rendering logic से अलग होना चाहिए
    flow के सभी step एक साथ होने चाहिए। Aquaman से यह किया जा सकता था

  • यूज़र के तौर पर मुझे यह पसंद नहीं, लेकिन developer के तौर पर product team requirements पूरी करने के लिए यह अच्छी लाइब्रेरी है

  • आज मैंने किसी दूसरे product के लिए Walnut.io [1] का demo देखा, उसमें से ज़्यादातर मैंने skip कर दिया और product के बारे में भी लगभग कुछ समझ नहीं पाया
    मेरे हिसाब से यह टूल से ज़्यादा इस बात पर निर्भर करता है कि product tour को कौन और कैसे बनाता है
    कुछ products इतने complex होते हैं कि उन्हें explanation, solution engineer, या account manager की guidance की ज़रूरत पड़ सकती है। ऐसा कोई चमत्कारी product नहीं है जिसे help या product tour की बिल्कुल ज़रूरत न पड़े
    [1] https://walnut.io