हैकाथॉन डेमो वीडियो बनाने के लिए पहले 300 से 400 शब्दों की स्क्रिप्ट लिखिए, फिर अपने प्रोडक्ट को सचमुच चलते हुए रिकॉर्ड कीजिए, और समस्या व आर्किटेक्चर को एक छोटे बनते हुए चित्र (व्हाइटबोर्ड शैली) से समझाइए। कुल लंबाई नियम में दी गई सीमा से कम रखिए, जो ज़्यादातर ऑनलाइन हैकाथॉन में तीन मिनट होती है। पहले बीस सेकंड में समस्या, चालीसवें सेकंड तक चलता हुआ डेमो, फिर तीस सेकंड में "यह काम कैसे करता है", और आख़िर में आगे क्या बनाएँगे। रिकॉर्डिंग साबित करती है कि चीज़ बनी है। चित्र यह समझाता है कि वह क्यों और कैसे काम करती है। यही दो काम अलग रखना पूरे वीडियो की कुंजी है।

पहले यह तय कीजिए कि वीडियो कौन देखेगा

भारत में "हैकाथॉन" शब्द तीन अलग चीज़ों के लिए इस्तेमाल होता है, और तीनों में वीडियो का काम अलग है।

Devpost पर चलने वाले ज़्यादातर हैकाथॉन के नियमों में साफ़ लिखा रहता है कि डेमो वीडियो तीन मिनट से कम हो, YouTube या Vimeo पर सार्वजनिक रूप से दिखे, और जज तीन मिनट के बाद देखने के लिए बाध्य नहीं हैं। दूसरे प्लेटफ़ॉर्म के नियम अलग हो सकते हैं, इसलिए हर बार उस हैकाथॉन का अपना rules पेज पढ़िए, पिछले साल का नहीं।

Smart India Hackathon का मामला अलग है। राष्ट्रीय स्तर पर आइडिया सबमिशन आधिकारिक टेम्पलेट में एक छोटी PDF प्रस्तुति होती है, और 2025 में उसकी सीमा छह स्लाइड थी। वीडियो ज़्यादातर कॉलेज के इंटरनल राउंड में माँगा जाता है, या फ़ाइनल पिच में काम आता है। SIH के लिए वीडियो कहाँ फ़िट होता है, यह विस्तार से Smart India Hackathon के लिए प्रोजेक्ट एक्सप्लेनर वीडियो वाले लेख में है। इस साल के नियम sih.gov.in पर और अपने कॉलेज के SPOC से पक्के कीजिए।

जज पहले बीस सेकंड में क्या खोजते हैं

जो जज सौ सबमिशन देख रहा है, वह हर वीडियो के पहले बीस सेकंड में तय कर लेता है कि बाक़ी कितने ध्यान से देखना है। उसके दिमाग़ में चार सवाल होते हैं, लगभग इसी क्रम में।

1. क्या यह सच में चलता है? सिर्फ़ स्लाइड वाला वीडियो, जिसमें कोई सॉफ़्टवेयर चलता नहीं दिखता, अच्छे आइडिया को भी नीचे गिरा देता है।
2. समस्या किसकी है? एक असली इंसान, एक असली स्थिति। "भारत में करोड़ों लोग" जैसी पंक्ति से कुछ नहीं होता।
3. इसमें मुश्किल क्या था? तकनीकी रूप से कौन सा हिस्सा कठिन था और आपने उसे कैसे सुलझाया।
4. यह आगे जा सकता है? अगला क़दम क्या है, और क्या वह व्यावहारिक है।

ध्यान दीजिए कि इस सूची में ट्रांज़िशन, म्यूज़िक और इंट्रो एनिमेशन कहीं नहीं हैं। रात के दो बजे लोगो एनिमेशन पर बिताया गया आधा घंटा किसी जज को नहीं दिखता।

ढाँचा, सेकंड के हिसाब से

तीन मिनट की सीमा हो तो ढाई मिनट का लक्ष्य रखिए। अपलोड में कुछ सेकंड कटते हैं, और समय से पहले ख़त्म होना आत्मविश्वास जैसा लगता है।

डेमो वाला हिस्सा सबूत है, उसे ज़्यादा एडिट मत कीजिए, वरना जज को शक होगा। बाक़ी हिस्से समझाने के लिए हैं: वे बातें जो सिर्फ़ क्लिक करके नहीं दिखाई जा सकतीं, जैसे समस्या क्यों ज़रूरी है या डेटा सिस्टम में कैसे बहता है।

भाषा: हिंदी, अंग्रेज़ी या हिंग्लिश

यह सवाल हर भारतीय टीम के सामने आता है, और जवाब जज से तय होता है।

• राष्ट्रीय या ऑनलाइन हैकाथॉन: जज देश के किसी भी हिस्से से हो सकते हैं, इसलिए अंग्रेज़ी सबसे सुरक्षित है।
• कॉलेज का इंटरनल राउंड: जो भाषा आपकी फ़ैकल्टी के साथ क्लास में चलती है, वही ठीक है। हिंदी पट्टी के बहुत से कॉलेजों में यह हिंग्लिश होती है, और उसमें कोई बुराई नहीं।
• जब आपका यूज़र हिंदी बोलता है: मान लीजिए आपका ऐप किसानों या छोटे दुकानदारों के लिए है। तब समस्या वाला हिस्सा हिंदी में रखना, भले बाक़ी वीडियो अंग्रेज़ी में हो, जज को दिखाता है कि आपने यूज़र को सचमुच समझा है।

हिंग्लिश में एक नियम रखिए: तकनीकी शब्द अंग्रेज़ी में ही रहने दीजिए (API, database, model, server), और समझाने वाली बात हिंदी में। "डेटाबेस" को "आँकड़ा-कोष" लिखने से जज का ध्यान बात से हटकर शब्द पर चला जाता है।

पूरी स्क्रिप्ट का उदाहरण: कॉलेज बस ट्रैकर

यह एक काल्पनिक पर बहुत आम प्रोजेक्ट है, जैसा कई कॉलेज हैकाथॉन में बनता है। टीम ने "BusSaathi" नाम का ऐप बनाया जो कॉलेज बसों की लाइव लोकेशन दिखाता है, और जिसके लिए बस में अलग GPS डिवाइस नहीं चाहिए: ड्राइवर का पुराना Android फ़ोन ही काफ़ी है। स्क्रिप्ट हिंग्लिश में है, लगभग 330 शब्द, जो सामान्य रफ़्तार (लगभग 150 शब्द प्रति मिनट) में सवा दो मिनट के आसपास चलती है।

समस्या (चित्र). "हमारे कॉलेज में बारह बसें हैं और लगभग दो हज़ार students इन्हीं से आते हैं। सुबह सात बजे स्टॉप पर खड़े student को पता नहीं होता कि बस दो मिनट में आएगी या बीस में। बस छूट गई तो पहला lecture गया, और attendance भी।"

हल (चित्र). "हमने BusSaathi बनाया। हर बस की live location, और आपके स्टॉप तक पहुँचने का अनुमानित समय, सीधे फ़ोन पर। बस में कोई नया hardware नहीं लगता।"

डेमो (रिकॉर्डिंग). "यह driver app है। Driver सिर्फ़ एक बटन दबाता है, Trip शुरू। अब student app देखिए: रूट नंबर सात की बस नक़्शे पर चल रही है, और मेरे स्टॉप के लिए समय दिख रहा है, छह मिनट। अब हम driver के फ़ोन का internet बंद करते हैं। App आख़िरी location के साथ 'signal कमज़ोर' दिखाता है, ग़लत समय नहीं। Internet वापस आते ही बीच की सारी locations एक साथ भेज दी जाती हैं और नक़्शा ठीक हो जाता है।"

यह कैसे काम करता है (चित्र, एक-एक बॉक्स). "Driver का फ़ोन हर दस सेकंड में अपनी location हमारे server को भेजता है। Server हर बस की पिछली कुछ locations से उसकी रफ़्तार निकालता है और हर स्टॉप तक का समय अनुमान लगाता है। Student app हर स्टॉप के लिए यही समय दिखाता है। Network न हो तो driver app locations फ़ोन में ही जमा रखता है और बाद में भेजता है।"

आगे क्या (चित्र). "अगले चरण में हम दो रूट पर एक हफ़्ते का असली trial करना चाहते हैं और देखना चाहते हैं कि अनुमानित समय असल समय से कितना अलग निकलता है। टीम BusSaathi: अदिति, हर्ष, नेहा और फ़ैज़ान।"

इस स्क्रिप्ट में तीन बातें जान-बूझकर हैं। पहली, डेमो में एक असफलता है (internet बंद करना), क्योंकि कमज़ोर network ही इस प्रोजेक्ट की असली चुनौती है। दूसरी, संख्याएँ ठोस हैं: बारह बसें, दस सेकंड, छह मिनट। गोल-मोल डेमो नक़ली लगता है। तीसरी, आर्किटेक्चर को पहले सीधी भाषा में समझाया गया है, ताकि चित्र में हर बॉक्स किसी वाक्य के साथ बने। और कोई सटीकता का आँकड़ा नहीं दिया गया, क्योंकि टीम ने अभी उसे मापा नहीं है। जो संख्या आपने मापी नहीं, वह स्क्रीन पर मत डालिए।

रात के एक घंटे का हिसाब

ज़्यादातर टीमें वीडियो सबमिशन से पहले वाली रात बनाती हैं। एक घंटा काफ़ी है, अगर काम बँटा हो।

• 0 से 15 मिनट, स्क्रिप्ट: ऊपर के पाँच हिस्से सादे वाक्यों में। एक बार टाइमर लगाकर ज़ोर से पढ़िए और ढाई मिनट में फ़िट होने तक काटिए। तब तक दूसरा साथी रिकॉर्डिंग की तैयारी करे।
• 15 से 30 मिनट, डेमो रिकॉर्डिंग: लैपटॉप का अपना स्क्रीन रिकॉर्डर या OBS, और हार्डवेयर प्रोजेक्ट हो तो किताबों के ढेर पर रखा फ़ोन। नोटिफ़िकेशन बंद, ब्राउज़र ज़ूम ऐसा कि फ़ोन पर भी अक्षर पढ़े जा सकें। मुख्य रास्ता दो-तीन बार रिकॉर्ड कीजिए और सबसे साफ़ टेक रखिए।
• 30 से 45 मिनट, चित्र वाले हिस्से: समस्या, हल, आर्किटेक्चर और आगे क्या, इन्हें एक छोटी स्क्रिप्ट की तरह बनाइए। आर्किटेक्चर का हर लेबल जाँचिए।
• 45 से 60 मिनट, जोड़ना और अपलोड: CapCut, Clipchamp, iMovie या DaVinci Resolve जैसे किसी भी सामान्य एडिटर में तीनों हिस्से जोड़िए, कैप्शन डालिए (जज अक्सर बिना आवाज़ के देखते हैं), अपलोड कीजिए, और लिंक को लॉग-आउट वाली विंडो में खोलकर पक्का कीजिए कि वह चलता है।

अंग्रेज़ी में यही योजना मिनट-दर-मिनट और एक अलग उदाहरण के साथ एक घंटे में हैकाथॉन डेमो वीडियो वाले लेख में है।

बनाइए

1. 1

   पाँच हिस्सों वाली स्क्रिप्ट टाइमर के साथ लिखिए

   समस्या, एक वाक्य में हल, डेमो, यह कैसे काम करता है, आगे क्या। ज़ोर से पढ़िए और ढाई मिनट में फ़िट होने तक काटिए।

2. 2

   प्रोडक्ट को सचमुच चलते हुए रिकॉर्ड कीजिए

   मुख्य काम का एक साफ़ टेक, और अगर प्रोजेक्ट की असली चुनौती कोई असफलता है तो उसे भी दिखाइए। अक्षर पढ़ने लायक़ हों, नोटिफ़िकेशन बंद हों।

3. 3

   चित्र वाले हिस्से openCanviz में बनाइए

   डेमो छोड़कर बाक़ी हिस्से पेस्ट कीजिए, Keep my wording चुनिए ताकि narration ठीक आपकी स्क्रिप्ट जैसा रहे, और व्हाइटबोर्ड शैली लीजिए, जो आर्किटेक्चर के लिए सबसे ठीक है। narration हिंदी में बन सकता है, या आप किसी साथी की अपनी रिकॉर्डिंग लगा सकते हैं।

4. 4

   आर्किटेक्चर वाला दृश्य जाँचिए

   हर बॉक्स और हर तीर को उससे मिलाइए जो आपने सच में बनाया है। जो डेटाबेस या कनेक्शन चित्र में अपने आप जुड़ गया हो पर आपके सिस्टम में नहीं है, उसे एडिटर में हटाइए।

5. 5

   जोड़िए, कैप्शन डालिए, लिंक जाँचिए

   चित्र वाली शुरुआत, रिकॉर्डिंग, चित्र वाला अंत। मुफ़्त एक्सपोर्ट पर watermark रहता है, साफ़ फ़ाइल चाहिए तो एक बार का भुगतान उस एक प्रोजेक्ट का साफ़ एक्सपोर्ट खोल देता है।

वे ग़लतियाँ जिनसे सबमिशन कटता है

• समय सीमा से लंबा वीडियो. कुछ हैकाथॉन बीच में देखना बंद कर देते हैं, कुछ अंक काटते हैं।
• Private लिंक. जज क्लिक करता है, "This video is private" देखता है, और आगे बढ़ जाता है। Drive लिंक हो तो "Anyone with the link" वाली सेटिंग पक्की कीजिए।
• Figma मॉकअप को चलता ऐप बताना. अगर कोई हिस्सा अभी सिर्फ़ डिज़ाइन है, तो स्क्रीन पर लिखिए "प्रोटोटाइप डिज़ाइन"। बाद में पता चले तो जज माफ़ नहीं करते।
• कॉपीराइट वाला गाना. फ़िल्मी गाना पीछे लगाया तो अपलोड म्यूट या ब्लॉक हो सकता है, कभी-कभी डेडलाइन के बाद।
• शोर में रिकॉर्ड की गई आवाज़. हैकाथॉन हॉल के शोर में लैपटॉप के माइक से बोली गई बात, साफ़ पढ़ी गई बनी हुई आवाज़ से बुरी लगती है।

आम सवाल

क्या वीडियो में अपना चेहरा दिखाना ज़रूरी है? ज़्यादातर नहीं। आख़िर में दो सेकंड का टीम कार्ड, नामों के साथ, काफ़ी है। वह समय डेमो को दीजिए। अगर नियम में टीम का परिचय कैमरे पर माँगा गया हो, तो दस सेकंड का एक छोटा क्लिप जोड़ दीजिए।

बनी हुई हिंदी आवाज़ लें या अपनी? अगर कोई शांत कमरा है, तो अपनी आवाज़ बेहतर है, जज टीम को सुनना पसंद करते हैं। रात के तीन बजे शोर वाले हॉल में, आपकी स्क्रिप्ट को साफ़ पढ़ने वाली बनी हुई आवाज़ जल्दबाज़ी की रिकॉर्डिंग से अच्छी है। बाद में आवाज़ बदली जा सकती है। हिंदी narration के बारे में और बातें हिंदी में एक्सप्लेनर वीडियो कैसे बनाएं में हैं।

प्रोडक्ट पूरा नहीं चलता, तब क्या? जो हिस्सा चलता है वही दिखाइए, और साफ़ बोलिए कि क्या सिम्युलेटेड है या hard-coded है। योजना वाले हिस्से को चित्र से समझाइए, पर narration में "हम बनाएँगे" कहिए, "यह करता है" नहीं। ईमानदारी उस डेमो से ज़्यादा अंक लाती है जिस पर जज को शक हो।

SIH के इंटरनल राउंड में भी यही ढाँचा चलेगा? ज़्यादातर हाँ, पर वहाँ अक्सर चलता हुआ प्रोटोटाइप नहीं होता। तब डेमो वाले हिस्से की जगह "समस्या विवरण (problem statement) की वह एक शर्त जिस पर हमारा आइडिया टिका है" रखिए, और आर्किटेक्चर को ज़्यादा समय दीजिए। अपनी छह स्लाइड वाली PDF का क्रम ही वीडियो का क्रम रखिए।

हैकाथॉन के बाद इस वीडियो का क्या करें? उसे रखिए। वही ढाँचा थोड़ा लंबा करके प्लेसमेंट इंटरव्यू में पोर्टफ़ोलियो, या फ़ाइनल ईयर प्रोजेक्ट की प्रस्तुति बन जाता है।