- जटिल और लंबी चर्चाएँ, चाहे आमने-सामने हों, चैट में हों या फ़ोरम में, आवेगपूर्ण प्रतिक्रियाओं और संरचना की कमी के कारण आसानी से पटरी से उतर जाती हैं
- Discourse में टिप्पणियाँ समयक्रम में जुड़ती जाती हैं, जिससे स्थानिक संदर्भ खोना आसान हो जाता है, और Slack सिर्फ़ एक-स्तरीय थ्रेड सपोर्ट करता है, इसलिए उसमें गहरी चर्चा समेटना मुश्किल है
- उद्धरणों के सहारे जवाबों के संबंध बनाए रखने का तरीका, जैसे-जैसे प्रतिभागी बढ़ते हैं, चर्चा की संरचना को दिमाग़ में ट्रैक करने पर मजबूर करता है, और यही quote hell तक ले जाता है
- CQ2 किसी खास उद्धरण या पूरी टिप्पणी को आधार बनाकर थ्रेड के भीतर थ्रेड बनाता है, और संबंधित जवाबों व ऊपरी संदर्भ को एक ही स्क्रीन पर दिखाता है
- यह अभी शुरुआती चरण का मुफ़्त ओपन सोर्स टूल है, और मोबाइल के लिए अभी ऑप्टिमाइज़ नहीं है, इसलिए इसे डेस्कटॉप या लैपटॉप पर आज़माना ज़्यादा व्यावहारिक है
जटिल चर्चाएँ कहाँ कठिन हो जाती हैं
- कार्यस्थल की रणनीतिक चर्चाएँ, AI alignment, तकनीकी डिज़ाइन दस्तावेज़, और सार्वजनिक नीति जैसे ऐसे विषयों में यह समस्या खास तौर पर दिखती है जहाँ लंबे संदर्भ की ज़रूरत होती है
- बार-बार सामने आने वाली रुकावटें हैं आवेगपूर्ण प्रतिक्रियाएँ और संरचना की कमी
- आमने-सामने की चर्चा तुरंत प्रतिक्रिया देने के लिए उकसाती है और उसमें चर्चा की संरचना बनाए रखना कठिन होता है, इसलिए जटिल विषयों को गहराई से लेने में उसकी सीमाएँ हैं
- सक्रिय रूप से सुनना आदर्श समाधान हो सकता है, लेकिन यह मानना मुश्किल है कि वह हर टीम और हर स्थिति में हमेशा काम करेगा
- लिखित, असिंक्रोनस चर्चा प्रतिक्रिया की गति को धीमा कर सकती है, और अगर slow mode जैसी सुविधाएँ हों तो वे अधिक सोच-समझकर जवाब देने के लिए प्रेरित कर सकती हैं
- लेकिन अगर असिंक्रोनस चर्चा में भी संरचना की कमी हो, तो लंबी चर्चा को फ़ॉलो करना कठिन रहने की समस्या बनी रहती है
Slack और Discourse की संरचनात्मक सीमाएँ
- Discourse की चर्चा बिना व्यवस्थित टिप्पणी-धारा की तरह चलती है
- कई लोग एक साथ बोलते हैं और विषय मिलते-जुलते जाते हैं; यह तरीका जटिल और लंबी विषय-वस्तु में गहराई तक जाने के लिए उपयुक्त नहीं है
- टिप्पणियाँ समयक्रम में सॉर्ट होती हैं, इसलिए चर्चा में “आप कहाँ हैं” की तुलना में “यह कब पोस्ट हुआ” ज़्यादा स्पष्ट दिखता है
- किसी खास टिप्पणी के जवाब एक जगह देखे जा सकते हैं, लेकिन उन जवाबों पर आए आगे के जवाब देखने के लिए दूसरी टिप्पणियों के बीच स्क्रॉल करना पड़ता है
- Slack लिखित असिंक्रोनस चर्चा के लिए बना टूल नहीं है, फिर भी इसका व्यापक उपयोग होता है
- किसी खास टिप्पणी पर अलग पैनल में थ्रेड के रूप में चर्चा की जा सकती है
- लेकिन थ्रेड के भीतर की टिप्पणी को फिर अलग थ्रेड नहीं बनाया जा सकता, इसलिए चर्चा एक-स्तरीय थ्रेड में फँस जाती है
- इसका UI लंबी असिंक्रोनस चर्चा की तुलना में छोटे और तेज़ कमेंट समूह भेजने के लिए अधिक उपयुक्त लगता है
- typing indicator तब दूसरे लोगों का ध्यान भटका सकता है जब कोई व्यक्ति अपने विचारों को व्यवस्थित कर रहा हो
जब उद्धरण संरचना की जगह लेते हैं: quote hell
- चैट और फ़ोरम टूल्स में आम तौर पर दिखने वाली समस्या है quote hell
- इसका सामान्य प्रवाह सरल है
- Ava किसी विषय पर एक टिप्पणी लिखती है
- Caleb, Ava की टिप्पणी के एक हिस्से को उद्धृत करके जवाब देता है
- Ava फिर Caleb के जवाब को उद्धृत करके उत्तर देती है
- इस तरीके में एक ही विषय पर प्रतिक्रियाएँ कई टिप्पणियों में बिखर जाती हैं, और उपयोगकर्ता को उद्धरणों और जवाबों के रिश्ते खुद ट्रैक करने पड़ते हैं
- बीच में असंबंधित टिप्पणियाँ भी आ जाएँ तो चर्चा का प्रवाह आसानी से टूट जाता है
- दो लोगों के बीच की चर्चा में यह बहुत स्पष्ट नहीं दिख सकता, लेकिन 5 या उससे अधिक लोगों वाली लंबी और जटिल चर्चा में भ्रम तेज़ी से बढ़ता है
CQ2 द्वारा प्रस्तावित चर्चा संरचना
- CQ2 जटिल चर्चाओं के लिए बनाया गया एक मुफ़्त ओपन सोर्स टूल है और अभी शुरुआती चरण में है
- LessWrong की छोटी चर्चा को CQ2 में सिम्युलेट करने पर यह अधिक व्यवस्थित और फ़ॉलो करने में आसान लगा
- इसकी मुख्य बात है थ्रेड के भीतर फिर से थ्रेड बनाने की संरचना
- यह हर थ्रेड को एक ही विषय पर टिके रहने में मदद करती है
- किसी खास उद्धरण को केंद्र में रखकर नया थ्रेड बनाया जा सकता है और उससे जुड़े जवाब एक ही जगह देखे जा सकते हैं
- मौजूदा थ्रेड के सभी ऊपरी थ्रेड उसी स्क्रीन पर देखे जा सकते हैं, इसलिए स्थानिक संदर्भ नहीं खोता
- CQ2 के tree के माध्यम से उन थ्रेड्स पर जल्दी जाया जा सकता है जिनमें अनपढ़ी टिप्पणियाँ हैं, जो निष्कर्ष तक पहुँच चुके हैं, या किसी खास थ्रेड पर सीधे पहुँचना हो
- सुलझे हुए थ्रेड्स और पूरी चर्चा, दोनों में निष्कर्ष जोड़ा जा सकता है
उपयोग का प्रवाह और आने वाले फीचर्स
- चर्चा शुरू करते समय शीर्षक और विवरण दर्ज किया जाता है
- विवरण छोटा या लंबा हो सकता है, और चर्चा शुरू होने से पहले संदर्भ, ज़रूरी जानकारी और विचार देने के लिए इस्तेमाल होता है
- इसके बाद प्रतिभागियों के साथ लिंक साझा किया जाता है
- सामान्य टिप्पणियाँ सबसे पहले और सबसे बाएँ मौजूद main thread में लिखी जाती हैं
- अगर किसी खास टेक्स्ट का जवाब देना हो, तो विवरण या टिप्पणी में टेक्स्ट चुनकर “Reply in new thread” बटन से उसी उद्धरण पर केंद्रित नया थ्रेड बनाया जाता है
- पूरी टिप्पणी का जवाब देना हो तो टिप्पणी के ऊपर दाईं ओर मौजूद reply बटन इस्तेमाल किया जा सकता है
- अगर किसी खास उद्धरण पर पहले से कोई थ्रेड हो, तो वह उद्धरण हाइलाइट दिखता है; उस पर क्लिक करके वह थ्रेड खोलकर चर्चा आगे बढ़ाई जा सकती है
- अगर पूरी टिप्पणी पर कोई थ्रेड हो, तो टिप्पणी के ऊपर दाईं ओर comments बटन हाइलाइट होता है, और उस पर क्लिक करके संबंधित थ्रेड खोला जा सकता है
- थ्रेड के बीच नेविगेशन trackpad scroll या
shiftकुंजी और mouse wheel से किया जा सकता है - नेविगेशन बार का tree किसी खास थ्रेड पर जल्दी जाने देता है, और हर थ्रेड के लिए टिप्पणियों की संख्या, अनपढ़ी टिप्पणियों की संख्या, और निष्कर्ष हुआ है या नहीं, यह दिखाता है
- “Conclude thread” बटन से थ्रेड को समाप्त किया जा सकता है, और निष्कर्ष वाले थ्रेड हरे बैज और हरी निष्कर्ष टिप्पणी के साथ दिखते हैं
- पूरी चर्चा को नेविगेशन बार के “Conclude discussion” बटन से समाप्त किया जाता है
- आने वाले फीचर्स में rich text, workspaces, thread custom title, mentions, slow mode, उपयोगी reactions, और ऐसा AI assistant शामिल है जो चर्चा में छूटी हुई बातों को ढूँढने में मदद करेगा
- CQ2 अभी मोबाइल उपयोग के लिए ऑप्टिमाइज़ नहीं है, इसलिए इसे डेस्कटॉप या लैपटॉप पर ही इस्तेमाल करना चाहिए
- Early access Tally फ़ॉर्म के ज़रिए मिल सकता है
1 टिप्पणियां
Hacker News की राय
जटिल चर्चा के टूल तो असल में Usenet newsreader में काफ़ी हद तक हल हो चुके थे, ऐसा मुझे लगता है
thread structure साफ़ दिखता था, एक स्क्रीन पर करीब 50 posts की संरचना देखी जा सकती थी, unread threads और posts highlight होते थे, और Tab दबाने पर अगली unchecked post पर चला जाता था
read status भी time के आधार पर नहीं, बल्कि post/comment के स्तर पर था, और तेज़ navigation, filtering जैसी सुविधा वाले features भी कहीं ज़्यादा थे
बाद के discussion platforms आम तौर पर usage efficiency और गहरी, लंबे समय तक चलने वाली चर्चा की क्षमता में पीछे चले गए; शुरू में वजह web browser की सीमाएँ थीं और बाद में mobile touch interface, ऐसा मुझे लगता है
top/bottom quoting आपस में गड्डमड्ड होते थे, threads टूट जाते थे, posts गायब हो जाती थीं, और लोगों का कई दिनों तक एक-दूसरे से अलग दिशा में बात करना आम था
मुझे Usenet सच में बहुत पसंद था और वही मेरे career की शुरुआत थी, लेकिन मुझे उसकी याद नहीं आती
posting, moderation, sorting, किसी खास व्यक्ति को follow करने जैसे basic features से पहले भी, topic discussion का बुनियादी अनुभव आज Usenet के वैध उत्तराधिकारी Reddit से खराब था
किसी बिंदु पर एक thread, दूसरे thread में चल रही parallel discussion की वजह से निरर्थक हो सकता है, और अगर दूसरे thread के किसी खास point तक आसानी से ले जाया जा सके तो बहुत मदद मिलती
लेकिन इसके लिए URL चाहिए था, और message ID उस काम के लिए इस्तेमाल नहीं होते थे
किस्सों के आधार पर कहूँ तो high school या university level classes के online discussion forum चलाने के लिए यह काफ़ी अच्छा दिखता है
इसकी reputation खराब है, लेकिन ऐसी चर्चाओं के लिए imageboard-style comments सबसे बेहतर लगते हैं
हर post की एक unique ID होती है, और अपनी post में दूसरी post का link डाल सकते हैं
फिर हर post के साथ backlinks जुड़ जाते हैं जो उसे quote करने वाली सभी posts दिखाते हैं, और posts time order में दिखते हुए भी अपेक्षाकृत आसानी से navigate किए जा सकने वाला hyperlink network बनाते हैं
लंबे post वाली discussions में यह काफ़ी प्रभावी था, बस अफ़सोस यह है कि structure अनावश्यक रूप से restrictive है
बेहतर होगा अगर posts बस एक linked graph बनाएं, और website उसे किसी भी मनचाहे तरीके से दिखा सके
इस project का layout Xanadu की बहुत याद दिलाता है, लेकिन मुझे नहीं लगता कि इतना complex interface ज़रूरी है
बल्कि यह productive discussion में बाधा भी बन सकता है
character limit या reply depth limit जैसे दूसरे media के constraints अक्सर clarity में मदद करते हैं, और लोगों के बीच information transfer मूल रूप से linear होता है, इसलिए आखिरकार छोटे essays लिखना और उन्हें exchange करना ही actual discussion की बुनियाद बनता है
ज़्यादातर users के लिए सबसे बड़ी बाधा comments के बीच आना-जाना है, और सामने वाला किस बात का जवाब दे रहा है यह देखने में कुछ seconds extra लगना भी interest खत्म कर सकता है
गलती से गलत जगह click कर दें या back बहुत बार दबा दें, तो पढ़ने की जगह खो देना भी आसान है
जब कई conversations साथ-साथ चल रही हों, तो किसी खास conversation पर लोग क्या कह रहे हैं, इसे follow करना मुश्किल होता है
thread का history follow करने के लिए unrelated comments को filter करना और duplicate quotes को ignore करना, cognitive load बढ़ाता है
नए तरीके में जिन posts में interest नहीं है, उन्हें सिर्फ एक बार देखना पड़ेगा
यह整理/organization के काम को लगभग एक format में बदल देता है
मेरे हिसाब से अभी भी 4chan-style linear timeline सबसे अच्छी है
बस
>references को follow करना आसान बनाने के लिए मजबूत UI support चाहिएयह app, HN और Reddit “thread के अंदर thread के अंदर thread” वाले tree को चुनते हैं, जो तब बहुत खराब होता है जब आप एक ही parent comment के कई replies के कुछ हिस्सों का एक साथ जवाब देना चाहते हैं
सुधार के लिए इस structure की DAG nature को स्वीकार करना होगा, और comment जिन parent nodes को reply कर रहा है उनका set सीधे चुन सकना चाहिए
उससे भी ज़रूरी है कि उस set को editable बनाया जाए
जब कोई व्यक्ति पहले से discuss हो चुके topic पर नए comment में जवाब देता है, तो “यहाँ मेरा reply देखो” वाला नया comment डालने की ज़रूरत न हो; पुराने answer को नए parent से जोड़ सकना चाहिए
ज्यादा participation वाली discussions में आपस में लगभग unrelated subthreads बनना स्वाभाविक है, और ऐसे cases में linear structure बहुत खराब है
एक reply hide करने पर उस reply पर आए पूरे reply chain को भी automatically hide किया जा सकता है
अगर LLM nodes में metadata जोड़ दे, तो यह और दिलचस्प हो सकता है
उदाहरण के लिए मान लें A statement Sa पेश करता है, B उसका Sba से और C Sca से जवाब देता है
नए जुड़ने वाले लोग देख सकते हैं कि Sba, Sa के ज़्यादातर हिस्से से सहमत है लेकिन किसी खास fact का खंडन करता है, जबकि Sca, Sa की किसी भी बात से सहमत नहीं है
साथ ही जिन nodes से बहुत लोग सहमत हों उनका weight बढ़े, और विरोध ज़्यादा हो तो घटे—ऐसा भी संभव है
implementation और ripple effects असल में लगभग अनंत हैं
CQ2 की तरह “thread के अंदर thread बनाकर हर thread को विषय से भटकने से रोकना” वाला तरीका अच्छा होगा, लेकिन मेरे अनुभव में लोगों से पहले स्तर का thread इस्तेमाल करवाना भी बहुत मुश्किल है, खासकर non-technical लोगों से
जटिल चर्चा अक्सर, चाहे अच्छा हो या बुरा, “छोटी-सी call करके clear कर लेते हैं” की तरफ चली जाती है
communication apps में जिस feature की मुझे सबसे ज्यादा उम्मीद है, वह यह है कि machine learning model ऐसी “छोटी call” सुने और summary व action items बनाकर फिर से thread में पोस्ट कर दे
तब दोनों तरफ के फायदे मिल सकते हैं
जानना चाहता हूं कि ऐसा क्यों है
बहुत smart और व्यवस्थित लोगों के साथ काम करते समय भी, thread आते ही structured communication पूरी तरह टूट जाती है
दिलचस्प बात यह है कि बोलकर बात करते समय भी कभी-कभी ऐसा होता है
workplace, phone tech support, कलाकारों/लेखकों के साथ feedback discussion, दोस्तों से बातचीत—इन सबमें कुछ लोग किसी खास sub-point को narrow करके अंत तक निपटाने और फिर आगे बढ़ने या big picture पर लौटने के तरीके को नापसंद करते हैं
इसके बजाय वे इधर-उधर कूदते हैं, या बातचीत को हाल के सबसे दिलचस्प topic में
chrootकी तरह बंद कर देते हैंanecdotal तौर पर यह “दो तरह के लोग” जैसा है, पर common factor नहीं पता
यह क्षमता की कमी या बुरी नीयत का मामला नहीं है; बस लगता है कि कुछ लोग tree या stack के रूप में नहीं सोचते
लक्ष्य “सिर्फ AI summary” हो तब भी recording चाहिए, और कहीं न कहीं transcript बचता है
यह भी सवाल है कि deletion के वादे पर भरोसा किया जा सकता है या नहीं
self-censorship, preferences और knowledge के distortion का खयाल आता है
जब privacy की उम्मीद न हो और पता हो कि निगरानी हो रही है, तो लोग अलग तरह से व्यवहार करते हैं
रोजगार में नुकसान, सामाजिक अलगाव और mental health असर के अलावा, panopticon जैसी environment लोगों को कम impulsive और ज्यादा compliant बनाती है, जिससे creativity और innovation पर बुरा असर पड़ सकता है
practical experience में local transcription भी काफी compute resources allocate न किए जाएं तो अक्सर instant नहीं होती
summary call खत्म होने के काफी देर बाद आ सकती है, और AI output plausible/सही है या नहीं जांचने के लिए दिमाग में काफी कुछ rewind करना पड़ता है
management को यह पसंद आएगा, लेकिन बाकी लोग धीरे-धीरे इसे नापसंद करने लगेंगे
कम से कम मेरे लिए private personal conversations और calls, modern remote work environment में interpersonal bond और social reassurance का आखिरी सहारा हैं
linked article में बताए कारणों की वजह से complex topics का अंत “बोलकर तय कर लेते हैं” पर नहीं होना चाहिए
निजी तौर पर मुझे आज भी moderated vBulletin/phpBB-style forums long-term online communication का सबसे अच्छा रूप लगते हैं
जिन कई forums को मैं देखता हूं, उनमें दशकों पुराने active discussion threads भी हैं
कई threads उलझ जाएं तो यह और खराब हो जाता है
पिछले साल के अंत में Google Chat ने यह “thread-based” spaces/channels तरीका force करने से पहले “topic-based” channels चुनने का option दिया था
हर discussion का अपना thread होता था, root level नहीं था, और किसी topic पर reply आने पर वह topic फिर ऊपर आ जाता था
software issue के हिसाब से topic, support case के हिसाब से topic जैसे uses के लिए अच्छा था, और “हर topic email chain जैसा है” कहकर समझाया जा सकता था, इसलिए non-technical लोग भी आसानी से समझते थे
हर topic के पहले comment को summarize करने की आदत भी बन गई थी, और वह पहला comment हमेशा दिखता था, इसलिए email की तरह discussion list scan की जा सकती थी
non-technical लोगों के लिए email से analogy दे पाना सबसे अच्छा होता है
Slack और Discord में default action नीचे वाले बड़े input box और send button से पूरे chat में unstructured message भेजना है
reply के रूप में अलग thread बनाने का option ज्यादा hidden है
simple UX rearrangement और emphasis से इसे solve किया जा सकता है
नया thread बनाने के लिए title require करना, या input box खोलने वाला button रखना—इस तरह थोड़ा और friction भी जोड़ा जा सकता है
यह Google Docs comments system से काफी मिलता-जुलता दिखता है, और वही समस्या लगती है कि हर side thread को एक-एक करके खोलने के लिए बहुत clicks चाहिए
कई replies को एक साथ “सब पढ़ लिया” जैसा महसूस करना मुश्किल है
मुझे Discourse का मौजूदा linear format ज्यादा बेहतर लगेगा
नए replies सारे नीचे जमा हों, और ideally context के लिए quote का थोड़ा हिस्सा हो तो काफी है
बस document की तरह scroll करके पढ़ सकते हैं, इसलिए updates catch up करना आसान होता है
अगर document पर साथ काम नहीं कर रहे हैं—यानी changes track करके उन पर comments नहीं कर रहे—तो हर comment को टुकड़ों में scan करना अक्सर ज्यादा useful नहीं होता
कई comments एक साथ पढ़कर फिर पूरे पर summary-style में जवाब देना सभी का समय बचा सकता है
लंबे text discussion को untrackable बनाने वाली चीज हर छोटे point पर endless back-and-forth है
ऐसी चीजें Slack या call जैसे real-time तरीके से handle करके, main conversation में “item 4 के बारे में Joe और Jane से बात की, और हमने agree किया कि blah blah इस्तेमाल करना best है” जैसी छोटी summary डालना बेहतर है
thread replies का summary tree Google Docs से बेहतर होने की संभावना दिखती है, लेकिन basic interaction flow Google Docs जैसा ही लगता है
पिछले कुछ सालों में proposed webpage annotation system specs देखें तो शायद और innovation की गुंजाइश हो
“जटिल और गहरी चर्चाएं पसंद हैं” कहा गया है, और असल में यह काफ़ी गहरी और जटिल दिखती है, इसलिए गहरी और जटिल चर्चा न बन पाने की कोई वजह नहीं दिखती
मज़ाक अलग रखें, मुझे जो बात पसंद आई वह यह है कि चर्चा मूल टेक्स्ट के किसी खास अंश के इर्द-गिर्द शुरू होती है
यानी टेक्स्ट का कोई हिस्सा चुनकर थ्रेड शुरू किया जाता है
HN पर जो टॉप-लेवल comments article quote से शुरू नहीं होते, उन्हें मैं हमेशा शक की नज़र से देखता हूँ, क्योंकि ऐसे मामलों में अक्सर संदेह होता है कि comment करने वाले ने मूल लेख पढ़ा भी है या नहीं
लेकिन यह तरीका text block के बजाय video, image, game, application वगैरह पर बातचीत कैसे होगी, यह हल नहीं करता
और इस pattern में सबसे कठिन UX समस्या, यानी overlapping excerpts, भी हल नहीं होती
सवाल यह है कि overlapping excerpts को वही thread माना जाए या नया thread, और boundaries कैसे define की जाएं
मैंने एक ऐसे विभाग में काम किया था जो group decision-making research पर आधारित custom platform से group discussions को support करता था
उस platform की killer features में से एक anonymity थी
जब लोग बदले की कार्रवाई के डर, राजनीति करने का ठप्पा लगने, या भीड़ के पीछे चलने के दबाव के बिना comments कर सकते थे और vote कर सकते थे, तब group discussion में सच सामने आ पाता था
cq2 में हर comment पर नाम लगा देखकर लगता है कि जिन लोगों के पास असुविधाजनक ideas हैं, वे post करने में हिचक सकते हैं
इसलिए मुझे जिज्ञासा है कि c2q-style tracking किस तरह के सवालों के लिए उपयुक्त होगी
आपने जो बताया, वह framework से ज़्यादा culture की समस्या लगती है
लोगों को अपने doubts कहने पर retaliation से डरना नहीं चाहिए, और सौभाग्य से हाल के clients या मेरा पिछला workplace ऐसा माहौल नहीं था
जानना चाहूंगा कि क्या उस platform की public information या research उपलब्ध है
यह भी जानना चाहूंगा कि trolling जैसे anonymity के bad behaviors को कैसे manage किया गया
मैं political systems को बेहतर बनाने की उम्मीद में AI का उपयोग करके collective decision-making सुधारने से जुड़े छोटे research projects देख रहा हूं
real examples बहुत कम हैं, इसलिए ऐसी intuition और मिल सके तो अच्छा होगा
अगर DM बेहतर हो तो Twitter पर @dch हूं
visual material बहुत हद तक गायब है
text-based discussions हर reader के दिमाग में अलग-अलग तस्वीर बना देती हैं
अक्सर ऐसा होता है कि सभी लोग text description से सहमत होते हैं, लेकिन जब designer कोई drawing बनाता है तो पता चलता है कि असल में alignment नहीं था और सब विरोध करने लगते हैं
asynchronously बेहतर तरीके से discuss करने का concept अच्छा है, लेकिन मैं images, videos, diagrams जैसे visual material को forum के केंद्र में रखूंगा, और visual material की सबसे बड़ी समस्या—कि बहुत से लोगों को इसे बनाना मुश्किल लगता है—को overcome करने की दिशा चुनूंगा
जिन alternatives का ज़िक्र किया गया है वे सभी comments को किसी specific user से बांधते हैं, और comments को दूसरे comments के response के रूप में जोड़ते हैं
इसके बजाय conversation discussion topic पर focus कर सकती है, और वह topic अक्सर concepts समझाने वाले visual material के set से सबसे अच्छे तरीके से व्यक्त होता है
comments का जवाब देने के बजाय, comments को visually expressed problem के components के इर्द-गिर्द organize किया जा सकता है
तब किसी specific user के comment को amplify या criticize करने के बजाय कई लोग एक concept को support कर सकते हैं
focus किसी के comment पर नहीं, बल्कि problem itself पर होता है, इसलिए शायद defensiveness भी कम हो सके
चर्चा में मौजूद concept को दर्शाने वाला structure बनाना, complex issues पर discuss करने और understanding improve करने के लिए core है
मैं जो tool[1] बना रहा हूं, उसका उद्देश्य लोगों के लिए ऐसे structures बनाना और उनसे काम लेना आसान करना है
हालांकि यह खास तौर पर problem-solving context पर focused है, और collaborative use के लिए महत्वपूर्ण features अभी missing हैं
यहां comments खास तौर पर relevant हैं और जल्द जोड़े जाने वाले हैं
core idea[2] ऊपर की बातों से जुड़ा लगता है, लेकिन यह tool questions, facts, sources जैसे supporting concepts और problems, causes, effects, tradeoffs, solutions जैसे main concepts के बीच ज़्यादा distinction करता है
[1] https://ameliorate.app/
[2] https://ameliorate.app/docs/getting-started/core-ideas
लेकिन group से कुछ बनवाना हो तो कई बार सिर्फ text भी पर्याप्त होता है
तब किसी को खुद drawing बनाने की ज़रूरत नहीं होगी
दूसरी तरफ, कोई भी visual material को direct control नहीं कर पाएगा
मैं ऐसी UI की कल्पना कर रहा हूं जहां लोग text box में comments enter करें, वे comments server को भेजे जाएं, और server “idea समझाने वाले visual material” को लगातार update करे
हर client नए visual material से UI refresh करे, और सभी comments को images, videos, diagrams से attach करने का तरीका भी दे
यानी client UI का केंद्र scrolling comments list नहीं, बल्कि AI-generated visual material हो
users discussion के अलग-अलग components में गहराई से जाकर debate explore कर सकें
AI-generated summaries भी हो सकती हैं
मूल रूप से AI side channel में drawing बनाने वाले designer और summary abstraction को लगातार update करने वाले smart assistant की भूमिका निभाएगा
एक छोटा group जो एक-दूसरे को इतना पसंद करता हो कि मदद करना चाहे, उसे आमने-सामने मिलना चाहिए, और उन लोगों को बाहर रखना चाहिए जो arrogance की हद तक senior हों
तब एक साल का काम एक महीने में खत्म किया जा सकता है
अगर छोटा group एक-दूसरे को पसंद करता है और मदद करना चाहता है, तो offline हो या Slack या कुछ भी, यह उसी तरह काम करेगा
इसका कोई technical solution नहीं है
गंभीरता से पूछ रहा हूं, HN/Old Reddit-style structure में समस्या क्या है, समझ नहीं आता
मेरे अनुभव में, अगर competent moderators हों तो वह system satisfying discussions पैदा करता है
ऊपर से “complex” discussions के मामले में यह assumption है कि participants अपेक्षाकृत छोटी बाधाओं के बावजूद involved रहना चाहेंगे, लेकिन इस solution में यह existential challenge जैसा दिखता है