जो स्कूल प्रशासनिक सिस्टम और learning platform दोनों चलाते हैं, उनके पास आमतौर पर हर चीज़ दो-दो होती है: दो login, दो पते, दो roster जो टर्म के तीसरे हफ़्ते तक एक-दूसरे से अलग हो चुके होते हैं, और कुछ बिगड़ने पर दो support नंबर।
EdunodeX अपना learning platform, LMX, ख़ुद देता है — और integration की सारी मेहनत असल में यह सुनिश्चित करने में लगी है कि स्कूल को यह कभी दूसरा सिस्टम लगे ही नहीं।
स्कूल के अपने domain पर learning platform
LMX वही सब रखता है जो एक learning platform से अपेक्षित है: courses, chapters, activities, assignments, और उनके विरुद्ध छात्र की प्रगति। यह एक अलग service के रूप में चलता है जिसे EdunodeX ही संचालित करता है, और शिक्षक तथा छात्र इसे किसी दूसरे पते पर नहीं, अपने ही स्कूल के domain पर एक path से खोलते हैं। इससे कई ऐसी दिक़्क़तें ख़त्म हो जाती हैं जो सुनने में मामूली और व्यवहार में महँगी हैं — दूसरा origin, नवीनीकरण के लिए दूसरा certificate, और एक दूसरा bookmark जो स्थानापन्न शिक्षक के पास होता ही नहीं।
EdunodeX के भीतर platform से हर संपर्क एक ही bridge module से होकर जाता है। इससे authorisation, error handling और डेटा की सीमा — तीनों एक ही जगह लागू होते हैं, और इसी वजह से integration को साफ़-सुथरे ढंग से बंद भी किया जा सकता है।
हर स्कूल के लिए अलग opt-in, default में बंद
इस integration पर लगा फाटक licensing का नहीं, डेटा-सुरक्षा का फाटक है, और इसे fail-closed बनाया गया है — यानी संशय होने पर यह बंद ही रहता है।
Synchronisation, sign-in या assignment की कोई भी प्रक्रिया शुरू होने से पहले दो शर्तें एक साथ पूरी होनी चाहिए: स्कूल में learning platform स्पष्ट रूप से चालू हो, और उसके लिए एक provider तय हो। दोनों, कोई एक नहीं। यह फ़र्क़ सिर्फ़ सैद्धांतिक नहीं है — provider वाले field में हर स्कूल के लिए एक default मान पहले से रहता है, इसलिए दोनों को विकल्प मान लेने पर फाटक हर स्कूल के लिए खुल जाता, उनके लिए भी जिन्होंने कभी सहमति दी ही नहीं। फाटक बंद हो तो हर रास्ता निष्क्रिय रहता है और कोई भी व्यक्तिगत डेटा सीमा पार नहीं करता।
Platform administrator इसे tenant management से किसी स्कूल के लिए चालू करता है, जिससे flag बदलता है और एक audit रिकॉर्ड लिखा जाता है। Provisioning ज़रूरत पड़ने पर ही होती है: learning platform पर स्कूल की जगह पहली बार इस्तेमाल पर बनती है, toggle दबाते ही नहीं। व्यावसायिक plans में यह शुरू से बंद रहता है; अपवाद सरकारी स्कूलों का package है, जहाँ board-lesson वाली कक्षा ही पूरा उत्पाद है और सहमति का इंतज़ाम ऊपर, कार्यक्रम स्तर पर होता है।
जब roster synchronisation चलता है, तब वह एक तय न्यूनतम ही भेजता है: नाम, एक बनाया हुआ ईमेल पता, और भूमिका। पते नहीं, अभिभावक नहीं, फीस की स्थिति नहीं, उपस्थिति नहीं।
हर स्कूल के लिए एक organisation
Learning platform के भीतर हर स्कूल को अपना organisation मिलता है, जिसकी पहचान स्कूल के आंतरिक identifier से बनी एक स्थिर, अपारदर्शी slug से होती है। यह जान-बूझकर न स्कूल का नाम है, जो बदला जा सकता है, न उसका subdomain, जो कहीं और मोड़ा जा सकता है — इसलिए पहचान या subdomain बदलने पर स्कूल के courses अनाथ नहीं होते। निकाला गया organisation स्कूल के रिकॉर्ड के साथ ही रख लिया जाता है, इसलिए आम रास्ता हर sign-in पर network call के बजाय स्थानीय lookup रहता है।
सबसे ज़रूरी बात, कोई request किस स्कूल की है यह हमेशा EdunodeX के अपने link रिकॉर्ड से तय होता है, learning platform के लौटाए किसी identifier से कभी नहीं — वरना tenant की सीमा EdunodeX के नियंत्रण से बाहर की किसी चीज़ पर निर्भर हो जाती।
Courses, कक्षाएँ और साझा catalogue
EdunodeX के शैक्षणिक ढाँचे और learning platform के ढाँचे के बीच का मिलान स्पष्ट है। स्कूल एक group बनता है; कक्षा एक user group। Platform में nesting की अपनी कोई सुविधा नहीं है, इसलिए पदानुक्रम का दिखावा करने के बजाय उसे EdunodeX के अपने नामकरण और identifier की परिपाटी से सँभाला जाता है।
शिक्षक पहले अपनी कक्षा provision करते हैं, फिर उसे किसी विषय के लिए एक course देते हैं। यह assignment कक्षा और विषय — दोनों पर टिका होता है, इसलिए कक्षा 7 विज्ञान और कक्षा 7 गणित अलग-अलग assignments हैं।
सामग्री fork-and-extend ढर्रे पर चलती है। स्कूल catalogue के किसी course को fork करके बदल सकता है, और उसके बाद उसकी कक्षाएँ fork पर पहुँचती हैं जबकि बाक़ी हर स्कूल catalogue वाली प्रति ही पढ़ता रहता है — यानी “साझा catalogue” का मतलब है कि हर स्कूल को अपनी प्रति मिलती है, और स्रोत EdunodeX ही बना रहता है। ये सारे link EdunodeX की अपनी tables में रहते हैं।
छात्रों के लिए board lessons
Lesson Studio में बने board lessons learning platform में इस तरह लाए जाते हैं कि हर slide एक activity बने, और slide की अपनी संरचित सामग्री साथ ही चली जाए। Platform उन slides को ख़ुद render करता है — छात्र की भाषा में, उनकी छवियों और ऑडियो के साथ। यह उसी slide contract का दूसरा, स्वतंत्र implementation है जिसे स्कूल का classroom player पढ़ता है: learning platform slide के पूरे दायरे को कवर करता है, classroom player एक हिस्से को।
दो व्यवहार विफलता की स्थिति के लिए बनाए गए हैं। जिस slide प्रकार को renderer नहीं पहचानता, वहाँ ख़ाली पन्ने के बजाय “समर्थित नहीं” की सूचना दिखती है; asset ग़ायब हो, तो टूटी छवि के बजाय उसका पाठ-लेबल दिखता है। सीमा एक ही दिशा में चलती है: Lesson Studio और classroom player EdunodeX के ही रहते हैं, और learning platform उस catalogue को पढ़ता है, उसमें लिखता नहीं।
प्रगति और अंक सिर्फ़ पढ़ने लायक तथ्य के रूप में लौटते हैं
Learning platform हस्ताक्षरित webhooks के ज़रिए वापस रिपोर्ट करता है — course और activity पूरा होना, assignment के अंक — और लेने वाला हिस्सा कुछ भी स्वीकारने से पहले हस्ताक्षर जाँचता है। घटनाओं को उलटकर सही छात्र और सही कक्षा-विषय से जोड़ा जाता है, और उन्हें छात्र-प्रगति के तथ्यों के रूप में दर्ज किया जाता है। शिक्षक उन्हें कक्षा के courses के साथ ही एक recent activity panel में देखते हैं।
ये gradebook में नहीं लिखे जाते, और यह अधूरी सुविधा नहीं, एक निर्णय है। EdunodeX में रिपोर्ट कार्ड के अंक शिक्षक के दर्ज किए या पुष्ट किए रिकॉर्ड होते हैं, जिनका एक नामित लेखक होता है। learning platform से आई completion घटना बाहरी और असमीक्षित डेटा है; उसे चुपचाप मूल्यांकन रिकॉर्ड में बहने देना उस गुण को तोड़ देगा कि रिपोर्ट कार्ड का हर अंक किसी व्यक्ति का रखा हुआ है। स्कूल चाहे कि वे नतीजे गिने जाएँ, तो वह एक अलग, समीक्षा किया गया क़दम है।
दूसरे password के बिना sign-in
EdunodeX से learning platform में जाते शिक्षक को एक अल्पकालिक hand-off token मिलता है और वे पहले से sign-in अवस्था में पहुँचते हैं। कोई दूसरा password न बनाना है, न भूलना है। Hand-off सिर्फ़ शिक्षण और प्रशासनिक भूमिकाओं तक सीमित है, और यह उस दीर्घकालिक server-to-server credential से अलग चीज़ है जिसे bridge इस्तेमाल करता है और जिसे कभी किसी वेब पते में नहीं रखा जाता।
इस रास्ते की एक ख़ासियत जान लेना ज़रूरी है, अगर आप इस पर कुछ बना रहे हों: hand-off token बनाते समय उपयोगकर्ता की भूमिका learning platform की ओर दोबारा सिंक भी होती है। जिस mint call में भूमिका नहीं दी गई, वह भूमिका को अपरिवर्तित नहीं छोड़ती — वह उपयोगकर्ता की भूमिका घटा देती है। इसलिए हर caller इसे स्पष्ट रूप से भेजता है।
शिक्षक का रोज़ का प्रवेश-द्वार एक courses पेज है, जो EdunodeX के अपने timetable से पढ़कर आज के periods दिखाता है। जिस period की कक्षा और विषय से कोई course जुड़ा है, उसके सामने एक सीधा विकल्प रहता है जो नया token बनाकर वही course खोल देता है। Learning platform को निर्धारित course जैसी कोई अवधारणा पता नहीं है, इसलिए scheduling उसमें भेजी नहीं जाती — timetable EdunodeX में ही एकल स्रोत बना रहता है।