छोटे आर्काइव के लिए static website का उपयोग

• लोकल में जमा दस्तावेज़, स्क्रीनशॉट, बुकमार्क और मीडिया को बाद में फिर से ढूँढने के लिए, हर छोटे कलेक्शन के साथ एक static website जोड़कर उसे ब्राउज़ किया जाता है
• हर कलेक्शन डिस्क पर एक फ़ोल्डर के रूप में रखा जाता है, और रूट में मौजूद HTML file को ब्राउज़र में खोलकर Finder से अधिक समृद्ध metadata और बेहतर संगठन मिलता है
• web server, build system, dependency या JavaScript framework के बिना इसे हाथ से लिखा जाता है, और हर साइट अधिकतम कुछ सौ lines of code की होती है, इसलिए छोटे प्रोजेक्ट के लिए उपयुक्त है
• मौजूदा folder hierarchy, Finder tags, “everything bucket” apps, और खुद बनाए tools — इन सबमें क्रमशः hierarchy की मजबूरी, implementation की सीमाएँ, app की सोच के हिसाब से ढलना, और maintenance का बोझ जैसी समस्याएँ थीं
• मैनुअल संगठन में समय लगता है, लेकिन इससे केवल वही फ़ाइलें बचती हैं जिन्हें सच में सहेजना सार्थक है, और HTML की सादगी लंबी अवधि के संरक्षण के लिए फायदेमंद है

---

लोकल आर्काइव को mini website की तरह देखना

• हर कलेक्शन के लिए static website बनाकर लोकल आर्काइव को ब्राउज़ किया जाता है
  • स्कैन किए गए दस्तावेज़
  • खुद बनाए गए दस्तावेज़
  • लिए गए स्क्रीनशॉट
  • सेव किए गए webpage bookmarks
  • सेव की गई video और audio files
• फ़ाइल के स्वभाव के अनुसार हर कलेक्शन के लिए अलग दृश्य रखा जाता है
  • स्क्रीनशॉट कलेक्शन को image grid में दिखाया जाता है
  • bookmarks को text link list के रूप में दिखाया जाता है
  • videos को thumbnail और text वाले मिले-जुले list view में व्यवस्थित किया जाता है
• लक्ष्य कोई जटिल सिस्टम बनाना नहीं, बल्कि macOS Finder से थोड़ा बेहतर file browsing interface बनाना है
  • पेज में अधिक metadata डाला जा सकता है
  • अपनी बनाई search और organization methods इस्तेमाल की जा सकती हैं

संरचना और तकनीकी चुनाव

• हर कलेक्शन लोकल डिस्क का एक फ़ोल्डर होता है, और website उस फ़ोल्डर के root में मौजूद एक या अधिक HTML files से बनती है
• उपयोग करते समय HTML file को सीधे web browser में खोला जाता है
• जानबूझकर छोटे पैमाने और low-tech approach को बनाए रखा जाता है
  • कोई web server नहीं
  • कोई build system नहीं
  • कोई dependency नहीं
  • कोई JavaScript framework नहीं
• सब कुछ हाथ से लिखा जाता है, लेकिन छोटे प्रोजेक्ट में यह संभालने योग्य है
  • हर website अधिकतम कुछ सौ lines of code की होती है
• लेखक का मानना है कि केवल डिस्क की files और HTML पर आधारित यह ढाँचा लंबे समय तक टिकने की संभावना रखता है
  • यह folder file structure की सादगी और portability को बनाए रखता है
  • और उसके ऊपर केवल ज़रूरी सुविधाएँ जोड़ता है

पहले के तरीके लंबे समय तक क्यों नहीं टिके

• साधारण file और folder तरीका hierarchical structure को मजबूर करता है, और हर फ़ाइल को ठीक एक जगह पर होना पड़ता है
  • code जैसे कुछ data के लिए यह ठीक काम करता है
  • लेकिन media files के लिए संतोषजनक hierarchy बनाना कठिन था
  • किस folder में रखें, यही सोचते-सोचते desktop बिखरा हुआ रह जाता था
• keyword tagging ज़्यादा पसंद आई, क्योंकि एक फ़ाइल पर कई labels लगाए जा सकते हैं और उसे कई तरीकों से फिर से खोजा जा सकता है
  • macOS Finder tags को support करता है, लेकिन उसका implementation इतना भरोसेमंद नहीं लगा कि उसे महत्वपूर्ण काम के लिए इस्तेमाल किया जाए
• DEVONThink, Evernote, Yojimbo जैसे “everything bucket” apps भी उपयुक्त नहीं लगे
  • ऐसा महसूस हुआ कि इन apps के तरीके के हिसाब से अपनी सोच बदलनी पड़ेगी
• फ़ाइल संगठन के लिए खुद के tools भी कम से कम 12 बार बनाए गए, और आख़िरी कोशिशों में से एक docstore था
  • यह अपने सोचने के तरीके से अधिक मेल खाता था, लेकिन maintenance burden पैदा करता था
  • Python upgrade या macOS update के साथ कुछ न कुछ टूट जाता था और code ठीक करना पड़ता था

फ़ोल्डर को mini website में बदलने का तरीका

• top-level folder में index की भूमिका वाला HTML file रख देने से, सभी files को मनचाहे metadata और tags के साथ दिखाया जा सकता है
• यह तरीका folder structure को सरल बनाता है और perfect hierarchy खोजने का दबाव कम करता है
  • files आमतौर पर केवल year के हिसाब से या filename के पहले अक्षर के हिसाब से समूहित की जाती हैं
  • folders को केवल नई files जोड़ते समय देखा जाता है, ब्राउज़िंग के लिए नहीं
  • files खोजने के लिए हमेशा website का उपयोग किया जाता है
• website keyword tags की मदद से files को कई तरीकों से ढूँढने देती है और असली folder structure की बारीकियों को छिपा देती है
• HTML को कम रखरखाव, लचीली, और आसानी से गायब न होने वाली तकनीक के रूप में चुना गया है
  • यह web की बुनियादी तकनीक है
  • लगभग हर आधुनिक कंप्यूटर में HTML pages render करने वाला browser होता है
  • 2006 में स्कूल की कक्षा के लिए बनाई गई पहली website भी आज के browser में बिना समस्या render हो जाती है

“छोटे” आर्काइव के लिए यह उपयुक्त क्यों है

• फ़ाइलों का संगठन, metadata लिखना, और viewer बनाना काफी हद तक हाथ से किया जाता है, इसलिए यह बड़े कलेक्शन पर अच्छी तरह scale नहीं करता
• कुछ सौ items सहेजने में भी काफ़ी समय लगता है, लेकिन यही friction यह तय करने में मदद करती है कि क्या सहेजने लायक है
  • यह सोचने पर मजबूर करता है कि क्या इसे ठीक से व्यवस्थित करना वाकई सार्थक है
  • क्या ऐसी फ़ाइल, जिसे सेव करने में 1 मिनट भी न लगाना चाहें, उसे बाद में फिर देखने की संभावना है
  • जिन फ़ाइलों को सहेजना तय किया जाता है, उनके लिए बाद में आसानी से खोजने योग्य metadata अधिक ध्यान से लिखा जाता है
• पहले हज़ारों files बड़े और अस्पष्ट folders में जमा रहती थीं, ठीक से व्यवस्थित नहीं होती थीं, इसलिए उन्हें फिर कभी देखा नहीं जाता था
• अब कुछ सौ items वाली छोटी websites हैं, जिनमें items अधिक सोच-समझकर चुने गए हैं और उपयोगी ढंग से वर्णित किए गए हैं
• automation पसंद होने के बावजूद, इस अधिक manual process से आने वाली constraints को सकारात्मक रूप से स्वीकार किया गया है

संरक्षण के साधन के रूप में static website

• इस तरीके की प्रेरणा Twitter account export से आई
  • Twitter account export लोकल में ब्राउज़ की जा सकने वाली mini website देता है
  • कई social media platforms भी data को मनुष्यों के लिए पढ़ने योग्य, ब्राउज़ करने योग्य website के रूप में उपलब्ध कराते हैं
• static websites, born-digital आर्काइव को संभालने वाली digital preservation पद्धति के रूप में भी उपयोगी हो सकती हैं
  • सादगी, दीर्घायु, और कम रखरखाव की प्रकृति उन memory institutions के लिए और भी मूल्यवान है जो दशकों या सदियों तक संरक्षण का लक्ष्य रखते हैं
  • साधारण notepad या text editor से भी एक basic HTML website बनाई जा सकती है
• Data Lifeboat project में Flickr के archive के कुछ हिस्सों को पैकेज करने के तरीके के रूप में बड़ी static websites बनाई जा रही हैं
  • लोकल आर्काइव आम तौर पर list view के क़रीब होते हैं, लेकिन Data Lifeboat के अंदर की websites में अधिक pages और features होते हैं
• Ed Summers की Historypin preservation के लिए static site पर लिखी पोस्ट भी इसी दिशा का एक उदाहरण है

क्रमिक migration और HTML का निजी उपयोग

• पहले से ही डिस्क भर में बिखरी बहुत-सी files होने के कारण सब कुछ एक साथ स्थानांतरित करना बहुत बड़ा काम है
• नई files को static websites में रखा जाता है, और पुरानी files को जब भी ढूँढा जाता है, उनके मौजूदा स्थान से निकालकर उपयुक्त static site folder में ले जाया जाता है
• शुरुआती site structure बना लेने के बाद, उसे चालू रखने के लिए maintenance burden लगभग नहीं रहा
• जो लोग पहली बार website बनाना सीखना चाहते हैं, उनके लिए Blake Watson की HTML for People की सिफारिश की गई है
  • इसका विचार है: “अगर कोई चाहे, तो उसे HTML में website बना पाने में सक्षम होना चाहिए”
• लंबे समय तक HTML को दूसरों के देखने के लिए website प्रकाशित करने का साधन माना गया, लेकिन इसका उपयोग लोकल personal archive के लिए भी किया जा सकता है
• 19 फ़रवरी 2025 के update में, code details समझाने वाली follow-up post How I create static websites for tiny archives जोड़ी गई