Monthly Archive for 2008. június.

Mi az a Plurk?

Miután jópáran megírták már a véleményüket a Plurkről, én is beállnék a sorba, talán tudok majd pár dologban újat, mást mondani. A címmel ellentétben már le se írom, hogy mi ez, inkább csak azt, hogy mi is van a dolog mögött, és felépítéséből adódóan miért működik úgy, ahogy. És a Twitter? Folyamatosan ássa a saját sírját.

Plurk

A legtöbben a Plurköt a Twitterhez hasonlítják, és nem véletlenül, azonos a kategória: úgynevezett mikroblogolás. Kategórián belül azonban rengeteg különbség van: “forradalmi” interfész, fórumos/chates szerkezet, API hiánya, karma rendszer, beágyazható képek, videók. És ezek a kisebb-nagyobb változtatások teljesen átírták a játékszabályokat is.

Interfész

Az interfész szép színes, magával ragadó, a forradalmi jelzőt pedig a vízszintes timeline-ra értettem az előbb. Nem azért, mert hatalmas újdonság lenne, hanem azért, mert ilyen megoldást weben még nem láttunk sohasem – ráadásul ami a technikát illeti jól is működik. Az áttekinthetőséggel azért vannak gondok: nehéz visszanézni ki mit írt, sokat kell görgetni, mikor ez az információ sokkal kisebb helyen is elférne egy “hagyományos”, Twitter szerű nézetben. Amennyit azonban ront az áttekinthetőségen ez a nézet, majdnem annyit javít is, ez a kettősség okozza azt, hogy sokan nem tudunk mit kezdeni a felülettel.

Vegyük észre azt is, hogy míg a Twitter megmaradt a JavaScript nélkül nagyrészt működő felületnél, addig a Plurk egy webalkalmazás. Ez a háttérben jobban optimalizálható architektúrát is jelent, bár valószínűleg nem ezzel az előnnyel fogják lenyomni a Twittert. Mindenesetre ennek a felépítésnek köszönhetően a felület jóval dinamikusabb, érdekesebb lett.

Fórumos/chates szerkezet

Míg a Twitter egy lapos, egymás után időben következő üzenetekből összeálló üzenetfolyam, addig a Plurk lehetővé teszi egy adott üzenetre “helyben” történő, egyértelmű válaszadást, elkülönítve ezzel a többi üzenettől a válaszokat. Ez is a dinamikusságot javítja – és rontja az áttekinthetőséget, ugyanis ezek a válaszok sok klikk után tekinthetőek csak meg. Ez a lehetőség azt is elősegíti, hogy kevésbé érdekes válaszok is szülessenek – míg a Twitternél a közösség nyomása miatt visszafogja magát az ember, és egy “Jó reggelt!” üzenetet nem reagál le mindenki (káosz lenne), addig a Plurknél ezt büntetlenül meg lehet tenni – így rengeteg “felesleges” üzenet generálódik (azért nem véletlen az idézőjel).

API hiánya

Míg a Twitter elterjedésének kezdeteitől rendelkezett API-val, a Plurk esetén tudatosan/nem tudatosan, de ez még nem áll fenn. Így valószínűleg sokkal nagyobb arányban szokják meg a webes felületét, és ragadnak oda, jobb lesz az API/webes felület használati arány. Az üzenetek szerkezetének viszonylagos bonyolultsága, és a webes felület timeline-os nézete miatt ráadásul bonyolultabb lesz a mashupok készítése is. Az API lehet a Plurk egyik kitörési pontja, ami majd dobhat egy nagyot a Twitter elleni harcban – és ez be van ígérve.

Karma rendszer

Az ember hiú, így a karma rendszerrel, és az egyes szintekkel jövő kockacukrokkal motiváltak a felhasználók a fejes ugrásra, ez az egyik kialakítója az addikciónak. A karmázás egyébként ügyes összetevő, és azt kell mondjam, hogy tényleg jól sikerült, nem tűnik erőltetettnek. Animált banános gif smiley, 2008? És mégis hogy rákattantak a felhasználók. :)

Beágyazható képek, videók

Az egyik dolog, amit a Twitter igazán megléphetett volna, valamiért mégsem tette, a beágyazható képek, videók lehetősége. Sokkal kényelmesebb helyben megnézni egy belinkelt videót, mint a videó eredeti oldalán, ráadásul a felhasználó helyben, tovább marad az oldalon. Terheltség szempontjából pedig közel nulla a hatása, hiszen az egész leprogamozható kliens oldali JavaScripttel is akár.

A Twitter még kitart, de…

A Plurk a fenti tulajdonságaival jóval több időt von el a felhasználóktól, mint a Twitter, azzal, hogy színesebb, karmás, dinamikusabb, a fiatalok – akiknek jóval több idejük van a “munkásosztálynál” – sokkal inkább rákattantak, mint az “idősebb” felhasználók. Érdekes látni, hogy míg egyeseket a Twitter nem fogott meg, a Plurk meg tudott.

Jelen felállásban a Plurk nem fogja tudni megfogni a Twitter felhasználók nagy részét, de ezen még változtathatnak, ha akarnak. Egyik eleme a változtatásnak ahogy az előbb is emlegettem, az API lehet. Egy egyszerűbb felület leprogramozásával, jobb követhetőséggel, kliens oldali programokkal meg lehet oldani egy részét annak, hogy rengeteg időt elvon az oldal. Egy másik durranás egy felhasználói felület újdonság lehet, amiről közelebbit nem tudok hirtelen mondani, de érzem, hogy egy apróság hiányzik a jobb használhatósághoz (lásd mikor iWiW bevezette az e-mail értesítőket). Ha ezt sikerül megtalálniuk a fejlesztőknek, akkor nagyot szakíthatnak.

Mit adott nekünk a Plurk

A Plurk különböző megoldásaiból nagyon sokat tanulhatunk. A timeline kapcsán megmutatták, hogy egy jól használható felület, egy SVN kommitokat tartalmazó idővonalat, vagy más eseményeket, híreket simán el tudok képzelni egy ilyen megjelenítésben. Valószínűleg több alkalmazás kapcsán találkozunk ezzel az UI megoldással. Ez a helyzet a felület további részeire is, néhány dolgot nagyon ügyesen megoldottak, míg amit nem, azt is folyamatosan csiszolgatják.

A biznisz

A Twitter egyik nagy előnye, hogy az automatizált információszórás nagyon kiválóan megoldható vele. Blogok, “celebek” twitteren teszik közzé friss információikat, legyen az egy friss blogbejegyzés, egy fontos esemény, vagy valamilyen fejlesztés, vélemény, gondolat. Ezt a lehetőséget a Plurkben egyelőre nem érzem, mert túl nagy egy üzenet elveszésének az esélye, bár persze az API hiánya is visszafogja ezt egyelőre. Ha pörögni fog az oldal, akkor várhatóan az üzleti alkalmazást is meg lehet majd találni rajta – ez egy nyitott kérdés még mindenesetre.

Vége-e a Twitternek?

A Twittert a jelen felállás szerint ha legyőzi valami, akkor az a totálisan dilettáns cégvezetőség lesz, nem pedig bármelyik konkurencia. Ha a Twitter a mai Apple WWDC közvetítést nem bírja ki, az várhatóan egy jelentős pofon lesz számára, és tényleg beindíthatja a lejtmenetet, főként hogy sokadszorra bejelentették, hogy most aztán bírni fogják. A Twitternek nem ártana a stabilizáció mellett valamit innoválnia is, az “unalom” is fontos szempont lehet a váltásban, már nagyon régóta semmi lényegi újdonság nincsen a felületében, működésében.

Jövő

A Plurk érdekesen robbant be az életünkbe, az A-csapatot :) dícséret illeti, jó alkalmazást raktak össze. Hogy mi lesz a jövő, azt pedig pár hét múlva meglátjuk, mindenesetre úgy érzem, hogy a Plurkben több van annál, mint hogy most van egy kis hype, aztán majd lenyugszunk. Addig is tessék követni Twitteren és Plurkön is!

SquirrelFish: új JS motort kap a Safari

Új JavaScript motort kap, kapott a Safari, illetve a mögötte levő WebKit böngészőmotor – a motor kódneve SquirrelFish. Az új JavaScript virtuális gép gyorsabb az összes eddigi konkurenciánál, konkrétan az előző WebKit megoldásnál, és a Firefox SpiderMonkeynál és a Flash ActionScriptjéből örökölt, a tervek szerint a Firefox jövőbeni JavaScript motorját adó (FF4-től) Tamarinnál is. A “mókushal” (használt magyar kifejezés) egyébként akármilyen hülyén is hangzik, egy létező alfaja(?) a halaknak, latinul Holocentrinae néven szokás emlegetni őket, és kifejezetten bamba a fejük.

Kis biológiai kitérőnk után visszatérve a JavaScript virtuális gépekhez, a SquirrelFish egy elég modern alapokra építkező, mindenféle bűvszót felsoroló motor, mely már akár ki is próbálható (WebKit Nightly Builds), aki a pontos részletekre kiváncsi, az olvassa el a bejelentést. További jó hír, hogy tovább szeretnék optimalizálni a motor teljesítményét, és elviekben még van is hova. A sebességnövekedés mindenesetre látványos (hozzáteszem, a WebKit 3.1-ben a gyorsítást részben különböző ügyes trükkökkel érték el, nem pedig a konkrét motor gyorsításával):

A hír azért érdekes egyébként, mert egyre több helyen találkozunk JavaScriptre épülő megoldásokkal a weben kívül is, és a modern JavaScript motorok képesek megközelíteni (ha nem meghaladni) az egyéb virtuális gépekre építő nyelvek sebességét, s mivel maga a JavaScript még bőven modern nyelvnek is nevezhető, egy egyre jobb és szélesebb körben is használható nyelvet fogunk kapni. Persze ha a böngészőkben is nő a teljesítmény, és egy AJAX-os oldal nem fekteti kétvállra a böngészőnket, akkor az se egy utolsó hír.

Kipróbálva a fent belinkelt WebKit-et, szubjektíve nem éreztem jelentős gyorsulást JavaScriptet extrém módon használó oldalaknál, de az tény, hogy szépen és gyorsan teljesített a motor. A Mozillások is végeztek teszteket (ennél objektívebb módszerekkel), így jött ki, hogy 40-50%-kal gyorsabb ez a motor a Mozillás implementációknál. Persze ők sem fognak a babérjaikon ülni – a lecke fel lett adva. Jó látni, hogy erős fejlesztések vannak ezen a téren.

Wikia Search

Itt a Wikia Search, és működik, legalábbis ezt mondják rá. Ami biztosan igaz, hogy a most beindult szolgáltatás úgy tűnik hogy jó alapokra épít, a kivitelezése (ami az interfészt illeti) pedig egész jó lett. Hogy a jövőben hogyan fog működni, az már egy másik kérdés.

Alapvetően kételkedésemnek adnék hangot, miszerint nem hiszem el, hogy a koncepció működőképes, de hát nem hiszem hogy van valaki, aki ne ugyanezt mondta volna a Wikipédiával kapcsolatosan, aztán mégis “egész jól” állunk. A Wikia Search nagyon hasonló koncepcióra épül, wiki szerűen szerkeszthetőek a kereső találatai, melyek a Wikipédiára, és egyéb forrásokra is építenek. Ha nem vagyunk elégedettek, akkor pedig vagy átszerkeszthetjük a találati listát, vagy pedig egy kattintással átugorhatunk a Google/Yahoo/egyéb kereső találataira.

Az örök kérdés, hogy nem lesz-e a kereső a spammerek áldozata, és akárki akármit is mond, ezt nehéz lesz elkerülni. Lehet, hogy van erre valami okos stratégia, Jimmy Walesről (aki a Wikipedia alapítója és a Wikia Search mögött is ő áll) mindent el lehet mondani, de hogy nem gondolkodna, azt nem. A szolgáltatás egyelőre úgy tűnik hogy “szabad préda”, egyelőre bárki bármit tud szerkesztgetni, akár jót, akár hülyeséget felvinni. Pár keresőkifejezésre, melyek a Wikipédiában is szerepeltek, bár nem rossz találatot produkált, azért mondjuk úgy, hogy messze van még a tökéletesről. Hogy mi lesz a dologból, azt pedig meglátjuk, elég rizikós vállalkozásnak tűnik a dolog…

Magyar Netvibes blog

A Netvibes egyre sikeresebb külföldön, és magyar blogokon is elég sokat hallani róla, a hazai piacon is szép arányt ért el a konkurens Google-lel szemben. A hazai mainstreambe persze nehéz betörni, ennek kapcsán gondoltam ki, hogy lehetne indítani egy szigorúan felhasználóknak szóló blogot, ahol az alapoktól a bonyolultabb lehetőségekig bemutatásra kerül a Netvibes, tartalmi és egyéb tippekkel megfűszerezve. Ha van erre érdeklődés, és találok 2-3 jelentkezőt aki szívesen besegítene, akkor be is indítanám ezt a blogot. Tehát jelentkezőket várok!

Netvibes blog

Magyarországon elég kevesen használnak “webkettes” szolgáltatásokat, és hát a hazai szolgáltatók sincsenek a topon amikor a widget fejlesztésről van szó (érthetően, hiszen miért fejlesztenének olyan platformra, amit kevesen használnak), de ez szerintem lassan de biztosan változni fog, ha más módon nem, hát a fiatal generáció felnövésével. Ennek ellenére szerintem érdemes lehet egy olyan blog, mely a már mostani felhasználóknak is segítséget és tippeket nyújt (mennyi apróság van, ami nem ismert, de kényelmesebbé teszi a használatot!), és segít az új felhasználóknak is az ismerkedésben, a hasonló szolgáltatásokkal történő összehasonlításban.

Egy ilyen – szigorúan nem hivatalos – blogot jómagam valószínűleg nem tudok elvinni egyedül időhiány okán (pedig bőven lenne miről írni!) – olyan a Netvibes iránt érdeklődőket keresek, akik eddigi tapasztalataikat megosztanák, vagy egy jövőbeni ismerkedés során leblogolnák azokat.