Ez a rövid írás még az ME 2.0 projekt indulásakor született (2009 nyarán). Bár a mondanivaló lényegét szélesebb körben is érvényesnek érzem, itt csak azért közlöm, mert ez az írás sokat magyaráz abból, hogy mire miért gondoltam a Mindentudás 2.0 portál tervezésekor. Még akkor is, ha sok minden átértékelődött menet közben.

A remix minden kultúra lényegi eleme (volt és lesz a jövőben is). A világháló megjelenése ehhez "hozzátette" az el-, szét- és megosztott erőforrás-kezelés lehetőségét. A hálózat egyrészt folyamatosan bővíti a remixelhetőség tartományát, másrészt egyre sokszínűbbé teszi a remixelhetőség technikáit, módozait, harmadrészt a hálózat terjedésével egyre dominánsabbá válik a böngésző használata, s ezáltal a hálózaton keresztül elérhető tartalmak és funkcionalitások egyre inkább a böngészőablakon belülre kerülnek.

A ME-webstratégia legfontosabb eleme az lehet, hogy a ME-webjelenlétét egy technikai jellegű koncepcionális váltással tartalmilag és funkcionálisan egyaránt nyitottá tesszük. Ezt a ma divatos gadget (vagy widget) technológia "mindenre kiterjedő" alkalmazásával tehetjük meg. A gadget-technológia annyit tesz, hogy a böngészőkben megjelenő tartalomrészek (résztartalmak) nem egyetlen kiszolgálószerverről jönnek a felhasználók gépeire, hanem az adott böngészőablakban megjelenített tartalom több szerverről, több irányból megérkezve épül fel. Ebben a megoldásban három fontos mozzanatot kell egymástól elkülönítenünk. Az egyik összetevő az információkezelés osztott jellege, vagyis az a lehetőség, hogy az egyszerre felkínált tartalom és funkcionalitás különböző komponensei sokféle irányból, forrásból, a világháló tetszőleges pontjairól szedhetők össze. A második mozzanat az, hogy nemcsak tartalomdarabkákat lehet sok irányból összeszedni, megosztani, hanem alkalmazásdarabkákat is, vagyis lehetséges tartalom- és funkcionalitásremix. A gadget-elv harmadik fontos eleme a többforrású tartalom- és funkcióaggregálás beágyazott módja, vagyis az a megoldás, hogy minden (tartalom vagy funkció jellegű) komponens a böngészőablakba van beágyazva, nem pedig külön ablakokon keresztül érhető el, használható. Ezt a megoldást a továbbiakban gadget-elvnek vagy komponensremixnek fogjuk nevezni, és az egyértelműség kedvéért kicsit alaposabban kibontjuk az új fogalom jelentését.

A komponensremixre már a web kezdetétől lehetőség volt, hiszen amikor egy weboldalba úgy ágyaztunk be egy képet, hogy azt egy másik szerverről lett letöltve és megjelenítve, akkor az a megoldás már e technika első – igaz, még kezdetleges – megvalósulását jelentette.

A ME-szájton a képek nagy része saját szerverről jön (az itt látható logó pl. az alábbi címről "érkezik": http://www.mindentudas.hu/p/mindentudas/2005/logo01.gif), bár a weboldalak html-forrásában találhatunk "külső kép" beágyazására is példát (a Webaudit forgalommérési szolgáltatáshoz szükséges 1 pixeles "mérőképet"):  < img src="http://audit.median.hu/cgi-bin/track.cgi?uc=10316719663131&dc=1" width="1" height="1">

A megosztott, de nem beágyazott képkezelés már sokkal többször előfordul, hiszen az előadások képanyagait az origo képarchívumából lehet elérni. A szemléltető ábra mutatja azt is, hogy ez a ME-kép az origo szerveréről érkezik. Persze az ábráról még az is "leolvasható", hogy a megjelenített kép önálló ablakba kerül, amely megoldás "ellentétes" a mai – és a várható jövőbeni – trenddel, amely mindenféle tartalmat (és funkcionalitást) beágyaz a böngészőablakon belülre. A "külön ablakos megoldásnak" sok esetben az volt az oka, hogy a képkezelés technikai lehetőségei sokáig nem engedték meg, hogy a beágyazott képet "önállóan" lehessen kezelni a weboldalon belül. Egy képsorozat elemeit pédául csak egymástól függetlenül, egyesével lehetett beágyazni egy szájt felületébe és nem lehetett lapoztatni köztük.

A lapozás funkciójának hiánya pédául azért okozhatott gondot, mert egy képsorozatot csak úgy lehetett bemutatni, hogy a sorozat minden eleme köré "fel kellett építeni" a befogadó oldal teljes környezetét, ami megterhelő és fölösleges volt akkor, amikor a képsorozat megjelenítése volt a fontos. A képek, képsorozatok "kényelmes" beágyazására a Flickr képmegosztó szolgáltatás megoldását hozhatjuk fel példaként, amikoris a képdobozba kerülő képek már nincsenek "összekötve" az oldal egészével. Amikor lapozunk, akkor az oldal egészének változtatása helyett csak a képdoboz taralma változik, semmi más. Ez csökkenti a hálózati forgalmat is (ami a befogadónak jó), de – és ez a fontosabb – könnyebbé teszi a képek beágyazását is (ami a szerkesztőnek jó).

A képek megosztása és beágyazása mindig is adott volt, régtől fogva éltek is vele. Másként volt ez a videók esetében, hiszen ott sokat kellett várni arra, hogy a weboldalakba beágyazhatóak legyenek a videótartalmak is. Mára persze már megoldották ezt a problémát is. Ez a helyzet akkor, amikor a YouTube videókat egy hírportál oldalaiba ágyazzák be (a videóablak a "cikken belül" látható, nincs átugrás a YoutTube domain alá, miközben a videótartalom egésze mégiscsak a YouTube szervereiről érkezik meg).

Meg kell említenünk itt, hogy ehhez szükség volt arra a technológiai és szemléleti váltásra, hogy a videótartalmak kiszolgálását nem a letöltés, hanem a streaming-lejátszás révén oldják meg. Első lépésként tehát egy böngészőablakba lehetett betölteni és lejátszatni a videókat, majd második lépésként ezt a videólejátszás lehetőségét nem egyetlen konkrét webcímről lehetett elérni, hanem a videólejátszót tetszőleges weboldalba be lehetett ágyazni, vagyis a vodeótartalom nagyon sokféle oldalba (kontextusba) ágyazva jelenhetett meg. Ezt a lehetőséget tette nagyon könnyen kezelhetővé a YouTube azáltal, hogy saját oldalain minden videó mellé odatette a beágyazást megvalósító kódot is, amit bárki "vihetett szabadon" és könnyedén beágyazhatta azt saját oldalaiba (ez az információ a YouTube oldalakon mindig a videóablak mellett jobbra, fent látható, szürke hátterű dobozban érhető el).

A ME jelenleg más megoldást alkalmaz. A videókat ugyan streaming technológiával jeleníti meg (amit a Magyar Telekom szerverei szolgálnak ki), de a mozgóképes tartalom önálló ablakba töltődik be, a videók nincsenek a ME-szájt felületébe ágyazva. A külön ablakos megoldás helyett be kell ágyazni a videókat, ahogy ezt ma már minden videómegosztó szolgáltatás tudja (a YouTube-tól kezdve a Videan és IndaVideo-n át a NAVA-ig bezárólag. Az egy másik stratégiai kérdés, hogy melyik videómegosztó szolgáltatóval vagy szolgáltatókkal érdemes (kell) együttműködni e téren (erre a kérdésre máshol kitérünk).

A ME videói elérhetők egyébként a NAVA tartományán belülről is (ahol egy külön gyűjteményben kezelik a ME anyagait), csak ott Real Media formátumban és korlátozott (NAVA Pontokon keresztüli) hozzáférési politika mentén.

A NAVA-ra történő hivatkozás azért is fontos, hogy rávilágíthassunk egy másik fontos – technológiai – követelményre, amelyet a videókezelés formátumára vonatkozóan érdemes előírni. A videómegosztók ugyanis – legalábbis egyelőre – többféle formátumban kezelik a videókat, és erre a ME-projektnek fel kell tudni készülnie.

A ME előadásainak nagy része elérhető hanganyag formájában is. Mivel természetes elvárás, hogy ezek az auditív tartalmak az új webjelenlét során is elérhetőek legyenek, az ezekre vonatkozó követelményeket is az eddigiekhez hasonló elvek mentén kell rögzítenünk. A jelenlegi megoldás "ódivatú", nem-felhasználóbarát, hiszen egyszerű állományletöltést kínál csak fel, vagyis a hanganyag lejátszási lehetőségét nem ágyazták be a weboldal felületébe. Miután a felhasználó a hangállományt letöltötte, a saját gépén található – önálló ablakban futó – hanglejátszó programmal hallgathatja meg azt. Ezen érdemes lenne változtatni.

Olyan megoldást kell keresni, amely egyfelől streaming technológiával valósítja meg a hanganyag lejátszását, másfelől lehetővé teszi a lejátszáshoz szükséges kontrollelemek beágyazását.

Az eddigi példák alapján azt szemléltették, hogy a különböző típusú tartalmak elosztott kezelése és weboldalba ágyazása gyakorlatilag minden információtípus (szöveg, kép, mozgókép, hang) esetében megvalósult. A dokumentumbeágyazás technikáját többféle módon igyekeztek meghaladni. A Flickr képsorozatkezelője csak annyi többlettel bírt az egyszerű képbeágyazáshoz képest, hogy egy lapozási funkciót "rendeltek hozzá", és első körben voltaképpen csak ennyivel többet tudnak az online prezentációs szoftverek is, amelyek a – most mindegy, hogy miként szerkesztett, a lényeg csak az, hogy rendelkezésre álló – lapokat képesek lapoztatni (mint a Google Presentation (http://docs.google.com/) vagy a SlideShare (http://www.slideshare.net/) esetében).

Ezek a megoldások már a dokumentummegjelenítés mellett már valamiféle további funkciót is képesek kezelni. Amiből levonható a következtetés, hogy a megosztás és beágyazás elve nemcsak tartalomegységekre alkalmazható, hanem ezek az elvek ugyanúgy működőképesek funkciókra, metódusokra, alkalmazásokra vonatkozóan is. Adódik tehát a lehetőség, hogy a megosztás és beágyazás technikáira támaszkodva alkalmazásokat, funkcionalitásokat tegyünk bele a weboldal dobozaiba. És ezzel el is jutunk a gadget (widget) technológia ötletéhez. Persze, ennek is megtalálhatjuk a korai előzményeit, előképeit.

Egyfelől az összes dokumentum-beágyazás megkívánt már egyfajta funkcióbeágyazást is, csak ezek nem haladták meg a html-nyelv, web-böngésző világ által kínált funkcionalitásokat. De a gadget-technológia nagyon korán megjelent primitív előképének tekinthetjük a hírszájtokon alkalmazott távoli menübeágyazás megoldásait. Erre a jelenlegi ME-szájt is szolgáltat példát, hiszen a jelenlegi weboldal egyetlen napi frissességű információját az a kis doboz szállítja, amely az origo hírszájt tudomány rovatából a legfrissebb híreinek címeit tartalmazza (a szemléltető ábrán a baloldali menüoszlop alján található ez a doboz). Ebbe a kis dobozba az origo szerverei küldik a napi híreket. Ezt a megoldást sok helyen és régtől fogva alkalmazzák.

Ez a példa szemléletesen mutatja a gadget-megoldás egyik rendkívül fontos vonását: ez a technológia képes lehet – sok más mellett – frissességet, változó tartalmat és változó funkcionalitást biztosítani. Legalábbis azon a kis dobozon belül, amelynek a kezelésére "felhatalmazást" kapott a "befogadó weboldal" kezelőitől. Ez a példa persze még mindig a tartalommegjelenítésről szól. A gadget-elv alkalmazása azonban továbbgondolható. Nemcsak annyit jelenthet, hogy ilyen tartalommegjelenítő dobozkákat tudunk kezelni, amelyek révén különböző helyekről szedjük össze és ágyazzuk be a weboldalakba más szolgáltatók által "küldött" hírek címeit, leadjeit, a kép- és videómegosztókon tárolt álló- és mozgóképes, valamint auditív tartalmakat, de a dobozokba be lehet "pakolni" alkalmazásokat is.

Ezt a lépést tették meg az utóbbi években például a Google az iGoogle oldalon, ahol a felkínált gadget-ekből mindenki összeállíthatja magának saját funkcionlaitású weboldalát, de a közösségi kapcsolati háló szolgáltatók (FaceBook, Myspace, iwiw, Google-Orkut stb.) is ugyanet valósították meg akkor, amikor alkalmazások fejlesztését és beágyazását kínálták fel bárki számára. Ehhez dolgozták ki a dobozok beágyazásához szükséges, az "anyaoldallal" való együttműködés menetére vonatkozó szabványokat (openSocial). Az utóbbi szabvány ugyan a kapcsolati háló jellegű közösségi site-okkal összefüggésben született meg, de ettől még a gadget-elv alkalmazását és érvényességét leválaszthatjuk erről. A lényeg itt az alkalmazások beágyazásának lehetősége.

A gadget-technológia arra ad módot, hogy egy weboldal egészén belül elkülöníthető legyen egy olyan rész, amelyen önálló, az oldal többi részétől független funkcionalitást nyújt. Ehhez képest már másodlagos, bár közel sem elhanyagolható vonás az, hogy mindeközben ezt a funkcionalitást más szerverről lehet kiszolgálni. Ez a technológia ötvözi a moduláris építkezés és az osztott információkezelés elvét. A gadgeteknek két fő típusát különíthetjük el ideáltipikus értelemben, és a konkrét gadgetek e két pólus közti kontinuumban helyezekdnek el. Ugyan minden gadget rendelkezik valamilyen minimális funkcionalitással, de van, ahol a funkciók valóban a végletekig redukáltak.

A távoli képbeágyazás ősrégi html-technikája például a tartalombeágyazásról szól, az egyetlen funkcionalitás itt a kép meghívásának lehetősége. Ezzel szemben állnak azok a megoldások, amelyek valamilyen alkalmazási logikát egy böngészőbe (vagy annak egy részébe ágyaznak be. A böngésző-alapú alkalmazások egyik lehetséges továbblépési iránya pont az lehet, hogy azok nemcsak önálló alkalmazásokként futnak majd a böngészőalakokban, hanem különbző gadgeteket solgálnak majd ki a funkcionalitásukkal. A Goole Docs ma még "csak" egy webes szövegszerkesztő, de könnyen elképzelhető, hogy a jövőben ezt az alkalmazási logikát több gadget is használni fogja, tehát az alkalmazás funkciói, metódusai komponensekként épülnek be más gadgetekbe. Erre már régóta van példa a CMS-rendszerek világában. A Plone keretrendszerben például a felhasználó választhatja ki, hogy melyik felkínált szövegszerkesztő komponenst akarja használni a keretrendszeren belül a rendszer által kezelt szöveges dokumentumok szerkesztésére.

Ez az a lehetőség, amit érdemes a lehető legnagyobb mértékben (akár a végletekig feszítve) kihasználni a ME-site kapcsán. Ha ugyanis úgy tervezzük meg a ME-site-ot, hogy a kívánatosnak tartott tartalmakat és funkcionalitásokat gadget-dobozokon keresztül "tesszük bele" a weboldalba, akkor esélyt adunk arra vonatkozóan, hogy a ME oldalak tartalmait és funkcióit a tudomány iránt érdeklődő ilyen-olyan, kisebb-nagyobb közösségek hosszú távon is képesek legyenek élővé tenni és folyamatosan frissen tartani. Ennek a megoldásnak elvileg két alternatívája van. Amennyiben hosszú távon és megbízható módon rendelkezésre áll a megfelelő anyagi háttér, akkor saját stábbal ás technikával is biztosítani lehet a webjelenlétet. Az elkövetkező rövid időszak ugyan pont ilyen megfinanszírozott periódus lesz, de ennek az állapotnak a hosszú távú fenntartására nincs reális esély. A másik lehetőség az, hogy a támogatás ideje alatt a ME brand (és webszájt) körül kialakul egy olyan közössség, amely a támogatás megszűnte utáni időszakban is képes lehet folyamatos webjelenlétet biztosítani, friss információt szállítani a ME oldalaira. Ez természetesen elvileg lehetséges, csak nem egy könnyű feladat tényleges megvalósítani az elképzelést. Hátránya még ennek a tervnek az is, hogy nem lehet többes alternatívákban gondolkodni, a "versengő" elképzelések közül ki kell választani egyet, és – legalább részben – arra kell felépíteni a ME-szájt egészét (nagy részét). Ez az előzetes választáskényszer sokkal kevésbé súlyos terhet jelenthet, ha a komponens-alapú építkezési filozófiát fogadjuk el. Ebben az esetben egyrészt több koncepció mentén is nyugodtan el lehet indulni a web2-es közösségépítéssel, és ezek mindegyikének eredményeit be lehet ágyazni egy-egy dobozba a ME tartományán belülre, majd csak "várni kell" arra, melyik elképzelés válik sikeressé. Másrészt könnyen le lehet cserélni, meg lehet szüntetni egy sikertelen kezdeményezést, hiszen elég csak "levenni" a sikertelen projekt dobozát a ME-oldalairól.

A komponensremix elvén alapuló szájt kialakításához és fenntartásához természetesen olyan tartalomkezelési lehetőséget kell biztosítani, amely révén mód nyílik arra, hogy a ME weboldalait ilyen gadget-dobozokból lehessen felépíteni. Ehhez egy hagyományos értelemben vett szerkesztőségi rendszert kell úgy átalakítani és kiegészíteni, hogy az biztosítani tudja a dobozok beágyazását, megfelelő paraméterezését, a dobozok, funkciók közötti adatcsere-folyamatok szabályozását.