Diátaxis – तकनीकी दस्तावेज़ लेखन के लिए एक व्यवस्थित दृष्टिकोण

 (diataxis.fr)
3 पॉइंट द्वारा GN⁺ 2024-12-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • इस आधार पर कि तकनीकी दस्तावेज़ों को उपयोगकर्ता की स्थिति के अनुसार अलग-अलग भूमिका निभानी चाहिए, Diátaxis एक ऐसा दृष्टिकोण है जो content·structure·format को साथ में व्यवस्थित करता है
  • यह उपयोगकर्ता की ज़रूरतों को 4 हिस्सों में बाँटता है और उन्हें क्रमशः tutorials, how-to guides, technical reference, explanation दस्तावेज़ प्रकारों से जोड़ता है
  • यह केवल एक वर्गीकरण तालिका नहीं, बल्कि क्या लिखना है, कैसे लिखना है, और कहाँ रखना है, इसे संभालने वाले documentation design framework के अधिक क़रीब है
  • इससे लेखक और मेंटेनर, दोनों के लिए दस्तावेज़ की गुणवत्ता का आकलन करना आसान हो जाता है, और इसकी हल्की, सहज तथा किसी विशेष implementation method को बाध्य न करने वाली प्रकृति इसकी मज़बूती है
  • Vonage, Gatsby, Cloudflare के उदाहरणों की तरह, यह उन टीमों के लिए एक व्यावहारिक मानदंड बन सकता है जो दस्तावेज़ों की navigability और information architecture को बेहतर बनाना चाहती हैं

Diátaxis द्वारा विभाजित 4 दस्तावेज़ प्रकार

  • Diátaxis तकनीकी दस्तावेज़ लिखने और संचालित करने के लिए एक सोचने का तरीका और कार्यान्वयन का तरीका है
  • इसका शुरुआती बिंदु दस्तावेज़ उपयोगकर्ता की ज़रूरतों को समझना है, और यहीं से content, architecture और format के लिए सिद्धांत निकाले जाते हैं
  • दस्तावेज़ आवश्यकताएँ और format 4 प्रकारों में बाँटे जाते हैं

    • tutorials

    • how-to guides

    • technical reference

      • explanation
      • दस्तावेज़ स्वयं भी इन 4 ज़रूरतों के केंद्र में संगठित होने चाहिए, और Diátaxis तीन प्रश्नों को साथ में संबोधित करता है
      • content: क्या लिखना है
      • style: कैसे लिखना है
      • architecture: कैसे संगठित करना है

लेखकों और मेंटेनरों के लिए उपयोगिता

  • Diátaxis केवल दस्तावेज़ उपयोगकर्ताओं के लिए ही नहीं, बल्कि दस्तावेज़ लेखक और मेंटेनर के लिए भी उपयोगी दृष्टिकोण है
    • हल्का और समझने में आसान
    • लागू करना सहज
    • implementation constraints को बाध्य नहीं करता
    • मेंटेनरों को अपने काम का मूल्यांकन करने के लिए quality principles देता है
  • इन सिद्धांतों को सैकड़ों दस्तावेज़ परियोजनाओं में सफलतापूर्वक अपनाए जाने के आधार पर व्यवस्थित किया गया है

वास्तविक दस्तावेज़ परियोजनाओं के उदाहरण

  • Vonage के Greg Frileux का आकलन है कि Diátaxis की मदद से वे ऐसा आंतरिक दस्तावेज़ सेट बना सके जिसे उपयोगकर्ता पसंद करें और जिसमें contributor आसानी से जोड़ सकें
  • Gatsby ने open source दस्तावेज़ों का पुनर्गठन करते समय Diátaxis framework को एक प्रमुख resource के रूप में इस्तेमाल किया, और बताया कि 4 क्षेत्रों ने प्रत्येक दस्तावेज़ प्रकार के उपयोगकर्ता लक्ष्यों को प्राथमिकता देने में मदद की
  • Cloudflare ने Cloudflare developer docs के पुनःडिज़ाइन में Diátaxis को information architecture के मानक के रूप में अपनाया, और नया content कहाँ रखा जाना चाहिए, इसका निर्णय लेते समय framework का संदर्भ लिया

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

1 टिप्पणियां

 
GN⁺ 2024-12-06
Hacker News की राय

  • पेशेवर तौर पर लिखने वाला न होते हुए भी, बारीकियों से अलग, यहां से मिली सबसे महत्वपूर्ण और बुनियादी समझ यह है कि हर बात को बिल्कुल एक ही बार कहने की जरूरत नहीं होती
    इस विचार से परिचित होने से पहले मैं खुद को उलझा लेता था, क्योंकि मानता था कि किसी एक टेक्स्ट फ्लो को ही “पूरे दस्तावेज़” की भूमिका निभानी चाहिए
    सिर्फ यह समझ लेना भी बहुत मदद करता है कि अलग-अलग पाठकों के लिए वही जानकारी अलग तरीकों से लिखी जा सकती है

    • वही बात थोड़े अलग नजरिए वाले 2–3 उदाहरणों से दिखाने पर भाषा की अस्पष्टता कुछ हद तक कम हो सकती है
      क्योंकि पाठक उदाहरणों के बीच का साझा तत्व खोजने लगते हैं, इसलिए सिर्फ एक उदाहरण से समझाने की तुलना में बात कम अस्पष्ट रहती है
      बाइबिल के Proverbs में Solomon जैसे लेखक भी इस तकनीक का खूब इस्तेमाल करते हैं
    • मेरे पादरी दोस्त अच्छे उपदेश के मूल सिद्धांत के रूप में हमेशा यह कहावत उद्धृत करते थे: “बताओ कि तुम क्या कहने वाले हो, फिर वह कहो, फिर बताओ कि तुमने क्या कहा”
    • तब चुनौती यह बन जाती है कि हर सामग्री कहां दर्ज है, इसे ट्रैक किया जाए, ताकि अपडेट करते समय सभी जगहों को साथ में सुधारा जा सके और आपस में टकराते दस्तावेज़ न बनें
    • सख्त पेज-सीमा वाले scientific papers में भी मुख्य संदेश को context और details जोड़ते हुए कई बार दोहराना बेहतर होता है
      Abstract में लिखा जाता है, “यह paper Y को Z के साथ evaluate करके दिखाता है कि X सही है”; introduction में समझाया जाता है कि A की समस्या B के कारण महत्वपूर्ण है, लेकिन X वाला पहलू अनदेखा रहा है, और Y को evaluate करने पर Z के विपरीत वास्तविक चुनौतियां सामने आती हैं; फिर “संक्षेप में, X के कारण Y, Z से बेहतर है” कहकर बात समेटी जाती है
      Related work में भी यह बताया जाता है कि Z के approach ने क्या सुधारा, लेकिन जैसा आगे दिखेगा वह पर्याप्त नहीं है; और हर section में मुख्य संदेश को बार-बार अलग ढंग से घुमाकर फिर से उठाया जाता है
    • इस विचार को और आगे बढ़ाएं तो source code खुद भी documentation जैसी ही बात एक अलग “पाठक”, यानी compiler, से उसके अपने तरीके में कह रहा है—ऐसा माना जा सकता है

  • 2 हफ्ते पहले Sequin docs पर यह framework लागू किया, और सिर्फ एक ढांचा होना ही बहुत अच्छा लगा
    अब docs का flow काफी बेहतर हो गया है, और यह पता होने की वजह से कि क्या कहां रखना है, docs जोड़ना और maintain करना भी आसान हो गया है
    हालांकि विडंबना यह है कि Diátaxis docs खुद थोड़े कठिन और लंबे-चौड़े हैं, इसलिए कुछ बार पढ़ने के बाद ही समझ आया
    टीम को समझाते समय मैंने इसे pressure cooker जैसे cooking tool खरीदने की उपमा दी: पहले quick start (tutorial) से मोटे तौर पर देखते हैं कि A से B तक कैसे जाना है; फिर आपकी पसंद की किसी खास dish को कैसे बनाना है, यह देखना how-to है; अगर कोई detail जाननी हो तो reference में अलग-अलग beans के exact cooking times देखते हैं; और जब यह जानना हो कि pressure cooking time क्यों बदलता है या safety mechanisms कैसे काम करते हैं, तब explanation material पढ़ते हैं
    मजेदार बात यह थी कि हमारी docs पूरी तरह उल्टी थीं, और “How Sequin Works” जैसी explanation से शुरू होती थीं
    इंजीनियर की स्वाभाविक प्रवृत्ति होती है कि पहले working principles और हमने इसे ऐसा क्यों बनाया, यह बताकर mental model बैठा दिया जाए; लेकिन लोगों के पास उसके लिए समय और धैर्य नहीं होता
    quick start → how-to → reference flow से उन्हें worldview में ढालना, और सच में रुचि मिलने के बाद explanation material से approach के लिए राजी करना बेहतर है
    https://sequinstream.com/docs

    • Docs का flow बहुत अच्छा लगता है
      अक्सर docs ऐसे बकवास शब्दों जैसे “innovative synergy experience” से धुंधली हो जाती हैं, मानो company यह मानने में शर्माती हो कि उसका tool बस एक tool है; या उल्टा, “यह product आखिर मौजूद क्यों है” पर बात करने से पहले ही जरूरत से ज्यादा specific details में उतर जाती हैं
      हालांकि docs में CDC बार-बार आता है और मुझे इसकी definition खोजनी पड़ी। करियर में कई बार CDC implement किया है, लेकिन acronym से परिचित नहीं था
    • चारों approaches का होना ही मुख्य बात है, और लगता है आप इसे अच्छी तरह संभाल रहे हैं
      Flow आखिरकार reader की choice है; मेरा दिमाग पहले पूरी explanation चाहता है और फिर how-to और tutorial खोजता है
    • यह analogy सच में बहुत पसंद आई, अब इस framework का फायदा पूरी तरह दिख रहा है

  • Technical writer के नजरिए से Diátaxis, DITA जैसा है: https://www.oxygenxml.com/dita/1.3/specs/archSpec/base/information-typing.html
    हालांकि ऐसे systems users की वास्तविक जरूरत को miss कर सकते हैं
    अगर technical docs केवल documentation platform के अंदर ही इस्तेमाल होनी हैं, तो Diátaxis लंबे समय तक अच्छी तरह फिट हो सकता है; लेकिन अगर वही जानकारी UI, docs portal, mobile app जैसी कई जगहों पर इस्तेमाल हो सकती है और होनी भी चाहिए, तो information को छोटे-छोटे टुकड़ों में बांटकर अलग-अलग तरीकों से assemble करना पड़ सकता है
    इसे content reuse कहते हैं, यानी वही content कई जगहों पर इस्तेमाल करना
    Content reuse के लिए information writing/editing का एक approach “every page is page one” concept में समझाया गया है: https://everypageispageone.com/the-book/
    अगर resources और समय हों, तो project की शुरुआत में UX research करने की सलाह दूंगा। इससे बाद में बहुत restrictive information model के कारण घुटन जैसी स्थिति से बचा जा सकता है
    Nielsen/Norman ने भी इस क्षेत्र पर काफी research की है, और related problems को हल करने के लिए दिलचस्प सुझाव दिए हैं: https://www.nngroup.com/articles/information-foraging/#toc-what-is-information-foraging-2

    • Diátaxis को DITA जैसा कहना मुझे ठीक से समझ नहीं आता
      DITA task, reference, concept जैसे topic types को अलग करता है, लेकिन tutorial या solution guide ऐसे topic types के combination बन जाते हैं
      यहां लगता है focus individual topics से बड़े deliverables पर है
    • LwDITA पर आपकी राय जानना चाहूंगा
      यह भी जानना चाहूंगा कि क्या आप DITA में गहराई तक गए हुए हैं, इसलिए complexity समस्या नहीं लगती
      Content को reusable pieces में तोड़कर DITA या DocBook semantics से mark up करने पर लगता है कि large language models के लिए इसे “समझना” कहीं आसान हो जाएगा, लेकिन इस बारे में कोई data नहीं देखा
    • DITA की समस्या यह है कि अक्सर इसके साथ एक बहुत opinionated proprietary toolchain आती है, भले ही वह अनिवार्य न हो
      आजकल XSL/FO और उसके रिश्तेदारों से जूझते रहने की तुलना में docs लिखने के बेहतर तरीके मौजूद हैं

  • तकनीकी दस्तावेज़ लिखने के क्षेत्र में यह पहले से ही बहुत लोकप्रिय है और काफी हद तक standard के करीब है
    हालांकि कभी-कभी लोग इसे बहुत आगे तक खींच ले जाते हैं और documentation page पर सचमुच केवल ये चार categories ही रख देते हैं, जो आमतौर पर अच्छी तरह काम नहीं करता
    यह मुख्य रूप से लेखक को यह सोच बनाए रखने में उपयोगी है कि “यह guide है, इसलिए सिखाने की कोशिश न करें, बल्कि परिणाम तक पहुँचने पर ध्यान दें”
    असलियत में बहुत कठोर सीमाएँ वांछनीय नहीं होतीं, और guide के अंदर थोड़ा tutorial होना भी ठीक है

    • कई projects के लिए चार categories में से किसी एक को भी मध्यम quality में उपलब्ध कराना improvement हो सकता है
      मुझे लगता है कि यह approach वास्तव में तब अटकती है जब quadrants के बीच linking कम होती है
      उदाहरण के लिए, किसी software framework में अगर guide अंततः इस्तेमाल की जाने वाली specific class या method के reference material से link नहीं करती, तो आसपास का context explore करना बहुत कठिन हो जाता है
      कुछ ठोस framework docs ने quadrants को इसी तरह बाँटा है, और उन docs की सबसे बड़ी झुंझलाहटों में से एक यही है
    • यह अलग करना ज़रूरी है कि अनुभवी लोग इसे आँख मूँदकर follow कर रहे हैं, या framework के beginners इसे धार्मिक नियम की तरह लागू कर रहे हैं
      अगर कोई दूसरा expert नहीं है, तो beginner के लिए “खुद समझकर सही काम करने” की बजाय rules को सख्ती से follow करना बेहतर हो सकता है
      beginner के पास परिभाषा के अनुसार वह judgement करने की expertise नहीं होती, और अनुभव बढ़ने पर वह तय rules से हटने की जगहें देखना शुरू करता है
      यह cookbook देखकर घर का खाना बनाने और किसी professional chef के अंदाज़ और taste से पतीले में ingredients डाल देने के फर्क जैसा है
    • मेरे हिसाब से methodology अंततः उपयोगी guidelines ही होनी चाहिए
      लेकिन मैंने ऐसे व्यक्ति के साथ काम किया है जो कहता था कि tutorial में एक भी explanatory sentence नहीं होना चाहिए और rules को शब्दशः follow करना चाहिए
      ऐसे systems का खतरा ठीक वहीं है
    • भले ही documentation page बहुत मजबूत boundaries बनाने की कोशिश में fail हो, परिणामस्वरूप कभी-कभी काफी high quality तक पहुँच जाता है
      यह “global variables को change न करो” या “functions को छोटा लिखो” जैसे programming principles जैसा है
      इन्हें perfectly match करने की ज़रूरत नहीं, लेकिन अधिकतर मामलों में उलटी दिशा की बजाय उसी दिशा में अधिक बढ़ना बेहतर होता है
    • हाल ही में किसी ने scikit-learn docs की तारीफ करते हुए यह page mention किया: https://scikit-learn.org/1.5/modules/grid_search.html
      इसलिए मैंने top section को Claude से Diátaxis के हिसाब से classify करने को कहा, तो उसने जवाब दिया कि यह मुख्यतः explanation है और इसमें कुछ reference material elements मिले हुए हैं, इसलिए Diátaxis criteria के हिसाब से ideal नहीं है
      उसने कहा कि hyperparameter tuning की concept और importance को शुद्ध रूप से explain करने वाला section और available tools/methods को list करने वाला अलग reference section रखना बेहतर होगा
      लेकिन इसके बाद उसने यह भी summarize किया कि यह integrated approach user guide context में क्यों अच्छी तरह काम करती है: यह लोगों के वास्तविक learning flow को follow करती है, concepts और implementation को तुरंत जोड़ती है, basic concepts से complex tools तक progressively reveal करती है, और theory व practice को जोड़कर practical value देती है

  • अपना पहला SwiftUI app release अभी-अभी पूरा करने के बाद, मुझे बहुत मजबूती से लगता है कि modern tech industry में documentation को बेहद ढीले तरीके से लिया जाता है
    Apple ने जिन शानदार technical writers को निकाला, उनके काम की बहुत याद आती है, और Apple engineers सच में docs बहुत खराब लिखते हैं
    हालांकि “dogmatic” approach से मैं हमेशा सावधान रहता हूँ। ऐसी “priest class” बनना आसान है जो वास्तविकता की मांग होने पर भी नहीं झुकती
    जिन्होंने शुरुआत में वह doctrine बनाया था, वे उसका शानदार उपयोग करते हैं, लेकिन पीछे आने वाले “priests” उसे बिगाड़कर approach को अभिशाप में बदल देते हैं
    कई अच्छे ideas बहुत rigid application की वजह से खराब हुए हैं। बस देख लीजिए कि “Agile” क्या बन गया
    docs के मूलतः दो चेहरे होते हैं: maintainers और users, और दोनों की ज़रूरतें बहुत अलग होती हैं, इसलिए शायद उन्हें पूरी तरह अलग teams संभालनी चाहिए
    अलग-अलग जगहों के docs sync से बाहर हो जाने की समस्या भी है, लेकिन महत्वपूर्ण चीज़ result है
    अगर कई instances को effectively sync किया जा सकता है, तो docs consumers के लिए effective और useful होते हैं
    perfectly formatted और synced docs भी अगर कोई नहीं पढ़ता, तो उनका कोई मूल्य नहीं है
    SNL में Phil Hartman द्वारा निभाया गया The Anal-Retentive Chef तैयारी में इतना समय लगा देता था कि actual cooking demo कर ही नहीं पाता था; tech field में भी ऐसा बहुत दिखता है
    toolchain और libraries perfect होती हैं, लेकिन वास्तव में usable नहीं होतीं
    docs मानव स्वभाव/psychology, graphic design, information architecture, technical infrastructure, publishing और distribution जैसी कई fields का मिश्रण हैं
    अधिकांश projects में docs को बाद की चीज़ की तरह treat किया जाता है, लेकिन मेरे हिसाब से requirements phase से ही उन्हें first-class consideration होना चाहिए

    • मैं Diátaxis को dogmatic approach की बजाय practical approach मानता हूँ
      document structure में कितना गहराई तक जाना है, इसका कोई अंत नहीं, लेकिन leakage points मिलने तक यह बेहतरीन training wheels की तरह काम करता है
    • मैं इस नजरिए से सहमत नहीं हूँ कि अच्छे ideas rigid application से “destroy” हो जाते हैं
      यह ऐसा लगता है मानो किसी अच्छे idea की सामान्य गलतफहमी या गलत application उस idea को ही खराब कर देती है
      इसके बजाय, actual application से अनुभव मिलता है। अगर मूल idea सच में अच्छा नहीं था, तो वह भ्रम तोड़ता है; और खराब examples, अगर गलत interpretation failure तक ले जाती है, तो उस ambiguity को उजागर करते हैं और idea को अधिक refined बनाते हैं
      हालांकि अगर खराब implementation के आदी लोग ज्यादा हो जाएँ, तो idea की popularity घट सकती है और refined implementation की demand भी कम हो सकती है
      यह idea के खुद degenerating होने से ज्यादा tragedy of the anticommons जैसा है

  • Diátaxis documentation को structure करने के लिए बेहतरीन है, लेकिन इसका असली मूल्य इस बात में है कि यह docs लिखने के तरीके को सरल बनाता है
    यह हर चीज़ को एक ही “perfect document” में ठूँसने की सोच से बाहर निकालकर यह पहचान कराता है कि अलग-अलग users की ज़रूरतें अलग होती हैं
    tutorial follow करके सीखने के लिए होता है, guide किसी specific problem को solve करने के लिए, reference तेज़ lookup के लिए, और explanation “क्यों” में गहराई से जाने के लिए
    केवल यह clarity ही उपयोगी docs लिखवा सकती है
    हालांकि कोई भी system अगर बहुत सख्ती से पकड़ा जाए, तो trap बन जाता है

    • मुझे लगता है documentation work काफी हद तक goals और expected users पर निर्भर नहीं करता क्या?
      या फिर कोई unified paradigm है, यह जानना चाहूँगा

  • हमारे organization में हम यह तरीका इस्तेमाल कर रहे हैं, और इसे अपनाने के बाद technical docs बिल्कुल अलग level पर पहुँच गए हैं
    page ownership और हर page owner की periodic review जोड़ने के बाद, यह मेरे देखे हुए technical documentation के एकमात्र सफल प्रयासों में से एक बन गया

  • मुझे लगता है कि divio में इस्तेमाल किया गया चित्र कहीं ज़्यादा intuitve है: https://docs.divio.com/documentation-system/
    हालांकि Diátaxis वाला पक्ष शायद हर अर्थ को ज़्यादा व्यापक रूप से document करता है

    • https://diataxis.fr/colophon/#origins-and-development
      Diataxis.fr का Divio rewrite वाला संस्करण graphically कम cluttered है, लेकिन मूल रूप से मुझे यह Divio में इस्तेमाल किए गए version जैसा ही लगता है
      इन दोनों materials को मैंने उनके-अपने website context में पेश किए गए ideas के मामले में practically एक ही document माना है
    • जानना चाहूंगा कि आपको Divio site वाला version बेहतर क्यों लगता है
      किस बात में वह ज़्यादा intuitive है, यह समझना चाहूंगा

  • मुझे यह idea पसंद है, और सौभाग्य से इसे बनाने वाले व्यक्ति से PyConUK में कुछ बार मुलाकात भी हुई है। वे talented और बहुत kind व्यक्ति हैं
    लेकिन documentation के अलग-अलग क्षेत्रों को इतनी सख्ती से अलग करने को लेकर मुझे थोड़ी हिचक है
    एक sprint में मुझे कभी बताया गया था कि मैं जो documentation तैयार कर रहा था, वह स्वीकार्य नहीं है क्योंकि उसमें कई formats mix हो रहे थे। स्पष्ट कर दूं, यह Daniele ने नहीं कहा था
    authority जताने की कोशिश नहीं है, लेकिन मैंने 20 साल से ज़्यादा teacher के रूप में काम किया है, और लोगों को काम पूरा करवाते हुए साथ-साथ उनकी समझ बनाने के लिए explanation और learning को scaffold करने के तरीकों की मुझे कुछ समझ है
    अगर पूरी rigidity न हो, तो यह documents कैसे बनाए जाएं और हर document type को क्या करना चाहिए, यह तय करने का एक शानदार tool है
    documentation examples में, जैसे numpy में, अक्सर देखता हूं कि “आसमान से उतरा जादू” जैसे examples की जगह कहीं बेहतर choices हो सकती हैं
    अच्छी तरह चुना गया एक example usage दिखाते हुए भी corner cases या सावधानियों तक बहुत कुछ सिखा सकता है

  • Theory में यह सही लगता है, लेकिन सहमत होना मुश्किल है। शब्द बहुत पास-पास हैं
    मेरे लिए “tutorial”, “how-to guide”, “explanation” असल में लगभग synonyms जैसे लगते हैं
    गहराई से सोचूं तो समझ आता है कि हर category के पीछे valid reason है, लेकिन semantic रूप से ये इतने पास हैं कि दिमाग फर्क देख नहीं पाता
    जब मैं जानना चाहता हूं कि कोई चीज कैसे काम करती है और “tutorial” व “how-to guide” दिखते हैं, तो समझ नहीं आता किस पर click करूं, और बस पहले वाले पर click कर देता हूं

    • अगर labels का वह set fit नहीं बैठता, तो Diataxis document फर्क समझाने के लिए कई और तरीके भी देता है
      अपने लिए बेहतर fit होने वाली terminology ढूंढना भी एक उपयोगी exercise हो सकती है
      या इसे action/cognition, यानी “करना vs सोचना”, और acquisition/application, यानी “सीखते समय vs काम करते समय” के distinction के रूप में भी समझ सकते हैं
      tutorial और how-to guide को अलग करने वाला dedicated page भी है: https://diataxis.fr/tutorials-how-to/
      सबसे simple distinctions में से एक यह है कि tutorial वह है जो Stack Overflow पर नहीं किया जा सकता
      tutorial में आप teacher द्वारा तय lesson plan follow करते हैं, और यह student के उन gaps को भरता है जिनके बारे में student को पता भी नहीं होता कि वे नहीं जानते
      Stack Overflow पर आपको question पूछना पड़ता है, लेकिन tutorial उन लोगों के लिए material है जिन्हें अभी यह भी नहीं पता कि क्या पूछना है
      simple task कैसे करें, ऐसे popular questions भी बहुत हैं, लेकिन उस format में fit होने के लिए मदद की vague request नहीं, बल्कि question पूछना पड़ता है: https://meta.stackoverflow.com/questions/284236
    • Terms similar लगते हैं क्योंकि सालों से अनगिनत खराब explanations ने दिमाग में उनके meaning को धुंधला कर दिया है
      Diátaxis document फर्क को काफी efficiently समझाता है: tutorial learning-oriented experience है, how-to guide goal-oriented directions हैं, reference information-oriented technical description है, और explanation understanding-oriented discussion है
    • चार अलग concepts को अलग करना था और हर एक को नाम चाहिए था, इसलिए शायद map पर labels के लिए चार ऐसे words चुने गए जो लगभग synonyms जैसे दिखते हैं
      इस system में “tutorial” को everyday word नहीं बल्कि technical term की तरह पढ़ना चाहिए
      जैसे psychologist के कहे “depression” का अर्थ everyday meaning से बिल्कुल समान नहीं होता
      फिर भी Type I-IV tutorial नाम देने से तो बेहतर है
    • मुझे सच में शक है कि ये इतने करीब हैं
      lecture explanation है, tutorial या hands-on guided experience है, और Microsoft की fake company Contoso याद आती है
      how-to guide वह है जिसकी जरूरत solution search करते समय या ChatGPT से पूछते समय होती है, और reference thesaurus, encyclopedia, user manual जैसी चीज है
      video games में built-in tutorial होता है, लेकिन कठिन puzzles के लिए walkthrough फिर भी चाहिए, और key bindings reference में देखे जाते हैं
    • यह भी ज़रूरी है कि कोई अच्छा writer हो जो सिर्फ examples से ही पूरी तरह साफ कर दे कि क्या क्या है