'webkettő' kategória archívuma.

Friend Connect? – ezmiez?

Imádom, amikor a sajtó, a bloggerek, és még a konkurencia is egy az egyben megeszi a Google bejelentéseit, úgy, hogy nem is jelentettek be még semmi konkrétumot. A Friend Connect ennek a tipikus esete, aminek a teljes neve Google Friend Connect. A gyönyörű az egészben az, hogy a Google még csak nem is hazudik egy szóval sem, csak éppen nem hangsúlyoz ki pár dolgot, a világ másik fele pedig félinformációkra építve felfúj egy rózsaszín lufit, és boldogan körbeugrálja azt.

Me can make money without doing evil.

Friend Connect

A konkrét részletekről most sem lehet tudni igazán sokat, de ezúttal a demóból és az oldalból elég jól ki lehet bányászni, hogy mit takat a Google Friend Connect-je. Idézetek a Friend Connect oldaláról:

Google Friend Connect lets you grow traffic by easily adding social features to your website. With just a few snippets of code, you get more people engaging more deeply with your site.

Közösségi szolgáltatásokat adhatsz az oldaladhoz, de semmilyen információd nem lesz a látogatóidról, és a kapcsolataikról. Úgy fogsz felépíteni egy közösségi alkalmazást, hogy a felhasználók a te szolgáltatásodtól függetlenül, a Google-nél szocializálódnak, egy fal mögött.

Attract more visitors. Visitors bring along friends from social networks like Facebook, orkut, and others to interact on your site.

A látogatók a Facebook, Orkut és egyéb irányokból hozhatják a barátaikat. Miután a Google-nek hozzáférést adnak ezekhez a hálózataikhoz, az kiolvassa az információkat, avagy bemásol mindent a Google profilodba.

Enrich your site with social features. Choose engaging social features from a catalog of gadgets provided by Google and the OpenSocial developer community.

Mindez tehát a Google technológiájára, a Google Widgetekre és a Google OpenSocialra épül. A Google OpenSocial jelentése az információid a Google-hoz láncolása.

No programming whatsoever. Just copy and paste snippets of code into your site, and Google Friend Connect does the rest.

Nem kell programozni, csak kitenni egy iframe-et. A kitett iframe bár az oldaladról szól, a Google-nek épít fel egy közösségi háló adatbázist, vagyis azt, hogy te merre jártál, mely szolgáltatásokat használsz.

Mi a baj?

Nem az, hogy minden információ a Google-hoz kerül. Nem a technológia. Csak az, hogy ez azt jelenti – hacsak nem köp bele valaki a levesbe mihamarabb -, hogy az információt kiszipkázva a Google vezető alapszolgáltató lesz a közösségi hálózatok terén. Az egész ugyanis messze sem egy nyitott megoldás a nyílt olyan jelentésében, mely lehetővé tenné a Google bármely konkurenciájának hozzáférését a közösségi hálómhoz, csak és kizárólag a Google-nak lesz hozzáférése. Sőt, még csak annyira sem nyitott, hogy az akcióban részt vevő oldalaknak bármi közük is lenne ehhez a hálózathoz. Itt pedig az a gond, hogy ezek az oldalak nem fognak tudni valódi közösségi oldalként viselkedni, a felhasználók számára testreszabott oldalakat létrehozni.

Eddig is nehéz volt olyan embert találni, akinek ne lett volna Google azonosítója, ezután pedig a látogatóid simán regisztrálnak a Google-nál úgy, hogy még csak észre sem fogják venni ezt a tényt, mert azt hiszik, hogy nálad regisztráltak. Nálad meg nem fognak regisztrálni.

Ahogyan – bár egészen más lett kihangsúlyozva – az OpenSocial sem szól másról, mint a Google Widget platformjának reklámjáról és terjesztéséről, addig a Friend Connect sem szól másról, mint a Google Accounts reklámjáról és terjesztéséről, az egészet az OpenSocialra építve.

A baj az, hogy egyáltalán nem arról a gyönyörű nyitottságról van szó, amit az ember reflexből odaképzelne a dolgok mögé. És hogy ha minden így marad, a Google hátulról indulva lenyomja az összes közösségi háló szolgáltatást.

Nyitott, de…

A Friend Connect nyílt szabványokat fog használni az authentikációhoz, azaz OpenID azonosítóval be fogsz tudni lépni ezekre az oldalakra. Azok a felhasználók azonban, akiknek nincsen ilyen azonosítójuk, várhatóan egy Google azonosítót fognak kapni magától jövő természetességgel. Az OpenID azonosító, ami az authentikációhoz lesz használva, az nem azt jelenti, hogy az adatok (bármilyen információ, beállítás a felhasználói azonosítón/jelszón felül) is az OpenID szolgáltatónál landolnak, hanem egyenesen a Google-nál fognak.

A felépülő közösségi háló várhatóan nyitott lesz bármilyen Google által meghatározott szabványos közösségi háló importálására, de ezeket a hálókat egyelőre nincs olyan konkurencia, mely megpróbálná valóban nyílt módon összefogni, úgy, hogy valóban mozgathatóak legyenek az adataink, ellenben az összes potenciáli konkurencia szó nélkül implementálja az interfészeket, és beépül a Google hálózatába. Ezután viszont miért is kéne regisztrálnom ezekbe a konkurens oldalakba, ha elég a Google-hoz?

Nyitott, de közel sem eléggé, a nyitottság sajnos egy falon belüli nyitottságot takar.

Jó lesz, de…

Igen, irónia nélkül is ki lehet jelenteni, hogy jó dolgot talált ki a Google, és hogy nagyon kényelmes lehet csak egy közösségi hálóval élni, én is unom már az ismerősök jelölgetését. Az oldal tulajdonosok kapnak egy könnyű invitációs lehetőséget programozás nélkül, olyan szolgáltatásokat (chat, kedvencek jelölése), melyeket nekik nem kell egyáltalán leprogramozniuk.

Az oldalak létrehozhatnak olyan dobozokat, melyek a Google Widget technológiájára épülnek, és a saját szolgáltatásukat jobban tudják integrálni ezekbe a közösségükbe, és ezek a widgetek sok oldalon működhetnek majd.

Jó lesz tehát, de sokkal jobb lenne, ha szinkronizált közösségek épülnének fel, melyek kapcsolódnak egymással, de minden szolgáltató hozzáfér azokhoz az információkhoz, melyek rá tartoznak. Hiába veszek fel ugyanis kedvencnek a Google-nél egy receptet egy iframe-en belül widgetben, ha mint oldalgazda nem fogom tudni, hogy milyen recepteket szedett össze a felhasználó, és milyen továbbiakat ajánlhatok még neki.

Összefoglalás

A Google nyitottságot, látogatottságot, közösségi szolgáltatások könnyű beépíthetőségét ígéri programozás nélkül, de ez így ebben a formában sajnos nem tűnik igaznak, vagy legalábbis mellékhatások nélülinek. Még ha a fenti keretek között a lehető legnyíltabb is lesz a szolgáltatás, az oldalak részben hozzáférhetnek látogatóik közösségi hálós preferenciáihoz, információihoz, akkor is egy zárt Google platformot kezdünk el építeni, melyből győztes szolgáltatóként a Google fog kijönni. Modern, szuper és fantasztikus lesz, ugyanolyan mint amikor az IE6 kijött a Microsoft tolmácsolásában. Biztosan jó ez akkor is, még ha a Google barátságos, és az lesz a jövőben is? Nem kéne inkább valami valóban nyíltat, függetlent összehozni?

Liligo.hu – a repülőjegy kereső

A Hírfigyelőhöz hasonlóan a most bemutatandó szolgáltatásnál is személyes érintettségem van, illetve ezen felül még egy dolog hasonló: ez a szolgáltatás is referenciaként szolgált a Netvibes-hoz történő jelentkezésemkor. A Liligo-ról van szó, mely egy francia cég repülőjegy kereső szolgáltatása, az apropó pedig az, hogy magyarul is elindult a szolgáltatás. A Hírfigyelős bejegyzésemhez képest technikai részleteket is megpróbálok leírni – igen sokat tanultam az oldal kliensoldali leprogramozásának kapcsán.

A hasonló szolgáltatásokhoz képest a Liligo két szempontból is többet nyújt, nem véletlenül szoktam ezt használni én is, amikor éppen repülőjegyet igyekszem vásárolni. Az egyik, hogy a potenciális ajánlatok begyűjtése on-the-fly, avagy a keresés időpontjában, a háttérben zajlik le, mintha valóban végignéznénk az összes ajánlatot. A másik lényegi különbség, hogy optimalizálva van fapados járatokra is, és ha éppen van úgy szolgáltatáspár, akkor képes két fapados szolgáltatótól a legjobb ajánlatot összeválogatni (odaút X szolgáltatóval, visszaút Y szolgáltatóval). Erre jellemzően sem a hazai utazási irodák nem képesek, sem pedig a külföldi hasonló szolgáltatások (melyek leginkább Amerikára vannak felkészülve, szemben a Liligo “mindent lefedő” európai kínálatával).

Az én feladatom anno a keresés frontendjének lekódolása volt, és bevallom nem ment könnyen, mint első komolyabb igazán JavaScript frontend projektem egyrészt több hónapig tartott, másrészt többször is leizzadtam vele. Két éve történt a dolog, anno blogbejegyzéseket is írtam okulásul a Weblabor hasábjain a kérdésről, kérdéskörről AJAX fejlesztés – tapasztalatok, AJAX fejlesztés – megjelenítés, AJAX fejlesztés-kommunikáció címmel. Ezeket a bejegyzéseket jó volt most is visszaolvasni – azóta is aktuálisak, és igazán új megoldások, technológiák sem jelentek meg azóta, melyek széleskörűen használhatóak lennének. Az utóbbi években persze részben már átírásra került a frontend kódja, és kisebb-nagyobb mértékben az oldal designja is változott, de az én fejlesztésemmel indult el az oldal francia változata, és állítólag még most is vannak olyan kódrészek, melyek a nevemhez köthetőek.

Ami érdekes megoldás a szerver oldalon, hogy a kereséskor lefutó robotok programozásához Java alapokon, Rhino motorral kis JavaScript programokat használ a szolgáltatás, nem véletlenül adott elő Xavier Casellato erről az idei Web Konferencián. Az oldal jellegéből adódóan a minél több párhuzamos kiszolgálás érdekében az alkalmazás egy nagy része a frontend kódba lett pakolva, így a szerver oldal feladata a JavaScript programkák futtatása, a kapott adatok nagyon minimális előfeldolgozása, majd pufferelése. A JavaScript kód ezt a puffert olvassa, dolgozza fel, és jeleníti meg folyamatosan. Úgy tudom, hogy ez a megoldás azóta sem változott, részemről egy elég ügyes, és költségkímélő megoldásnak tartom továbbra is.

A szolgáltatás magyar verziójáról tudni kell, hogy – első körben a hazai viszonyokhoz igazítva – kevesebb funkcióval indult el, így haladóbb felhasználóknak érdemesebb lehet az angol, francia vagy német (és más nyelvű) verziók használata, melyek már nem csak repülőjegyeket, hanem hoteleket is tudnak keresni (a francia verzió pedig még több dolgot). Szintén az idegen nyelvű változatok – egy igen érdekes – sajátossága egy a Netvibes-hoz hasonló felület, melyet az angol verzióban a jobb felső sarokban levő “Show My Liligo” linkkel lehet elérni. Gyakorlatilag felépítettek egy specializált Netvibes klónt, az utazások köré épülő widgetekkel, fülek létrehozásának lehetőségével, stb.

A Liligo csapatában többen is magyarok, így már csak ezért is érdekes a projekt számomra. Amiért folyamatosan “lobbizok”, az a szokásos hülyeségem: az API – az olyan konkurens nagyobb szolgáltatásoknak, mint például a Kelkoo és Expedia van már valamilyen API-ja régóta. Ezeket jó lenne ha külső fejlesztők is el tudnák érni, és érdekes szolgáltatásokat a Liligo köré kifejleszteni – ezzel talán még ismertebbé válna az oldal.

Miért WordPress?

A Nintendo Wii blogom kivételével az összes blogom alatt WordPress fut, és nem véletlenül. Ebben a bejegyzésben azt próbáltam meg összeszedni, hogy miért a WordPress motorját gondolom a legjobb blogplatformnak. Vannak egyéb platformokkal is tapasztalataim, de szívesen veszem ha más leírja hozzászólás formájában más motorok számára kínált előnyeit, hátrányait, vagy kitér olyan témákra is a WordPress-szel kapcsolatosan, melyeket itt most nem említek meg.

WordPress

Több lehetőséget is végigpróbáltam már, amit PHP+MySQL, avagy a legnépszerűbb/legolcsóbb hoszting kapcsán ki lehet próbálni, és végül a WordPress mellett tettem le a voksom blogok kiszolgálása kapcsán. Bár sohasem kerestem az okokat, a választás mögött nagyjából a jó alapok, és a jó pluginek állnak.

Az alapok

A WordPress blogok kiszolgálására optimalizált CMS rendszer, ez eleve azt jelenti, hogy feltelepítés után az admin felület és az oldal megjelenítése a blogírás, olvasás igényeit kielégítő megjelenést ad. Ez nyilván egy előny, de ezzel együtt a WordPressben ez tényleg jól is sikerült. Nagyon régi admin felület emlékeim már nincsenek, arra még emlékszem, hogy mikor míg a WYSIWYG editorokat sohasem bírtam igazán, addig amikor megjelent a WordPressben ez a lehetőség, megemeltem a kalapom a megvalósítást illetően. Hasonló jellegű rendszerek esetében mindig is gond a WYSIWYG editor, hiszen a böngészők ezirányú beépített lehetősége sohasem túl barátságos, vannak kisebb-nagyobb hülyeségek. Ugyan nem néztem meg, hogy mit csináltak ezzel a fejlesztők, de egyszerű, jól használható eszközt tettek a kezem alá, és ez a lényeg. A gombsorok is a célszerű, értelmes funckiókat teszik elérhetővé, nincsenek betűkészlet, színek állítására szolgáló gombok, és egyéb hülyeségek, ami meg van, az jól működik. Maradva a WYSIWYG editornál, egy CMS rendszer fejlesztésekor örök probléma a képek (és egyéb fájlok) feltöltése, kezelése is, ez már a WordPress előző verziójánál is jól használható volt, a 2.5-ös verzió megoldása pedig egyszerűen és jól működik.

Az előző WordPress admin felület layoutot, designt illetően is úgy gondolom, hogy bőven jó példaként szolgált, a 2.5-ös verzió designja pedig úgy gondolom, hogy “díjnyertes alkotás”. A kezdeti lépéseket a két verzió közötti váltás során még idegenkedve figyeltem (“nagyon webkettes, de elég béna”), de mire eljutottak a fejlesztők a 2.5 kiadásáig, nagyon jól összepakolták a megjelenést. Nem hiába, több komoly UI designer is dolgozott rajta. Hogy konkrétumokat is említsek, az egyes akciók (mint új blogbejegyzés írása, régiek menedzselése/listája, a félbehagyott régiek) megfelelő kattintásszám után érhetőek el (új bejegyzés – 1 kattintás az admin felületről), a még nem moderált hozzászólások száma az admin felületen bárhonnan látható, a bejegyzés szerkesztő elrendezése a célnak tökéletesen megfelel (cím, bejegyzés tartalma, címkék/kategóriák egymás alatt, mentés és publikálás jobb oldalon). Az olyan “apróságok”, mint a az automatikus mentés, az átméretezhető bejegyzés szerkesztő doboz, a helyből elérhető médiatár vagy azonnali feltöltés “popup”-ban, az elrejthető nem használt mezők, a helyben létrehozható új kategória, a bejegyzés aktuális szavainak száma mind-mind a WordPress melletti elköteleződésem erősítik csak meg.

A WordPress 2.5 újdonsága az igazi Dashboard, ami egy helyre foglalja össze a fontosabb információkat – ez bár eddig is volt, de most lett igazán használható. Köszönhető ez egyrészt a kicsit módosított felépítésének, tartalmának, másrészt annak, hogy a pluginek is be tudnak ide dolgozni, ami még jobb áttekintést tesz lehetővé. A spam-ek kezelése szintén egy olyan dolog, melyet jól old meg alapból a WordPress: beállítható hogy minden hozzászólót egyszeri alkalommal engedélyezni kelljen – ezzel a spamek gyakorlatilag kiszűrésre kerülnek (már ami a megjelenésüket illeti). Jön viszont az adminisztráció, ami egy idő után (amikor a blog ismertté válik a spam robotok felé is) darabra eléggé megnövekszik a sok spam megjelenésével – de hála a JavaScriptes/AJAX-os megoldásoknak és az ügyes elrendezésű felületnek a WordPress-ben nagyon gyorsan végig lehet menni akár több száz spamen is (kb. 1 perc). A korona pedig az Akismet tud lenni, ami ezeket a spameket elég jó hatékonysággal kiszűri, ez egy olyan alapból telepítésre kerülő plugin, amely bár regisztrációt kíván a WordPress.com-on, de elég jó hatékonysággal működik. A hozzászólások jó kezelhetőségét az is segíti, hogy lehet róluk e-mail kérni (illetve alapból a szerző e-mail címére kimennek az e-mailek).

Biztos lenne még pár érv, amit össze tudnék szedni a WordPress mellett, de talán már ezekből is látszik, hogy még ha valakinek nem is jönnek be ezek a megoldások valamiért, azt nem lehet a blogmotorra mondani hogy csak hanyagul összedobálták volna. Más megoldások kapcsán ezen a szinten jellemzően két gond merül fel. Az egyik, hogy az admin menüszerkezete, layoutja nem blogolásra van optimalizálva, több felesleges menüponton is át kell küzdenem magam, ha valamit szeretnék csinálni, vagy csak kiváncsi vagyok rá, míg a másik, hogy jó kis munka, míg alapból kihozza ezeket a lehetőségeket az ember a rendszerből beállítások, pluginek feltelepítése után, és még akkor sem olyan érett a felület, mint a WordPress esetén.

Pluginek

Mindezeket a funkciókat pluginek segítségével turbózhatjuk fel igazán. Az Akismetről már esett szó, nekem még az alábbi bővítmények segítenek be (lustaságból nem linkelem be az oldalaikat, de könnyű megtalálni őket):

  • Fluency Admin – nagyon cool kinézetet varázsol az admin felületnek, fentebb dícsértem az alap admin kinézetet, no, ez még annál is pofásabb, és ha lehet a használhatóságon is lök egy kicsit még tovább (csak a modern böngészőkkel kompatibilis: Firefox, Safari, IE8).
  • Admin Drop Down Menu – a menüszerkezet második szintjét az első szintre kattintok, második szintre kattintok helyett legördülő menüssé varázsolja – mind az alap designnal, mind a Fluency felületével működik.
  • Subscribe to Comments – segítségével a hozzászólók az egy adott bejegyzéshez történő további hozzászólásokról e-mailben értesülhetnek. Alap plugin, kötelező feltenni.
  • Ozh’ Absolute Comments – a hozzászólások kezelése nagyon kényelmes lesz, egy hozzászólásra egyből tudok az admin felületen is válaszolni, nem kell a bejegyzés oldalára is elmenni. Jópár percet lehet vele spórolni.
  • Plugin Central – a 2.5-ös WordPress plugin kezelése sokat fejlődött, pl. admin felületről lehet frissíteni plugineket. Ez a bővítmény lehetővé teszi több plugin egyszerre történő frissítését, illetve új pluginek letöltési URL-jének megadásával azok admin felületről történő telepítését is.
  • Wassup – élőben láthatjuk, hogy kik látogatják éppen oldalunkat (IP cím, hosztnév, hivatkozó oldal, böngésző adatok, hozzászólás szerző infókkal, ismeretlen/belépett/korábban hozzászólt/robot kategóriákba sorolva a látogatókat), illetve visszamenőleges látogatási statisztikákat is képes megmutatni.
  • WordPress.com Stats – elég jó statisztikákat kínál a hivatkozókról, bejegyzéseink látogatottságáról, a keresőkifejezésekről melyekkel oldalunkra érkeztek a látogatók, az oldalunk linkjein történt “kimenő” kattintásokról és a bejövő linkekről. Bár nem egy Google Analytics, annál egy fokkal jobban kézreálló megoldást kínál. Ehhez is WordPress.com regisztráció,

Ezek mellett persze vannak még pluginjeim, de ezek azok, melyeket mindenkinek ajánlani tudok, és nagyon sokat segítettek a blog adminisztrálása, üzemeltetése, blogolás megértése kapcsán.

Egyebek

Az egyebek alá lehet besorolni a verzióváltáskor (nálam svn up pár naponta – az is megérne egy külön misét, hogy mennyire stabil az SVN-ben levő kód) lezajló automatikus adatbázis frissülést, a millió sablont (K2 a kedvenc, de tényleg nagyon sok ingyenesen használható van), a felhasználók optimális kezelhetőségét, az admin felületen szerkeszthető sablonokat és kiterjesztéseket, a widget támogatást.

Mindent összevetve a WordPress-t sok aprósága és a célra termettsége miatt favorizálom, de ahogy a bevezetőben is említettem, ha tud valaki jobbat, ne tartsa magában. :) Egy másik vetülete a kérdésnek: lehet, hogy adott esetben nem a WordPress a megoldás, mert olyanok a körülmények. Bár a WordPress pluginek segítségével elvihető általános CMS irányba is, lehet, hogy éppen nem a legjobb megoldás, mert elég, ha egy másik, vagy saját CMS-t használunk erre a célra. Ha egy oldalhoz akarunk blogot passzintani, és nem PHP+MySQL alapokon készült, akkor Ruby és Perl alapokon is vannak, alakulnak ki jól használható blog platformok, és lehet, hogy egy környezetet összerakni és üzemeltetni kényelmesebb, mint különbözőeket karban tartani. Végül ha blogszolgáltatást szeretnénk indítani, akkor sem biztos, hogy a WordPress mellett kell letennünk a voksunkat – bár hozzáteszem, “kész”, igazán jó megoldásról egyelőre nem tudok ebben az irányban (WordPress MU-val az a baj, hogy ha nagyon kicsi, vagy igazán nagy szolgáltatók vagyunk, akkor működik csak optimálisan).

Netvibes Ginger – ajánljatok tartalmat

A Netvibes Ginger változatában (melyre ma lettek átállítva Corianderről azok akik eddig nem váltottak) megváltozott a tartalmi ajánlók módja, és új kategóriák jöttek létre. Szeretném, ha a magyar rendelkezésre álló tartalmak, avagy RSS/Atom hírforrások, UWA widgetek közül a lehető legjobb válogatást kínálná a Ginger, de ehhez segítségeteket szeretném kérni, mert elég nagy valószínűséggel nem ismerek minden kategóriában minden idevágó tartalmat. Az alábbiakban összegyűjtöttem, hogy milyen kategóriák vannak. Ha bármelyik kategóriába ajánlasz akár csak 1 tartalmat is, már az is segítség.

Előbb azonban arról, hogy mit keresek. Kiegyensúlyozott, szélsőségektől mentes, minőségi tartalmakat várok (nem bulvárt), s egy olyan összeállítást ami a népszerűségi arányokat is minél jobban lefedi. Van olyan kategória amibe túl sok elemet tudnék belepakolni, és ezek megszűrése kapcsán kell a segítség, s van olyan, mely esetben jó ha egyet tudok, itt pedig továbbiak hozzáadása miatt. Azt nem tudom megígérni hogy minden ajánlott tartalom bekerül a végén a lecsóba, de igyekezni fogok jól dönteni.

Íme a kategóriák:

  • Legismertebb blogok
  • Hírek
  • Üzlet
  • Sport
  • Zene
  • Művészet és szórakoztatás
  • Technológia
  • Játék
  • Életstílus
  • Eszközök és szolgáltatások
  • Vásárlás
  • Tudomány
  • Oktatás
  • Utazás
  • Szervezetek

Hogy melyik kategóriába mi illik, azt a http://eco.netvibes.com/widgets oldalán a jobb oldali kategóriák végigkattintgatásával lehet a legjobban megítélni.

Netvibes UWA fejlesztés

A Web Konferenciás, Netvibes UWA témakörben tartott előadásom rövidesen elérhető lesz a rendezvény honlapján, de úgy döntöttem hogy egy blogbejegyzés formájában itt is részletesen közzéteszem az ott bemutatottakat. A cél egy az UWA filozófiáját, megközelítését bemutató widget elkészítése volt, melynek során mind AJAX kommunikációt (RSS tartalom lehívás), mind az előre elkészített építőelemek (fülek, lapozó), mind pedig általában egy widget fejlesztését be tudom mutatni. A végeredmény itt érhető el: Indafotó UWA widget.

Indafotó widget a Netvibes Eco oldalán

A Netvibest remélhetőleg nem kell bemutatnom ezen sorokat olvasóimnak, és az előadásom során sem tette fel senki a kezét amikor megkérdeztem, hogy be kell-e mutatnom a szolgáltatást. Annyit szeretnék elmondani mégis, hogy a közhiedelemmel ellentétben a Netvibes nem feedolvasó alkalmazás, nem a hírek, hanem a felhasználót érintő összes webes szolgáltatás egy helyre való összegyűjtésére szolgál, mintegy információs központként. És ennek csak egy része a hírek, blogbejegyzések olvasása. Ugyanígy jellemzően a többi hasonló szolgáltatás célja is az összes információ egy helyre sűrítése.

UWA widgeteket pont ezért kell készítenünk, hiszen míg a nemzetközi oldalak, alkalmazások jól le vannak fedve, addig a hazai és saját fejlesztésű szolgáltatások nyilván kevésbé. A másik fele a dolognak – amiért megéri egy widgetet leprogramozni -, az a “reklámfelület”, avagy annak lehetősége, hogy brandünkkel a felhasználó folyamatosan találkozzon saját oldalán. A widgetek RSS feedekhez történő hasonlítása több ponton is helytálló amikor valaki felteszi a “miért” kérdést.

Térjünk a tárgyra: a Netvibes UWA egy olyan widget fejlesztést megkönnyítő keretrendszer, mely ebbe a folyamatba illeszkedik. Használjon valaki Netvibes-t. iGoogle-t, Live.com-ot, Apple Dashboard-ot, Windows Vista Sidebar-t. Yahoo! Widgeteket (anno Konfabulator), Opera Widgeteket, iPhone-t, vagy akár JBoss-t, egyszeri, egy widget lefejlesztésével, jellemzően a platformok sajátosságainak ismerete nélkül célozhatjuk meg őt, ha ezt a keretrendszert használjuk.

Az UWA azért született meg, mert nem volt de-facto standard szintű megoldás erre a feladatra, jellemzően minden widget szolgáltatás, widget motor, a saját formátumát használta, a W3C ezirányú standardizálási törekvései pedig eléggé le vannak maradva. Az UWA mögött levő rendszer feladata az, hogy az elkészített widgetünket az összes több platform számára “on-the-fly” átkonvertálja, és azokon működővé tegye. Bár mindegyik támogatott platform HTML+CSS+JavaScript megoldást használ, mindegyik például más és más függvénnyel/formátummal oldja meg a(z AJAX) kommunikációt, a beállítások letárolását és hasonlókat.

Egy UWA widget kifejlesztése jellemzően könnyű, mivel jól dokumentált standardokra épít, avagy XHTML, CSS és JavaScript ismerete szükséges a fejlesztéshez. Ezen kívül az UWA környezet számos segítséget is kínál feed feldolgozás, kontrollok, előre létrehozott CSS osztályok segítségével. Egy UWA widget a következőképpen épül fel:

  • Egy statikus, UTF-8 kódolású XHTML fájl, ami egyben valid XML is. Ez adja a widget vázát.
  • Az XHTML alap egy specifikus Netvibes névtérrel egészül ki: xmlns:widget=“http://www.netvibes.com/ns/”
  • Meta leíró elemeket használ a szerző, widget és UWA verzió, az esetleges automatikus frissítések és egyebek leírására.
  • Speciális widget:preferences elem segítségével írhatóak le a widget beállításai.
  • A widget megjelenése CSS segítségével írható le.
  • A widget működését JavaScriptben kell leprogramozni.
  • A widget indulásakor aktuális megjelenést (jellemzően Loading… felirat) pedig a HTML body-jában kell leírni.

A cél

A célunk egy Indafotó albumokat megjelenítő widget létrehozása lesz. A beállítások között felsorolhatunk felhasználóneveket vesszővel elválasztva, s az ezekhez a felhasználókhoz tartozó legfrissebb képeket jelenítjük meg füleken. A fülek neve az adott felhasználó azonosítója, a fül tartalma pedig x darab kép lesz, mely lapozható. Ehhez az Indafotó RSS interfészét fogjuk felhasználni.

Konkrét tippeket az UWA fejlesztéssel kapcsolatosan ennek az írásnak a végén fogok megosztani, például azzal kapcsolatosan is, hogy pontosan milyen fejlesztői környezetben érdemes elkezdeni kifejleszteni egy widgetet, most viszont szeretném bemutatni azt, hogy hogyan épülhet fel, és hogyan működhet az előbb felvázolt widget.

Az első lépések

Első lépésként hozzuk létre a widget vázául szolgáló XHTML dokumentumot, és indulásként jelenítsünk megy egy fotót, alatta pedig egy tájékoztató szöveget.

A váz így fog kinézni:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:widget="http://www.netvibes.com/ns/">
<head>
<title>Indafotó</title>
<meta name="author" content="András Bártházi" />
<meta name="version" content="1.0" />
<meta name="apiVersion" content="1.0" />
<meta name="autoRefresh" content="20" />
<link rel="icon" type="image/x-icon" href="http://indafoto.hu/favicon.ico" />
<link rel="stylesheet" type="text/css" href="http://www.netvibes.com/themes/uwa/style.css" />
<script type="text/javascript" src="http://www.netvibes.com/js/UWA/load.js.php?env=Standalone"></script>
<style type="text/css">/*<![CDATA[*/
/*]]>*/</style>
<script type="text/javascript">//<![CDATA[
// ]]></script>
</head>
<body>
<p>Loading...</p>
</body>
</html>

Remélhetőleg egy a HTML-t ismerő személy számára semmilyen újdonságot nem mutattam itt most be ezzel a forráskóddal. Ami UWA specifiku, az a szerzőt, a widget verziószámát, az UWA (API) verziószámát) és az automatikus frissítési időt leíró meta elemek. A belinkelt favicon a widget ikonja lesz, a belinkelt CSS és JavaScript pedig az úgynevezett Standalone módban történő működtetésért és megjelenítésért felelős kódokat tölti be. Egy UWA widget többféle körülmények között megjelenhet, az egyik ilyen “körülmény” a Standalone mód, amikor egy web böngészőben nyitjuk meg minden direktben az UWA forrást. Ezt a két sort nem kötelező betenni, de csak nyerünk vele, ha benne lesz az oldalban.

Van egy-egy üres CSS és JavaScript kódrész is – ezekbe fogjuk írni a konkrét kódunkat. Végül, de nem utolsó sorban egy HTML BODY rész jön, amiben egyelőre egy Loading… üzenetet helyeztünk el. Ide a widget funkcióinak függvényében komolyabb HTML-t is lehet rakni, ez az a HTML rész, mely egyből megjelenik. Adott esetben olyan widgetet is készíthetünk, mely nem tartalmaz semmilyen JavaScript-et sem, hanem csak egy HTML-ből áll, például ha egy képet, Flash fájlt szeretnénk csak megjeleníteni.

Egy widget jellemzően különböző eseményeket kezel le. A legfontosabb esemény az onLoad, ez a widget betöltődésekor történik, és ennek az eseménynek a hatására kell beindítanunk a widget működését. Egy esemény lekezelése a megfelelő függvény létrehozásával történik. Indulásként a widget betöltődésekor hívjunk meg egy olyan függvényt, mely megjeleníti a kép és üzenet párost:

widget.onLoad = function() {
	Indafoto.showMessage();
}

És készítsük is el ezt a függvényt:

var Indafoto = {}; 
 
Indafoto.showMessage = function() {
	widget.body.innerHTML =
		'<p><a href="http://indafoto.hu/boogie/image/85596-84fb74c7" target="_blank">' +
		'<img src="http://img2.indafoto.hu/4/9/759_2b3bf3eee2475e03885a110e9acaab61/85596_84fb74c738fba9b5ccd963e4d9da79db_m.jpg" width="100%"/>' +
		'</a></p>' +
		'<p>A widget tartalmát a Beállítások között tudod beállítani. Az "Elemek" értékhez Indafotó felhasználók azonosítóját írhatod be, vesszővel elválasztva.</p>' +
		'<p>Például: <strong>boogie,eszpee,blumi,darthwalk,tschoppy,dtamas</strong></p>' +
		'<p>Fedezd fel az <a href="http://indafoto.hu/">Indafotót</a> további azonosítókat illetően!</p>';
}

Az első sor egy Indafoto nevű objektumot hoz létre. Célszerű az összes függvényünket egy a widget nevével megegyező objektumba pakolni, átláthatóbb, rendezettebb lesz a kód.

Ezután definiáljuk a függvényt, mely a widget tartalmát fogja beállítani. A kulcs a widget.body nevű változó, mely mindig azt a “div”-et tartalmazza, ami a fenti XHTML forrásban a <body> résznek felel meg, a document.body analógiát fedezhetjük itt fel. Ennek a div-ek a tartalmát esetünkben az innerHTML segítségével volt a legegyszerűbb beállítani.

Itt tartunk:

Neki is állhatunk

A következő feladat, és innen már meg sem állunk a végleges widgetig, a widget beállításainak leírása. Ehhez a fejlécbe kell tennünk egy <widget:preferences> részt (én a stíluslap elé szoktam tenni), mely ezt írja le:

<widget:preferences>
  <preference name="title" type="text" label="Cím" defaultValue="Indafotó" />
  <preference name="tabs" type="text" label="Elemek" defaultValue="" />
  <preference name="nbTitles" type="range" label="Db" defaultValue="10"
	step="1" min="1" max="30" />
</widget:preferences>

A különböző beállítási lehetőségeket itt most nem mutatom be, itt most két fajtát használtunk: a text és a range típust. Előbbi egy sima input elemet, utóbbi egy select mezőt fog megjeleníteni, esetünkben 1 és 30 közötti számokkal. Kb. így fog megjelenni – persze ez függ attól is, hogy milyen környezetben, milyen témát választottunk éppen:

Figyeljünk arra, hogy túl hosszú címet ne adjunk, hiszen lehet hogy olyan vékony lesz a widget, hogy nem fog tudni megjelenni. Ugyanez igaz a select elemek választási lehetőségeinek szövegére is.

Alakítsuk át az onLoad eseményt lekezelő részt, hogy ha már kitöltésre került az Elemek rész a beállításoknál, akkor ne a tájékoztató üzenetünk jelenjen már meg:

widget.onLoad = function() {
	if (!widget.getValue('tabs')) {
		Indafoto.showMessage();
	} else {
		Indafoto.ids = widget.getValue('tabs').split(/\s*,\s*/);
		Indafoto.initTabs();
	}
}

A beállításokat mint láthatjuk, a widget.getValue függvény segítségével tudjuk lekérdezni. Ha be van állítva már valami, akkor szétvágjuk a szöveget a vesszők mentén (lesz egy tömbünk a felhasználó azonosítókról), és ezt letároljuk egy változóba. Ezután pedig meghívjuk a fülek megjelenítéséért felelős kódrészletet.

Ami itt is van:

Indafoto.initTabs = function() {
	widget.body.innerHTML = '';
	Indafoto.tabs = new UWA.Controls.TabView({
	});
	for (var i=0; i<Indafoto.ids.length; i++) {
		Indafoto.tabs.addTab(i, {text: Indafoto.ids[i]});
	}
	Indafoto.tabs.observe("activeTabChange",
		Indafoto.onTabChange);
	Indafoto.tabs.selectTab(0);
	Indafoto.tabs.appendTo(widget.body);
}

A widget.body.innerHTML rész már ismerős lehet. A fülek létrehozása már érdekesebb, egy előre elkészített UWA kontrolt, a TabView-t fogjuk ugyanis ehhez felhasználni. Miután létrehoztunk ezt a konrolt, hozzáadunk annyi fület, amennyi azonosítót találtunk a beállítások között (a fül felirata a felhasználó azonosítója lesz), beállítjuk, hogy mi történjen ha másik fülre vált a felhasználó, kiválasztjuk az első fület, majd az egész kontrolt hozzáfűzzük a widgetünk tartalmához. A pontos paraméterezésről nem ejtenék szót, az előbb belinkelt oldalon részletes doksi olvasható róla.

Már csak az a kérdés, hogy mi történik ha fület váltunk (illetve amikor megjelenik az első fül induláskor). Erre szolgál a váltáskor meghívott onTabChange függvényünk:

Indafoto.onTabChange = function(tabId, data) {
	Indafoto.data.currentId = tabId;
	Indafoto.data.offset = 0;
	widget.setTitle(widget.getValue('title') + ": " +
		Indafoto.ids[tabId]);
	if (!widget.data[tabId]) {
		UWA.Data.getFeed("http://feed.indafoto.hu/"+Indafoto.ids[tabId]+
		  "/feed", function(data) {
			widget.data[tabId] = data;
			Indafoto.display(data);
		})
	} else {
		Indafoto.display(widget.data[tabId]);
	}
}

A függvény két paramétert kap, az első az éppen újként kiválasztott fül azonosítója, a másik pedig a fülhöz tartozó adatok. Azt kapjuk a gyakorlatban vissza, amit a fülek létrehozásakor, az addTab függvénynek átadtunk. Az offset beállítása a lapozáshoz kell, azt fogja tartalmazni, hogy hányadik elemtől kell megjelenítenünk a képeket.

Ezután a widget.setTitle segítségével beállítjuk a widget fejlécében látható címet, mely a beállításoknál megadott címből, és az aktuális fül címéből fog állni. Ha még nem töltöttük le az adatot, akkor letöltjük, majd ha megérkezett, akkor letároljuk és megjelenítjük, ha pedig már korábbi fülváltás során már letöltöttük, akkor megjelenítjük.

Az AJAX kommunikációra különböző lehetőségeink vannak, ezek közül most az előfeldolgozást is tartalmazó feed lekérést használtuk. Az UWA keretrendszer tartalmaz egy feed előfeldolgozót, ami egységes formátumra hozza az összes ismert formátumot, legyen az RSS valamelyik verziója vagy Atom formátum. Az UWA.Data.getFeed “szokásos” aszinkron módon működik, vagyis a kérést elindítja, és majd ha megjött a válasz, akkor meghív egy függvényt.

A megjelenítésért a display nevű függvényünk fog felelni, melynek egyetlen paramétereként a beérkezett feed tartalmat adjuk át akkor is ha éppen most érkezett, akkor is ha már a cache-nek nevezhető tömbünkben már benne volt.

Ez a függvény így fog kinézni:

Indafoto.display = function(feed) {
	var tabContent = Indafoto.tabs.getTabContent(Indafoto.data.currentId);
	if (!feed) {
		tabContent.innerHTML = '<p>Nem létező azonosító, vagy egyéb hiba.</p>'
	} else {
		tabContent.innerHTML = '';
		var pager = new UWA.Controls.Pager({
			module: widget,
			limit: widget.getValue('nbTitles'),
			offset: Indafoto.data.offset,
			dataArray: feed.items
		});
		pager.onChange = function(newOffset) {
			Indafoto.data.offset = newOffset;
			Indafoto.display(widget.data[Indafoto.data.currentId]);
		}
		var feedList = widget.createElement('ul');
		var j = 0;
		for (var i = Indafoto.data.offset; i < feed.items.length; i++) {
 
			if (j++>=widget.getValue('nbTitles')) break;
 
			var item = feed.items[i];
			var li = widget.createElement('li');
			var a = widget.createElement('a');
			a.href = item.link;
			a.target = '_blank';
			a.desc = item.content.stripTags().truncate(255);
			a.onmouseover = function() {
				UWA.Utils.setTooltip(this, this.desc, 250);
			}
			var img = widget.createElement('img');
			img.src = item.enclosures[0].url;
			a.appendChild(img);
			li.appendChild(a);
			feedList.appendChild(li);
 
		}
		tabContent.appendChild(pager.getContent());
		tabContent.appendChild(feedList);
		tabContent.appendChild(pager.getContent());
	}
}

Ez az eddigi leghosszabb függvényünk, de ez sem igazán bonyolult. Az első sorában a TabView kontrol megfelelő metódusának meghívásával lekérdezzük azt a “div”-et, amibe pakolhatjuk a tartalmat. Ezután megnézzük, hogy sikerült-e megkapnunk a feed tartalmat, ha nem, akkor egy hibaüzenetet jelenítünk meg.

Az ezutáni kód három fő részből áll. Elsőként létrehozunk egy lapozásért felelős Pager kontrolt, majd felépítjük a képekből álló listát, s végül kipakoljuk ezeket a fülbe.

A Pager kontrolt szintén nem fogom most részleteiben bemutatni, jó a doksija. Beállítjuk a fő paramétereit, melyek azt mondják meg, hogy mennyi elem között kell lapozni, egy oldalra mennyi elem jut, stb., utána pedig egy függvény létrehozásával megmondjuk, hogy mi történjen mikor lapozunk.

A képek megjelenítéséhez létrehozunk egy felsorolást (ul) a widget.createElement-tel – ez a document.createElement-hez hasonló függvény -, majd végigmegyünk a feed elemein, és létrehozunk listaelemeket, azokba linkeket, és azokba képeket.

Végül a fül tartalmának elejére és végére betesszük a lapozót, közé pedig a képekből álló felsorolást.

Ezzel készen is lennénk ami a JavaScript kódot illeti, de hogy jól is nézzen ki a képekből álló felsorolás, még adjuk hozzá a következő CSS kódot a widget fejlécében:

.nv-tabContent ul,
.nv-tabContent ul li {
	display: block;
	margin: 5px;
	padding: 0;
	background: none;
}
.nv-tabContent ul li {
	background: #000;
	padding: 1px;
	float: left;
}

És már működik is a widgetünk:

Tippek és trükkök

Összegyűjtöttem pár tippet és trükköt is, melyet nem árt, ha ismerünk ha UWA widget fejlesztésére adjuk a fejünket. Íme:

  • Mindenekelőtt olvasd végig a teljes doksit, és nézzed át a fejlesztői blog bejegyzéseit, különös tekintettel az archívumra. A doksi nem hosszú, de számos további tippet és trükköt sorol fel, kitérve esetleges platform sajátosságokra is. Mindenképpen javaslom ezt a lépést, mert sokkal jobban képbe lehet jönni a lehetőségeket illetően, nem beszélve a példakódokról.
  • Az UWA widgeted különböző böngészőkben, különböző platformokon fog futni. A Netvibes oldalán “bármilyen” böngészővel használhatják, az Apple Dashboardon WebKit, Opera Widgetként Opera megjelenítő motor fogja megjeleníteni. Használj szabványos megoldásokat (XHTML, CSS, JavaScript), melyek mindegyik böngészőben, motorral működni fognak!
  • Az UWA működéséhez főként az szükséges, hogy a feldolgozóscript hozzáférjen a kódunkhoz. Ez akkor lehetséges csak, ha a kódunk valamilyen publikusan elérhető címen, egy webszerveren érhető el. Kivétel a Standalone mód, de azt nem ajánlom fejlesztésre.
  • Az UWA fejlesztést legegyszerűbb élesben végezni. Ehhez látogasd meg a Netvibes oldalát, válaszd ki a tartalom hozzáadását a felső sávból, az Esential widgeteket, majd onnan (lapozás után) az UWA widgetet. A beállítások között add meg a widgeted címét, majd kattintsd be mind a két checkbox-ot: legyen inline is a widget, és tiltsad is le a cache-t. Így a widget refresh gombjának megnyomásával mindig a legfrissebb kódod lesz meg.
  • A widget refresh gombja mindaddig újratölti az egész widgetet számodra, amíg le nem kezeled az onRefresh eseményt. Ezután a teljes oldalt kell újratöltened, ha a widget kódját újra szeretnéd tölteni. Ha már van Netvibes oldalad, hozz létre egy üres, csak a fejlesztett widgetet tartalmazó fület a fejlesztéshez.
  • Minél több dolog kerüljön bele a widgetbe, minél kevesebb információt tölts be. Így lesz gyors a widgeted.
  • Ne használj egyedi id-kat a widgeteden belül, mivel előfordulhat, hogy a widgeted több példányban jelenik megy egy ugyanazon oldalon belül, ekkor pedig ütközés léphet fel az id-kat illetően. Használj class-okat, és a widget.getElementsByClassName(‘class’)[0] formát.
  • A függvényeidet tegyed egy a widget neve alapján elnevezett objektumba, pl. var Widgetem = {}; Widgetem.display = function() {}; Widgetem.hide = function() {}; stb. Így jóval áttekinthetőbb, szebb kódot kapsz, és nem fog semmivel sem ütközni a függvény elnevezésed (ki tudja melyik platform milyen függvényeket használ…)
  • Kódolj angolul, ha segítséget kell kérned, jóval könnyebb lesz kommunikálnod, nem kell még a fordítással is foglalkozni. Jelenleg több külföldi, angolul beszélő fejlesztő van a világon, mint magyar. :)

Linkgyűjtemény

Pár link, melyek segíthetnek a fejlesztés során:

Ginger újdonságok

A Ginger még regeteg mindent fog hozni az UWA kapcsán, de már most elérhető két újdonság:

  • widget.readOnly – ha publikus oldalon jelenik meg a widget, akkor igaz az értéke, különben hamis – publikus oldalon másképp viselkedő widget készíthető segítségével
  • widget.addStar – bármilyen link + szöveg pár hozzáadható a Netvibes hírfolyamhoz is – a Ginger szociális újdonságai kapcsán

Ezeken kívül is készülünk az OpenSocial-lal, és egyéb meglepetésekkel.

Összefoglalás

Nem lett rövid olvasnivaló amit a fentiekben összeszedtem, illetve az előadásomban előadtam, főként akkor, ha még utána is olvasol a lehetőségeknek. Remélem hasznos információkkal bírtam szolgálni, és több magyar UWA widget fog készülni a jövőben.

IndaFotó Netvibes UWA widget előzetes

Lassan befejezem a widgetet, melynek a fejlesztését be fogom mutatni a holnapi konferencián. Twitteren felmerült, hogy az Inda/Index fizet-e a fejlesztésért: de nem, ez most nem egy szponzorált widget lesz, hanem a szolgáltatásuk, és annak megújulása kapcsán úgy gondoltam, hogy megérdemelnek ennyi reklámot. Íme két képernyőkép:

Részletek tehát holnap!

Hírfigyelő – elindult végre

Tegnapi nap folyamán elindult a Hírfigyelő, melyet a legegyszerűbb úgy jellemezni, hogy egy Netvibes klón. Az oldalnak igen-igen kalandos története van (pl. hogy régebbi állapotát a Netvibes jelentkezésemkor használtam fel referenciaként…), de most nem erről szeretnék szót ejteni, hanem arról, hogy mit tud a jelenlegi változat.

A Hírfigyelő jelenlegi állapotában egy olyan hír/feed olvasó alkalmazás, mely dobozok kihelyezésével, akár több fülre szervezésével teszi lehetővé napi híradagunk áttekintését. Bár az oldal még több sebből vérzik (számos kisebb-nagyobb hiba van az oldalon, melyek jelen pillanatban legalább kényelmetlenné teszik a használatot), sikerült egy jól átlátható designnal kijönni, az alap funkciók egyszerűen érhetőek el. A konkrét hibákat most nem kezdem el felsorolni, ezek remélhetőleg előbb-utóbb javításra kerülnek.

Pozitívum az OPML importálás lehetősége, az előre összeállított fülek (nincs Webakadémia! :) ) és az oldal által már ismert források felajánlása amikor elkezdem gépelni egy feed URL-jét. A feedolvasó designmentességét illetően vannak gondjaim, de a feedek közti váltási lehetőség a kenyérmorzsa navigációval szintén jól sikerült. Amit fájlalok, azok az olyan alap funkciók, melyek már elvárhatóak lennének egy ilyen oldaltól 2008-ban, gondolok itt arra, hogy egy adott feed-nél beállítható legyen a megjelenített elemek száma, hogy átírható legyen egy doboz címe, hogy átírható legyen egy feed URL a dobozban. Szintén elég nagy hiányosság az, hogy a dobozokat nem lehet a fülek között ráncigálni – ha rossz fülre vettem fel egy dobozt véletlenül, akkor semmilyen módszer nincs azt áthelyezni. Az a trükk sem segít, hogy fogom és kimásolom a feed URL-jét, mert nem lehet elérni ezt az információt.

Hiányosságként élem meg a fülek helyben történő átnevezhetőségét (a kis prompt ablak 2008-ban már nem trendi), ikonok hozzárendelhetőségét, a fülek számának jelzés nélküli korlátozását. Ha van OPML importja az oldalnak, akkor illendő lenne az OPML exportálást is megoldani. További hiányosságokat a jelen verzióval kapcsolatosan nem igazán tudok felsorolni, mert annyira le lett egyszerűsítve a koncepció, hogy ennek keretében hirtelen más nem hiányzik.

Az oldalon jelenleg csak és kizárólag feedolvasó dobozok kaptak helyet. Ez várhatóan változni fog rövidtávon, és lehetőség lesz saját dobozok lefejlesztésére is külső fejlesztők által, mely a tervek szerint nagyon egyszerűre lesz véve. Az oldal üzemeltetése szempontjából nagyon fontos szempont lehet, hogy mennyire sikerül az egyszerűség megtartása melett a sebességet, terhelhetőséget, biztonságot is megvalósítani – és természetesen tovább fejleszteni új funkciókat bevezetve. A biztonságot illetően már most vannak óriási hiányosságok, reméljük lassan de biztosan ezek is ki lesznek küszöbölve.

Kérdés persze, hogy mennyire van létjogosultsága ma egy ilyen jellegű magyar oldalnak, hogy ha a külföldi megoldások (mint a mintául szolgáló Netvibes) nagyságrendekkel előrébb vannak a felhasználói tábort, funkciókat, lehetőségeket, biztonságot és nem utolsó sorban erőforrásokat (nem 1 fő fejlesztő, hanem 20; több nagyságrenddel nagyobb pénzügyi lehetőségek) illetően. És hozzá kell tenni, hogy jön az IndaStart is, így nem csak külföldi, hanem hazai konkurenciája is lesz az oldalnak, várhatóan nem is akármilyen. Ezzel együtt az alapok jónak tűnnek (és most nem csak a kódra gondolok), sok-sok szorgalommal, munkával azért a helyzet nem reménytelen.

Feedolvasók aránya

Nemrégiben álltam át a Feedburnerre a feed tartalmak kiszolgálását illetően (elvileg akik a régi feed URLekre vannak feliratkozva, ők is az új feed tartalmat kapják), így van már pár napja statisztikám arról, hogy mekkora az egyes feedolvasók aránya a Webakadémián. A dolog azért is aktuális, mivel az Index/Inda hamarosan előáll a saját feedolvasójával IndaStart néven, így egy hónap múlva érdekes lesz megint ránézni hogy mi a helyzet (remélhetőleg mérhető lesz a dolog). Nálad milyen arányú a Netvibes és a Google?

A Google jellemzően az iGoogle és a Google Reader, a Netvibes pedig csak a Netvibes oldalt mutatja: 46%-ot visz el a Google, 36%-ot a Netvibes, a maradék pedig a többi feedolvasóra marad. Az arány persze változik nap-mint-nap, de jellemzően 10% a különbség a kettő szolgáltató között. Az egyéb feedolvasók közül nem nagyon emelkedik ki egy sem.

Update: Teljesen megfelejtkeztem a Hírfigyelőről mint potenciális indulóról – a Hírfigyelő is elindult a napokban.

Hogyan NE írjunk APIt? Az IWIW első lépései

Benjamin aposztrofálta a hónap IWIW fejlesztésének, miszerint az IWIW elkövetett valami olyat, ami igazi API-nak nevezhető: egy felhasználó fotói elérhetőek RSS-ben is. Ennek nagyon megörülve el is határoztam, hogy összedobok egy widgetet belőle, már csak azért is, hogy az IWIW lássa a hazai fejlesztői támogatást és érdeklődést az ilyen lépések iránt. Két dolognál bukott el a dolog…

IWIW API

Egy felhasználó képeinek URL-je http://www.iwiw.hu/pages/misc/gallery.jsp?userID=xxxx&tab=images formájú, ahol az xxxx a felhasználó azonosítóját jelenti. Az első, és legnagyobb gond, hogy ez a cím használhatatlan, mivel csak akkor elérhető, ha be van jelentkezve a kliens az IWIW-re. Ezt egy widget platformon, ahol vagy egy szerver oldali alkalmazás szedi le az adatokat az IWIW-től, vagy egy olyan böngésző, amivel nem vagyok feltétlenül bejelentkezve (gondolok itt az Apple Dashboard-ra), vagy egy idő után kijelentkeztet a rendszer, bár kivitelezhető a lekérdezés, nem mondanám, hogy egyszerű a dolgom. Ez az URL tehát akkor és abból a böngészőből érhető el csak, amikor és amivel be vagyok jelentkezve az IWIW-re. Nem ragozom, használhatatlan tehát a hozzáférés.

Egy másik kisebb-nagyobb gond, hogy az IWIW nem nyújt olyan API-t, amivel egy felhasználó nevéből megkapható lenne a felhasználó azonosítója. Egy widget az nem geekeknek készül, hanem átlag felhasználóknak, elmondani neki hogy hogyan nyerheti ki a saját vagy ismerőse “felhasználói azonosítóját” (azmiaz?) – hát nem egy egyszerű dolog.

A lépés értékelendő az IWIW részéről (részemről pont ilyen kis lépéseket gondolok célszerűnek), de így nem ér semmit sem. Hozzátenném, hogy mivel pletyka szinten értesültem a dologról, lehet hogy az IWIW nyújt olyan megoldást, melyről nem tudok. Lehet hogy nem ártana ezeket a fejlesztéseket publikus fórumon közzétenni, egy kis fejlesztői dokumentációval?

TV műsor API

A StartUP konferencián beszélgettünk az API-król, s ennek a vitának a kapcsán vetette fel valaki (nem vagyok benne biztos, hogy konkrétan a vitán), hogy milyen jó lenne egy filmes, TV műsoros adatbázishoz hozzáférő API. Van egy projekt, aminek kapcsán éppen kialakítás alatt áll nálunk egy ilyen adatbázis, a hosszú hétvégén a TV műsor részhez össze is dobtam egy API jellegű hozzáférést. Arra lennék kiváncsi, szerintetek mi hiányzik belőle? Mire használnátok fel?

Kezdetnek íme az előzetes: http://barthazi.hu/jaccoter/tvmusor/api.php?type=xml&channel=m1+m2&day=20080324 – a TV csatorna, csatornák nevét, és a dátumot kell megadni, illetve a kívánt formátumot, ami PHP, XML és JSON lehet. A műsor jellemzően pár napra előre elérhető, és egyelőre nem töltjük az adatbázisba, csak a népszerűbb adókat. Az API jelenleg minden korlátozás nélkül használható, az URL viszont előbb-utóbb megszűnik (pontosabban átalakul).