लोगों को बात करने के लिए लिंक करने लायक चीज़ देना
(simonwillison.net)- अगर आप चाहते हैं कि लोग किसी प्रोजेक्ट या प्रोडक्ट फीचर को समझें और साझा करें, तो बार-बार समझाने से पहले एक समर्पित वेबपेज होना ज़रूरी है
- ChatGPT Code Interpreter एक शक्तिशाली फीचर होने के बावजूद, आधिकारिक दस्तावेज़ों में उसके नाम और discoverability को लेकर असंगति रही, इसलिए किसी और द्वारा बनाया गया विवरण अधिक उपयोगी लिंक बन गया
- Claude Artifacts और GitHub Codespaces·Copilot के उदाहरण दिखाते हैं कि जब कोई फीचर लिंक करने लायक लक्ष्य बन जाता है, तब उसे साझा करना और समझाना आसान हो जाता है
- Dan McKinley की Boring Technology की तरह, जब किसी अवधारणा को अलग पेज में व्यवस्थित किया जाता है, तो पहली बार सुनने वाला भी सिर्फ एक लिंक से संदर्भ जल्दी समझ सकता है
- समर्पित पेज की उपयोगिता सिर्फ search visibility तक सीमित नहीं है, बल्कि वेब पर बातचीत में वही बात बार-बार दोहराने की ज़रूरत कम करने में भी है
लिंक करने लायक पेज की ज़रूरत क्यों है
- जिन चीज़ों—जैसे प्रोजेक्ट, आइडिया, या प्रोडक्ट फीचर—को आप चाहते हैं कि दूसरे लोग समझें और उनके बारे में बात करें, उनके लिए लिंक करने लायक पेज होना चाहिए
- हाइपरलिंक वेब पर बातचीत को बढ़ाने का बुनियादी साधन है, क्योंकि इससे हर बार नई व्याख्या लिखने के बजाय किसी निर्णायक व्याख्या से जोड़ा जा सकता है
- अगर समर्पित पेज नहीं है, तो रुचि और search traffic किसी और द्वारा लिखी गई व्याख्या या ऐसे पेजों की ओर जा सकती है जिन्होंने पहले ही खोज शब्दों पर कब्ज़ा कर लिया हो
ChatGPT Code Interpreter की discoverability समस्या
- ChatGPT Code Interpreter ऐसा फीचर है जो ChatGPT को जवाब देने की प्रक्रिया में Python कोड लिखने और चलाने देता है
- फीचर खुद बहुत शक्तिशाली है, लेकिन अगर आपको इसे prompt से सक्रिय करने का तरीका न पता हो, तो इसके अस्तित्व का पता लगाना मुश्किल है
- OpenAI साइट पर Code Interpreter खोजने पर API फीचर से जुड़े तकनीकी दस्तावेज़ या पुराना फ़ोरम थ्रेड मिलता है, जो भ्रम पैदा करता है
- इस फीचर का परिचय कराते समय OpenAI के आधिकारिक पेज से अधिक उपयोगी लिंक code-interpreter टैग पेज बन जाता है
- बाद में वास्तविक दस्तावेज़ मिला, लेकिन उसका शीर्षक Data analysis with ChatGPT था, और पेज में “Code Interpreter” शब्द ही नहीं था, इसलिए उसे खोजना कठिन था
- OpenAI इस फीचर का नाम लगातार Code Interpreter, Advanced Data Analysis, और Data analysis with ChatGPT के बीच बदलता रहा है
अच्छे फीचर पेज के उदाहरण
- Claude के Artifacts फीचर के लिए कम से कम एक आसानी से मिलने वाला help page मौजूद है
- हालांकि Artifacts announcement post को Claude 3.5 Sonnet की घोषणा के साथ साझा किया गया, इसलिए उसे सिर्फ Artifacts के स्पष्ट लिंक लक्ष्य के रूप में देखना कठिन है
- GitHub अलग-अलग फीचर्स के लिए अलग landing page देता है
- जब किसी फीचर के लिए अलग समर्पित पेज होता है, तो लिंक करने और साझा करने के समय व्याख्या का एक स्पष्ट संदर्भ बिंदु मिल जाता है
Boring Technology: जब एक अवधारणा वेबसाइट बन गई
- Dan McKinley ने 2015 के Choose Boring Technology निबंध में Boring Technology शब्द गढ़ा था
- मुख्य विचार यह है कि डेवलपमेंट टीम की नई समस्याएँ सुलझाने की क्षमता सीमित होती है, इसलिए उस क्षमता का उपयोग उन हिस्सों पर होना चाहिए जो प्रोडक्ट को विशिष्ट बनाते हैं
- बाकी क्षेत्रों में ऐसी सबसे साधारण और अच्छी तरह जानी-पहचानी तकनीक चुननी चाहिए, जिसके bugs और limitations लंबे समय से ऑनलाइन समझे और चर्चा किए जा चुके हों
- इस विचार को boringtechnology.club नाम की वेबसाइट में भी व्यवस्थित किया गया है
- अगर कोई इस शब्द से परिचित न हो, तो सिर्फ एक लिंक साझा करके उसे कुछ ही मिनटों में संदर्भ समझाया जा सकता है
व्यक्तिगत आइडिया को भी साझा करने लायक पेज चाहिए
- baked data, git scraping, और prompt injection जैसे विचार भी ऐसे पेजों में व्यवस्थित हैं जिन्हें बार-बार साझा किया जा सकता है
- हालांकि अलग domain न होने पर “यही वह मुख्य पेज है जिसे लिंक करना चाहिए” वाला संदेश कुछ कमजोर पड़ सकता है
- स्पष्ट लिंक लक्ष्य किसी आइडिया की shareability और उसके आसपास बातचीत की संभावना दोनों बढ़ाता है
SEO से भी ज़्यादा, बातचीत में दिखने वाली उपयोगिता
- समर्पित पेज का एक स्पष्ट उद्देश्य SEO है
- जब उपयोगकर्ता किसी प्रोडक्ट फीचर को खोजें, तो उन्हें किसी और द्वारा बनाए गए पेज के बजाय आपकी अपनी साइट पर आना चाहिए
- लेकिन इसकी बड़ी उपयोगिता बातचीत में दिखती है
- किसी अवधारणा को समझाते समय पूरा पैराग्राफ फिर से लिखने के बजाय, आप एक ऐसा लिंक साझा कर सकते हैं जिसमें निर्णायक व्याख्या मौजूद हो
- अगर आप चाहते हैं कि लोग किसी आइडिया, प्रोजेक्ट, या फीचर को समझें और उस पर चर्चा करें, तो उसके अनुरूप एक वेबपेज बनाना चाहिए
1 टिप्पणियां
Hacker News की राय
rsync.net ऐसी चीज़ें अच्छी तरह करता है। उदाहरण के लिए, मुझे याद नहीं कि किसी और सेवा में CEO page जैसा कुछ देखा हो।
पता नहीं यह असल में कितना उपयोगी है, और मुझे कभी CEO तक कुछ पहुँचाना भी नहीं पड़ा, लेकिन ग्राहक न होने के बावजूद यह लेख पढ़ते ही सबसे पहले यही पेज याद आया।
[1]: https://www.rsync.net/products/ceopage.html
यह पेज इस तरह बनाया जाता है कि attendee को खुद कोई ठोस business justification गढ़ने की ज़रूरत न पड़े, बल्कि वह इसे सीधे अपने manager को भेज सके।
OpenAI के स्तर की कंपनी से अब तक technical writer hire कर लेने की उम्मीद होती है, लेकिन LinkedIn के हिसाब से ऐसा नहीं लगता। इसलिए documentation की हालत इतनी खराब होना बहुत चौंकाने वाला भी नहीं है।
समझ नहीं आता कि वे dedicated documentation role क्यों नहीं hire करते। या तो वे इसे महत्वपूर्ण नहीं मानते, या documentation के ऊपर growth को सख्ती से प्राथमिकता देते हैं; वजह जो भी हो, अंत में वे अपना ही नुकसान कर रहे हैं।
लेख में https://boringtechnology.club/ का संदर्भ है; यह एक शानदार slide deck है, जो कहता है कि innovation effort सिर्फ unique solutions के लिए बचाकर रखो।
बाकी सबके लिए जितना हो सके boring technology अपनानी चाहिए। मैंने बहुत बार देखा है कि development teams नीचे तक हर चीज़ में innovation करने लगती हैं और फिर असल में वे क्या value दे रही हैं, इस पर focus खो देती हैं। मैं इस slide deck को अपने worldview में गहरा उतार लेना चाहता हूँ।
Simon का एक और अच्छा लेख। कल रात मैंने यह concept एक नए project में सीधे डाल दिया। मैं यह evidence दिखाना चाहता था कि Google Gemini App yt-dlp को censor करता है, लेकिन Gemini API ऐसा नहीं करता; साथ ही project के लिए inbound path और Simon ने जो business-side reasons बताए, वे भी बनाना चाहता था।
https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
साथ ही मैंने localStorage का इस्तेमाल करके visited public chats की list save करवाई। वापस आने पर आप वे दूसरे chats देख सकते हैं जिन्हें आपने पढ़ा था, और यह ढूँढना भी आसान है कि original link कहाँ से मिला था, बजाय इसके कि message history खंगालनी पड़े।
Dead links सबसे खराब होते हैं। क्या कोई GPT से dead link की website hallucinate कर देने वाला browser extension नहीं बना सकता?
कलाकार अक्सर सिर्फ social media sites को link कर देते हैं, लेकिन accounts suspend हो सकते हैं और usernames बदल सकते हैं। developers भी dependencies को “link” करते समय यह नहीं सोचते कि repository गायब हो सकती है, और अगर किसी ने backup नहीं लिया तो उस version का source code भी साथ में गायब हो सकता है; package version registry से हट सकता है या dependency की online documentation गायब हो सकती है।
[1]: बस manifest file में name+version जोड़ देना और हमेशा के लिए भूल जाना। cache जोड़ भी दें तो वह ठीक-ठाक mirror नहीं होता, और आपदा की स्थिति में dependencies खुद build कर सकने का तरीका तो बिल्कुल नहीं।
अगर लोग एक-एक करके बताते रहें कि वह page पहले कैसा दिखता था, या clues ढूँढने के लिए web crawl करें, तो यह काफी interesting idea होगा। “under construction” banner भी वापस लाया जा सकता है।
मुझे Simonw blog पसंद है। पिछले साल September से मैं Python interpreter का इस्तेमाल करके उनका blog पढ़ रहा हूँ। उन्होंने कहा था कि वे पूरा application तुरंत बनाने की कोशिश में अकेले ही ऐसा करना शुरू कर बैठे थे।
हालांकि मुझे अभी भी साफ नहीं है कि यह कैसे किया जाता है। लगा था कोई आसान option या button होगा, लेकिन मिला नहीं। मैं और कोशिश करके पता लगा सकता था, लेकिन अगर कोई convenient link या tutorial होता तो शायद GPT को अधिकतर ignore करने के बजाय उसे इस्तेमाल करता रहता।
इस context में Square का incident response meme https://outage.party/ पर अब भी जिंदा है।
Microsoft के कई products से मुझे ठीक इसी वजह से सचमुच नफ़रत थी। VSTS/VSO/Dev Ops जैसे बार-बार नाम बदलने वाले products या Sharepoint वगैरह खास तौर पर भयानक थे। एक deep link 700 characters का होता था, उसमें दर्जनों base64 query strings और बेतुके paths लगे होते थे। “समस्या क्या है? URL shortener इस्तेमाल कर लो न? URL तो वैसे भी लंबे होते हैं, कुछ नहीं कर सकते” — इस तरह की बातों से पागल होने जैसा लगता था।
2014 में हमारी team का internal tool system resources की स्थिति दिखाता था, और सभी resources व उनकी states SQL database में थीं। लेकिन webapp router जैसी चीज़ें आने से पहले वाला SPA था और न URL update करता था, न deep links support करता था। किसी खास resource issue को email या messenger पर भेजना हो तो समझाना पड़ता था: “X tool पर जाओ, Y search करो और Z -> W -> M -> O -> K दबाओ, वहाँ दिखेगा।” मुझे बहुत गुस्सा आता था कि बस https://X.com/Y/Z/W/M/O/K link से गहराई में nested state share क्यों नहीं कर सकते। कई बार कहने पर भी जवाब यही मिला कि “यह priority नहीं है और इतनी बड़ी बात भी नहीं है।”
एक बार मुझे 2 हफ्ते तक वह चीज़ ठीक करने का मौका मिला जिसे मैं सुधारना चाहता था, और मैंने deep links support करने वाला alternative बनाने का फैसला किया। साथ ही सभी deep links में
/api/prefix लगाने पर content JSON के रूप में return करने की सुविधा भी दी। team और company में यह बहुत hit हुआ, और मेरा tool कहीं ज़्यादा simple और कम features वाला होने के बावजूद X tool का usage लगभग रातोंरात घट गया। आखिरकार ज़्यादातर लोग “गहराई से जांच-पड़ताल करने वाला powerful SPA” नहीं, बल्कि links आसानी से share करने का तरीका चाहते थे।एक महीने बाद X tool team ने company-wide email में बड़े जोर-शोर से deep links support करने की घोषणा की। लेकिन
/api/prefix से JSON data return करने वाली simple functionality को उन्होंने important नहीं माना। 5 साल बाद मेरे tool का UI पुराना पड़ गया था, लेकिन असली service को core internal service का दर्जा मिल गया क्योंकि कई teams ने/api/prefix URLs के इर्द-गिर्द automation बना लिया था, और आखिर में उसी team को code लेकर maintain करना पड़ा।Simonw fan के तौर पर एक बात कहना चाहूंगा जिसे अभी तक किसी ने नहीं उठाया: Simon लोगों को link करने लायक targets देने के जो दूसरे examples बनाते हैं, वे HN पर भी बहुत effective हैं: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Simon अक्सर AI side की ongoing खबरों को बहुत तेजी से summarize करते हैं—ऐसी खबरें जिन्हें करीब से जुड़े लोग तो पहले से जानते हैं, लेकिन broader audience अभी नहीं जानती। वे संबंधित facts को जल्दी linkable और accessible बना देते हैं, ताकि उस मामले से दूर बैठे लोग भी चर्चा कर सकें।
“हाइपरलिंक वेब की सबसे अच्छी चीज़ हैं” — इस बात से सहमत हूं. सटीक कहें तो यह हाइपरलिंक और URL हैं.
URL वेब की बुनियाद हैं. वे लेखों और दूसरे resources को सटीक, सार्वभौमिक होने की उम्मीद वाले, और लंबे समय तक टिकने की उम्मीद वाले तरीके से संदर्भित करने देते हैं. लोगों को इसकी शानदारियत न समझते देखना हमेशा खीझ पैदा करता है. जैसे, किसी message में link paste करने के बजाय “YouTube पर इसे search करो” कहना. अगर किसी लेख को वेब पर स्थायी ठिकाना दे दिया जाए, तो visibility भी बढ़ती है और लेखक को वही विचार फिर से लिखने की जरूरत भी कम होती है.
संबंधित classic essay: Cool URIs don't change. [0][1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://news.ycombinator.com/item?id=23865484
व्यवहार में असर यह होता है: अगर आप किसी से बातचीत में हों या किसी presentation के Q&A में कहना चाहें, “हां, हमने भी उस पर सोचा है और acmeinitiative.example.com/skub पर संबंधित जानकारी है”, लेकिन आपने अभी तक
/skubलेख नहीं लिखा है, तब भी उसी मौके पर तुरंत/skubको उस लेख का तय handle घोषित किया जा सकता है. लेख बाद में लिखेंगे तो वहीं दिखाई देगा, और इच्छुक लोग कभी भी उस URL से उसे ढूंढ पाएंगे. किसी दूसरे व्यक्ति के लेख या बाहरी resource के लिए भी यही बात लागू होती है: अपने namespace में तुरंत URL बना लें और बाद में समय मिलने पर original link पर redirect कर दें.recordings, podcasts वगैरह में, जहां साफ दिखता है कि बोलने वाले स्मार्ट technologists अपने domain के मालिक हैं, मैंने बहुत बार देखा/सुना है कि वे यह तरीका नहीं अपनाते. आम तौर पर वे कोई ऐसा description बुदबुदाते हैं जिसे शायद ढूंढा जा सके, या title याद करने की कोशिश में आधा गलत बोल देते हैं. फिर हर इच्छुक listener को अपनी-अपनी time और attention खर्च करके उसे ढूंढना पड़ता है, और सामूहिक रूप से भारी ऊर्जा बेकार चली जाती है.
FB copyright content sharing के नाम पर random blogs तक कई sites को block करता है, और reddit सभी
.ru, कई archive sites, Telegram links आदि को block करता है. Twitter ने कुछ blog platforms को block किया था, और छोटी sites भी अक्सर Discord को block करती हैं. Discord blocking को जायज़ ठहराया जा सकता है, लेकिन अच्छा होगा अगर यह trend लोगों को वहां से निकलने की वजह बने.पहला, यह तुरंत AOL Keyword जैसी अजीब-सी खराब feeling जगाता है. दूसरा, यह search bubble की अवधारणा को पूरी तरह नजरअंदाज करता है. वही search term डालने पर भी आपको और मुझे मिलने वाले results काफी अलग हो सकते हैं. तीसरा, जब URL और hyperlink मौजूद हैं, तो मुझसे अतिरिक्त काम करवाने की जरूरत नहीं. सीधे link करेंगे तो मैं ढेरों reaction videos के बीच भटके बिना देख पाऊंगा कि आप असल में किस चीज़ का संदर्भ दे रहे थे.
लेकिन कई sites और services को यह पसंद नहीं है. वे इसे अपने attention territory में दखल मानती हैं. एक लेखक के रूप में, अगर मैं किसी ऐसे विचार का link दूं जिसे मैंने पहले ही किसी blog post या किताब में सावधानी से व्यक्त किया है, तो “promotion” के नाम पर comment हटा दिया जाता है या censor कर दिया जाता है. आजकल HN पर सज़ा से बचने के लिए, पाठकों को और गहराई में जाने के लिए link देने के बजाय, मैं अक्सर अपने लिखे original text को बस copy-paste कर देता हूं. जानकारी फैलाने के जिस अच्छे “academic” तरीके का हम प्रचार करते हैं और expression को control करने वाले systems की वास्तविकता के बीच साफ gap है.