दस्तावेज़ों में अपने-आप अपडेट होने वाले screenshots जोड़ना

• चल रहे web application से screenshots को अपने-आप capture करके help document build के साथ अपडेट करने वाला एक workflow बनाना, ताकि UI बदलने के बाद भी document images latest बनी रहें
• Markdown के अंदर SCREENSHOT comment में target path, capture method, CSS selector जैसे निर्देश होते हैं, और build process इन्हें पढ़कर असली image भर देता है
• Rake task Capybara और Cuprite के जरिए headless Chrome चलाती है, और team के हिसाब से काम को group करके एक बार login करने के बाद कई URL पर घूमते हुए capture करती है
• capture में element, full_page, viewport तीन mode supported हैं, और click, wait, crop, torn, hide जैसे options से खुले हुए UI state या गैर-ज़रूरी elements को भी control किया जाता है
• सिर्फ rails manual:build एक बार चलाने से screenshot generation और help page build साथ में हो जाते हैं, और code व documents को उसी PR या commit में मिलाना आसान हो जाता है, जिससे manual capture और manual crop की friction काफी कम हो जाती है

---

अपने-आप अपडेट होने वाले screenshots का तरीका

• चल रही Jelly(टीमों के लिए shared mail inbox service) के help center को इस तरह बनाया गया है कि वह running web application से screenshots को अपने-आप capture करे और दोबारा build होने पर उन्हें साथ में अपडेट भी करे
• documents Markdown में लिखे जाते हैं, और Self-updating screenshots लेख के अनुसार उन्हें Redcarpet से HTML में process करके फिर Rails app के ERB view के रूप में render किया जाता है
• Markdown के अंदर SCREENSHOT comment डाला जाता है, जिसमें target path, capture method, CSS selector जैसे निर्देश दिए जाते हैं
  • <!-- SCREENSHOT: acme-tools/inbox | element | selector=#inbox-brand-new-section -->
  • उसके ठीक नीचे image tag उस जगह के रूप में इस्तेमाल होता है जहाँ result डाला जाएगा
• UI का रंग, button की position, या text थोड़ा भी बदल जाए तो पुराने document screenshots जल्दी outdated हो जाते हैं, और यह workflow उस manual update burden को कम करता है

capture pipeline और maintenance के फ़ायदे

• अंदरूनी तौर पर Rake task Capybara और Cuprite के जरिए headless Chrome चलाकर सभी Markdown files में SCREENSHOT comments को scan करती है
• screenshot का काम team के आधार पर group करके process किया जाता है, ताकि एक ही team में सिर्फ एक बार login करके कई URL पर जाया जा सके
• supported capture mode तीन हैं
  • element: CSS selector से किसी खास DOM element को capture करता है
  • full_page: पूरे page को capture करता है, और ज़रूरत पड़ने पर height के आधार पर crop किया जा सकता है
  • viewport: browser window में इस समय दिख रहे हिस्से को ही capture करता है
• detail options के रूप में click, wait, crop दिए जा सकते हैं, जिससे button click के बाद दिखने वाली state या animation के बाद की screen भी अपने-आप capture की जा सकती है
  • <!-- SCREENSHOT: nectar-studio/manage/rules | full_page | click=".rule-create-button" wait=200 crop=0,800 -->
  • यह button दबाकर form खोलता है, फिर 200ms इंतज़ार करता है, और एक खास हिस्से को crop करके capture करता है
• extra options के रूप में torn और hide भी हैं
  • torn CSS clip-path का उपयोग करके फटे हुए कागज़ के किनारे जैसा effect लागू करता है
  • hide dev toolbar या cookie banner जैसे उन elements को अस्थायी रूप से छिपाता है जो screen पर नहीं दिखने चाहिए
• पूरा pipeline सिर्फ rails manual:build command से चल जाता है, और सभी screenshots capture करने के साथ help pages build भी साथ में हो जाता है
• document source public/manual/ के नीचे basics, setup, advanced जैसे sections में व्यवस्थित है
• build step में इन Markdown files को app/views/help/ के नीचे ERB views में बदला जाता है, और breadcrumb व section navigation भी साथ में generate होते हैं
• feature development और help updates को एक ही codebase के भीतर साथ में संभाला जा सकता है, इसलिए code और documents का synchronization उसी PR या उसी commit में बनाए रखना आसान हो जाता है
• scroll वाले elements, click करने पर खुलने वाले popover, और गैर-ज़रूरी हिस्सों से बचने के लिए crop जैसे exception handling को implement करने में ज़्यादा समय लगा, लेकिन एक बार setup होने के बाद help center को कहीं ज़्यादा बार अपडेट किया जाने लगा
• UI बदलने, build फिर से चलाने और result को commit करने वाले workflow से screenshots को हमेशा latest रखा जा सकता है, और manual capture व manual crop की friction लगभग खत्म हो जाती है

[GN⁺]

Hacker News राय

• मैंने भी इसी तरह .#screenshots derivation जोड़ा हुआ है, और शुरुआती setup cost बड़ी होती है, लेकिन उसके बाद maintenance लगभग नहीं के बराबर रहता है
  जब प्रोग्राम से screenshot generate ही कर रहे हों, तो ऐप के light/dark theme दोनों version साथ में बना सकते हैं, और prefers-color-scheme: dark के हिसाब से उन्हें बदल सकते हैं
  ऐसे elements GitHub README में भी अच्छे से काम करते हैं: https://github.com/CyberShadow/CyDo#readme
  • मैं इस तरीके से पूरी तरह सहमत हूँ
    मोबाइल ऐप में मैंने Nix से एक बार इस्तेमाल होने वाला Android emulator चलाकर latest screenshots generate करवाए, और इसमें न पहले से setup की ज़रूरत पड़ती है, न run होने के बाद कोई data बचता है
    मेरे मामले में setup भी इतना मुश्किल नहीं था; idea सोचना उससे ज़्यादा कठिन था, और Nix code मैंने अपने पसंदीदा LLM से एक ही बार में बनवा लिया
    screenshots को manually update करना दुनिया का सबसे कठिन काम तो नहीं है, लेकिन upload-apk + take-screenshot + transfer-back-to-PC + edit वाला flow हमेशा हल्का-सा झंझट लगता है, इसलिए आख़िरकार मैं यह काम लगभग करता ही नहीं
• मोबाइल पर code examples के लिए horizontal scroll ज़रूरी है
  context से अंदाज़ा तो लग गया था, लेकिन फिर भी असुविधा हुई
• यह mobile projects में सच में बहुत उपयोगी है
  app stores में screenshots अनिवार्य होते हैं, लेकिन screen size की संख्या और localization की संख्या के हिसाब से image बनानी पड़ती हैं, इसलिए यह जल्दी ही झंझट बन जाता है
  पहले मैं इसके लिए खुद script लिखता था, और अब https://fastlane.tools/ जैसे Fastlane tools बहुत मदद करते हैं
  मैं अपनी logic puzzle game Nonoverse में भी Fastlane इस्तेमाल कर रहा हूँ, और app store page पर example screenshots देखे जा सकते हैं: https://apps.apple.com/us/app/nonoverse-nonogram-puzzles/id6...
  App Preview video recording भी कई scenes तक शामिल करके automate कर रखी है, और अगर किसी की दिलचस्पी हो तो यह अलग से लिखने लायक विषय है
  • इसमें दिलचस्पी तो काफ़ी बढ़ गई है, लेकिन यह paid service है या local पर चलने वाला OS app, यह साफ़ समझ नहीं आ रहा
• काफ़ी बढ़िया है
  मैं vibe coding से जो छोटे casual games बनाता हूँ, वे हमेशा ऐप के CLI से headless चलने, offscreen texture rendering, screenshot commands, और performance instrumentation की क्षमता के साथ शुरू होते हैं
  इसे जोड़ने में लगभग समय नहीं लगता, और agent के लिए UI automate करने और अहम points देखने का रास्ता भी बन जाता है
  इसी वजह से agent से screenshots update करवाना भी बहुत आसान हो जाता है
  build process में पूरी तरह घुले-मिले version जितना elegant तो नहीं है, लेकिन अब मैं वह हिस्सा भी जोड़ने के बारे में सोच रहा हूँ
  • मैं भी बिल्कुल यही करता हूँ
    मेरे पास offscreen screenshot path और world pos/camera view vector देने वाले CLI arguments भी हैं, और text-based input format से scripted benchmarks चलाता हूँ
    यह format कई named segments की lines, हर segment के लिए n game ticks की लंबाई, और हर segment के control inputs से बना होता है
    game code पर काम करते समय visuals और performance का A/B test करने में मैं इसका बहुत इस्तेमाल करता हूँ
  • क्या आप इन casual games के कुछ links share कर सकते हैं?
    मुझे भी यह जानने में काफ़ी रुचि है कि vibe coding game development को कितना आसान बनाता है
    Adobe Flash के दौर में indie game ecosystem सचमुच बहुत जीवंत था, और उसके बाद उस स्तर की development ease को छूने वाली चीज़ें बहुत कम रहीं
    vibe coding पहली ऐसी चीज़ लगती है जो शायद उस स्तर से आगे निकलती है
  • इसे जोड़ने में लगभग समय नहीं लगता वाली बात मामले पर निर्भर करती है
    आप कौन-सा engine इस्तेमाल कर रहे हैं, यह जानने की जिज्ञासा है
• सच में शानदार
  मुझे खास तौर पर यह बात पसंद आई कि Markdown document के अंदर screenshot declaration inline डाली जा सकती है
  अपने desktop app में मैंने कई भाषाओं और light/dark modes के screenshots generate करने, noise हटाने, और Windows/macOS window frames लगाने वाला solution बना रखा है
  उसे यहाँ संक्षेप में लिखा है: https://maxschmitt.me/posts/cakedesk-website-redesign#screen...
  अभी वह अलग script है, इसलिए maintenance काफ़ी झंझटभरा है, लेकिन markdown/mdx के हिस्से के रूप में शामिल करने वाला तरीका देखना चाहिए
  इससे अच्छी प्रेरणा मिली
• ऐसी चीज़ की सच में बहुत बार ज़रूरत पड़ी है
  इसे तो कोई नोटिस न करे, ऐसा X का बेहतरीन काम वाले meme की तरह इस्तेमाल किया जा सकता है
• यह अच्छा है
  मेरे https://github.com/zombocom/rundoc में भी ऐसा मिलता-जुलता feature है
  इसका मुख्य उद्देश्य tutorial generation है, इसलिए यह चलाए गए commands का output भी वापस document में डाल देता है
• यहाँ real-time rendering वाला approach भी संभव हो सकता है
  जैसे tool का live preview किसी rectangle के भीतर डाल दिया जाए
  अगर tool हल्का हो, तो यह visual तौर पर भी सबसे अच्छा हो सकता है, और browser की accessibility settings या user addons जैसी rendering settings भी वैसे की वैसे reflect हो सकती हैं
  • या फिर HTML को static build भी कर सकते हैं
    iommi docs में सचमुच ऐसा ही किया गया है: https://kodare.net/2025/01/14/iframes-not-screenshots.html
  • हालाँकि यह security issue भी बन सकता है
• e2e tests चलाते समय screenshot generation भी साथ में करने का मैंने सोचा है
  अगर documentation के docs/ को भी उसी repository में रखा जाए, और docs update करते समय जहाँ नए screenshots चाहिए हों वहाँ नया test जोड़ दिया जाए, तो यह काफ़ी अच्छी तरह फिट बैठ सकता है
• बढ़िया
  मैंने भी कुछ साल पहले बिल्कुल यही बनाना शुरू किया था, लेकिन बाद में इसे https://picshift.io/ जैसी ज़्यादा general दिशा में abstract कर दिया
  फिर भी screenshot use case मुझे अब भी बहुत पसंद है, और इस project का मूल नाम भी ScreenSync था
  • अच्छा है, बढ़िया बनाया है, और यह देखकर खुशी होती है कि ऐसे अलग-अलग approaches साथ-साथ मौजूद हैं