Tartalom
Ez a cikk először a .net magazin 229. számában jelent meg - ez a világ legkeresettebb weblaptervezők és -fejlesztők magazinja.
Mint. Olvassa el később. +1. Csipog. Tumblr. Rábukkan. Az elmúlt években a kis chiclet gombok kanyarószerűen terjedtek az interneten, és megjelentek és eltűntek, amikor az új eszközök és szolgáltatások egyre népszerűbbek és csökkentek. A népszerű ShareThis gomb, amely lehetőséget nyújt a webhelytulajdonosoknak arra, hogy legalább ezeket a szociális szolgáltatásokat egy előugró mezőbe írják be, jelenleg több mint 120 lehetséges célállomást kínál - és bár soha senki nem sorolja fel mindet egyenesen, gyakran nehéz pontosan megmondani, hogy ki az összes lehetőség segít.
Javításra szoruló probléma, amelyet mind a Google, mind a Mozilla megoldásokkal kezel - Web szándékok és Web Műveletek / Tevékenységek. Végrehajtásuk változó, de az alapvető cél ugyanaz: távolodni attól, hogy a webhely / alkalmazás készítője bizonyos szolgáltatásokhoz kapcsolódjon, hogy elvégezzék a dolgokat, annak érdekében, hogy egyszerűen lehetővé tegyék számukra, hogy olyan igéket adjanak meg, amelyeket a böngésző kezelhet egy felhasználói oldalon. felhasználónként.
Mit jelentene ez a gyakorlatban? Nos, például: jelenleg sokféle könyvjelző eszköz létezik, a legnépszerűbbek közül kettő a Delicious és a Pinboard. A cikk végén található könyvjelzőgomb integrálásához a webhely tulajdonosának két különböző kódrészletet kell hozzáadnia. A Web Intents / Actions világban ez egyszerűen egy „Bookmark This” gombra válik. Amikor a felhasználó rákattint, böngészője meglátja az igét, kikérdezi a regisztrált szolgáltatások listáját és átadja az adatokat.
Ez azonban csak a lehető legegyszerűbb forgatókönyv. Ami azt akadályozza meg, hogy a Web Intents / Actions dicsőített „mailto: link” legyen, az az, hogy sokkal többre képesek, beleértve a kétirányú interakciókat is, amelyek alkalmassá teszik őket teljes webes alkalmazásokra, valamint egyszerűen chiclet-cserékre. A Web Intents jelenlegi specifikációi a Discover, Share, Edit, View, Pick, Subscribe and Save igéket kezelik. Nagyon kevés kódolással például elküldhet egy képet egy szerkesztőnek, és visszakaphatja a megérintett verziót, ugyanolyan egyszerűen, mint az információkat, például az elérhetőségeket, kihúzni egy külső címjegyzékből egy meghatározott formába - mindezt anélkül, hogy egyetlen egyedi API-hívás, vagy akár annak tudása, hogy valójában mi a második fél.
Természetesen ennél több finomság van benne. Ahogy a Mac és a Windows nem a fájlok és képek helyett, hanem a típusuk alapján foglalkozik a képfájlokkal, úgy az alkalmazások is megadhatnak formátumokat és adattípusokat. Például egy webalapú képszerkesztő bekapcsolódhat a JPEG kezelésébe, miközben udvariasan elzárkózik a PNG-k vagy az MP3 útjától. Abban az esetben, ha több regisztrált ügyfél és szolgáltatás képes kezelni egy kérést, a böngésző egyszerűen megjeleníti a menüt, amelyben a felhasználó kiválaszthatja, hogy melyiket szeretné használni. A megfelelő megvalósítást feltételezve, ugyanaz a kódrészlet működik mindegyiknél.
Eltérő víziók
A fogás az, hogy míg a Google és a Mozilla nagyjából ugyanazt a jövőképet osztja meg, megvalósításuk és végső céljaik kissé eltérnek.
"Bár a böngészőfunkciók fejlesztése a szabványtestületek égisze alatt nyíltan zajlik, mégis úgy érzi, mintha találkoznánk a különböző szabadkőműves megrendelések között" - magyarázza Glenn Jones, a februári Web Intents Design Push esemény egyik szervezője. - Tehát, amíg nem értettem félre a kézfogásokat, az itteni különbségek arra vonatkoznak, hogy mindenki milyen célt ér el.
„A Chrome csapata nagy hangsúlyt fektet a webalkalmazásokra, és érdekli őket például az offline működés. A Mozillát jobban érdekli a közösségi média szélesebb körű felhasználása, és egy kicsit le akarja tartani a megoldást. "
Az „egyszerű”, nem meglepő, nem egészen az a szó, amelyet Tantek elik használ, a webes szabványok a Mozillánál vezetnek. "Úgy gondoljuk, hogy a Mozilla webes tevékenységei koncentráltabb megközelítés [mint a Web Intents], amely a nyitott webalkalmazások rendszerére támaszkodik a felfedezéshez" - magyarázza. "A felfedezésnek a webalkalmazásokra való alapozása egy feltételezés, hogy a felhasználó által telepített alkalmazások igénylése egy felhasználó-központú mechanizmus, amely biztonságosabb, az adatvédelmet javító és érthetőbb."
A Mozilla egyik sajátos technológiai panasza az, hogy a Web Intents nagymértékben támaszkodik a JavaScript-re, jelenleg mindenki számára elérhető alátét áll rendelkezésre, aki kísérletezni akar velük. "Ez sok webhely és alkalmazás számára nem indul el, mivel korlátozott képességű eszközökön kell működniük, vagy amikor a felhasználók kikapcsolják a JavaScript-et, vagy más módon nem tudnak hozzáférni a külső szkriptekhez" - folytatja az elik. "A Twitter példája és az egyszerű hiperhivatkozások használatának legjobb gyakorlatai alapján tudjuk, hogy a webes műveletek JavaScript nélkül is működőképessé válhatnak, ezért a webes műveleteknek JavaScript nélkül is működniük kell."
Amiben mindkét fél egyetért, az az, hogy a technológia felhasználói felületének oldala még mindig munkára szorul. Mi történik például akkor, amikor a felhasználó egy olyan igére kattint, amelyhez még nem regisztrált szolgáltatást, vagy ha a szolgáltatás meghiúsul? Milyen gyorsan választanak azok a webhelyek, amelyek jelenleg a Facebook Like gombokat használják a forgalom növelésére, alkalmazkodni fognak egy olyan világhoz, ahol a „Share” a Google Plus és a MySpace között bármi körül visszavetheti a forgalmat? Pontosabban, hogy ezek a szolgálatok hogyan fogják ezt a találatot az információs térképeikre felvenni?
"Az elmúlt hónapokban a rejtett érték elvesztése képes pontosítani a Facebook / Twitter / Google és így tovább, ha nyomon követi az emberek böngészőjének előzményeit az interneten keresztül, és mindez az injektált JavaScript az aggasztónak tartja" - mondja Jones. „Ezeknek az adatoknak nagy pénzértéke van az érintett vállalatok számára, és ha nincs olyan JavaScript az oldalakon, amely halkan követi a felhasználók böngészési előzményeit, az visszatarthatja őket az interfészek biztosításától. Ez nagy ok arra, hogy a felhasználók kedveljék a webszándékokat / -műveleteket, de ez lelassíthatja a Facebook-szerűek használatát. "
Együtt dolgozni
Ezeket és további kérdéseket még meg kell oldani, mielőtt a Web Intents vagy a Web Activity eléggé elterjedhetne ahhoz, hogy szabványos építőelem legyen.
"Nem hiszem, hogy bárkinek érdeke, hogy ezen a téren különböző szabványokat dolgozzon ki" - mondja Jones. "Remélhetőleg felvetődik a kérdés, hogy miként nyerhetünk egy másikat. Szívből veszem, hogy Ian Hickson (a Google Standards Development csapatának tagja és az Acid böngésző kompatibilitási tesztjeinek szerzője / fenntartója) most fontolóra veszi a registerProtocolHandler (), registerContentHandler () a Web Intents szolgáltatással működik. ”
A két technológia összehasonlítása érdekében a legjobb kiindulópont a Google webhely, amely rengeteg élő bemutatót, egy kísérleti JavaScript-alátétet és rengeteg Q & As-t tartalmaz, amelyek megmagyarázzák, miért fontos ez a fajta technológia, és miért kell új technológiára. A Mozilla verzió inkább fejlesztőközpontú és több háttérismeretet feltételez, de a fő központot itt találja.
