Magyar Opera

Miért fontosak a minialkalmazások?

Tegnap az Opera - a 10.51 megjelenése mellett - fontos bejelentést tett. Bemutatta ugyanis az üzleti felhasználóknak a mobiltelefonokra szánt új minialkalmazás motorját, ami immár a keresztplatformos felhasználói felületet használja.

Ennek a legnagyobb előnye nyilvánvaló: az Opera megjelenítő és JavaScript motorját használva meglehetősen összetett, online vagy offline alkalmazások fejleszthetőek, ráadásul szinte minden telefonon és operációs rendszeren elérhetővé tehetőek. Az egységes megjelenés pedig lehetőséget biztosít a márkaidentitás megtartására, a használt készülékek típusától függetlenül.

A következő évek talán leggyorsabban fejlődő piaca a mobilos alkalmazásoké, és az sem elhanyagolható, hogy az online kapcsolatra képes programok eladásul és a generált adatforgalom révén is hasznot hajt a szolgáltatóknak, így vonzó lehet számukra az Opera új megoldása.

Az Opera Insight nevű, befektetőknek és partnereknek szánt online magazinban ebből az apropóból Malik Kamal-Saadi-t, az Informa Telecoms & Media médiakutató cég vezető elemzőjét faggatták. Alant az "interjú" szabad(!) fordítását olvashatjátok.

Az alábbi interjú eredetije az Opera Insight internetes magazinban jelent meg 2010. márciusában.

Segítik majd a minialkalmazás motorok a mobil üzletág fejlődését?

A minialkalmazás motorok igen alkalmasak a webes tartalmak megjelenítésére és kiaknázására, különösen a mobil felhasználás esetén. Ezek a rendszerek jobb minőségű szolgáltatást nyújtanak, mint a WAP, miközben a teljes értékű HTML böngészőkhöz képest kevésbé memória- és számításigényesek.

Ezen felül a minialkalmazások sosem látott mértékű testreszabást és irányítást tesznek lehetővé a szolgáltatók számára, ami a böngészőkkel nem volna lehetséges. Mindezek az újdonságok több lehetőséget biztosítanak a bevételek növelésére - feltéve persze, hogy sikerül felülkerekedni a technikai és stratégiai kihívásokon.

Radikális változások a mobil iparban

Az Informa Telecoms & Media úgy becsüli, hogy a 2009-es világválság 9,8%-os mennyiségi, és 12,1%-os értékbeli visszaesést okozott a mobiltelefon-iparnak a megelőző évhez viszonyítva. Noha a piac várhatóan két éven belül újra visszaáll a korábbi szintre, a fejlett piacokon a készülékeladások már elérték a csúcsot, ami az OEM gyártókat növekvő versengésre kényszeríti.

Az árháború csak fokozódik az olyan új szereplők színre lépésével, mint az Apple, a Google vagy a RIM, hiszen ezek innovatívabb termékek kiadására és az árak csökkentésére kényszerítik versenytársaikat, különösen az okostelefonok szegmensében.

Egyre világosabb, hogy a készülékgyártók a fejlett piacokon nem hagyatkozhatnak a telefon eladásokra, ha fenn akarják tartani a jelenlegi növekedési ütemet. Új lehetőségek után kell nézniük, például részt kell venniük a tartalomfejlesztésben és szolgáltatásokat nyújtaniuk az alkalmazásboltokon és - ami még fontosabb - az interneten keresztül.

Ez a folyamat már el is kezdődött, hiszen néhány gyártó - többek közt a Nokia, az Apple, a Samsung, az LG, a RIM a Sony Ericsson és a Motorola - olyan végfelhasználókat célzó üzleti modelleket próbálnak létrehozni, amik a készülékeket a kínált szolgáltatásokhoz kapcsolják. Ez nem csak azt teszi lehetővé számukra, hogy megkülönböztessék magukat a többiektől azáltal, hogy a felhasználóknak az eddigieknél komolyabb felhasználói élményt nyújtanak, hanem új bevételi forrásokat is jelent azáltal, hogy a saját, vagy a mobil szolgáltatókkal közösen üzemeltetett szolgáltatásokat kínálhatják megvételre.

Ez a folyamat azt mutatja, hogy az iparág egy új korszakba lép, ahol a termékeket elsősorban a szoftverek különböztetik meg, nem a hardver. Azok a gyártók, akik felkészülten várják ezt a komoly változást előnyben lesznek azokkal szemben, akik még mindig a hardvert tekintik elsődlegesnek.

Amióta az Apple bemutatta az iPhone-t, a legjelentősebb mobilszolgáltatók komoly lépéseket tettek szoftverstratégájuk megváltoztatása érdekében, hogy jobban alkalmazkodhassanak a mobil nethez. Lassan a mobil internetes megoldások - különösképpen a minialkalmazások - adják a mobiltelefonok fő karakterét. Minden készülékgyártó látja már a minialkalmazások kínálta lehetőségeket, ami által növelhetik telefonjaik értékét és kiegészíthetik bevételi forrásaikat.

Kezdetben azzal próbálkoztak, hogy előre telepítettek néhány alkalmazást a telefonjaikra. Jelenleg egyre inkább arra törekszenek, hogy komplett "minialkalmazás ökoszisztémákat" hozzanak létre, ami magában foglalja ezen kiegészítők fejlesztését, elterjesztését, telepítését, megjelenítését, üzemeltetését és persze pénzzé tehetőségét.

A mobilszolgáltatóknak ráadásul egy másik komoly kihívással is meg kell küzdeniük, hiszen a hangalapú szolgáltatások bevételei csökkennek, ugyanakkor a külső résztvevők által generált tartalomszolgáltatások bevételei sokkal gyorsabb ütemben növekednek, mint a szolgáltatók saját hasonló megoldásai esetén. Utóbbiak zárt szolgáltatásai jórészt képtelenek voltak meggyőzni a felhasználókat és egységes élményt nyújtani a számukra.

Az OEM-ek (készülékgyártók) egyre aktívabb részvétele, a szoftverfejlesztő cégek és a külsős tartalomszolgáltatók mellett nyilván nem kívánják eljátszani az egyszerű adatközvetítő szerepét. Kétségbeesetten igyekeznek jobban beágyazódni az alkalmazásfejlesztés területén, hogy ők is kiaknázhassák a mobil internet gazdagságát.

A legnagyobb szolgáltatók közül néhányan már nyíltan beismerik, hogy egyedül képtelenek megteremteni ezeket a szolgáltatásokat, és harmadik fél bevonásával kísérelnek meg létrehozni versenyképes ajánlatokat és egy fenntartható üzleti modellt. Ezek a folyamatok idővel átformálják majd a teljes mobilipart és a szolgáltatóknak lépniük kell, ha vissza akarják nyerni a mobil szolgáltatások rendszere feletti ellenőrzést.

A mobilipar legjelentősebb változásai az utóbbi két évben:

  • A legjelentősebb telekommunikációs cégek megpróbálnak tartalomszolgáltatókká válni, és kitörni az egyszerű adatközvetítő pozíciójából.
  • Ahogy a forgalom és a bevétel kezd elkülönülni egymástól, a szolgáltatók felismerték, hogy a mobil szélessáv önmagában nem képes finanszírozni a következő generációs hálózatok kiépítésének költségeit.
  • A szolgáltatók igyekeznek optimalizálni a készülékeiken használt operációs rendszereket, ezzel is növelve a felhasználói élmény egységét, illetve - ami ennél is fontosabb - csökkentve az egységes szolgáltatásplatform implementálásának költségeit.
  • A készülékgyártók, szoftverfejlesztők, tartalomszolgáltatók fokozatosan betelepülnek a piacra, egyszerű adattovábbító szerepre kárhoztatva a szolgáltatókat.
  • Az Apple-féle App Store sikere felhívta a szolgáltatók figyelmét a saját alkalmazásboltokban rejlő lehetőségekre. Néhány cég már tervezi saját bolt létrehozását, vagy már el is készült vele
  • A mobil szolgáltatók egyre inkább olyan másodlagos bevételi források irányába fordulnak, amik nem igényelnek komoly kezdeti befektetéseket. Az alkalmazásboltok gyors bevezetése és a szolgáltató-orientált fejlesztői programok is ennek a törekvésnek a jelei.
  • az API-k - eszköz és hálózati szinten egyaránt - egyre nagyobb érdeklődésre tarthatnak számot, a mobil piacon, mivel új üzleti modellek bevezetését teszik lehetővé, beleértve az alkalmazásboltokat és a kétoldalú üzleti modelleket.
  • Teret nyernek a webes szolgáltatások és a szolgáltatók a webes alkalmazások és widgetek felé fordulnak, így nyújtva sokrétűbb és specifikusabb szolgáltatásokat a felhasználók számára.

Miért fontosak a minialkalmazások a szolgáltatóknak?

A felhasználók lojalitásának megőrzése sokkal fontosabbá vált, mint az árak alacsonyabbá tétele, vagy a felhasználói szolgáltatások fejlesztése. A felhasználók már hozzászoktak a tartalomszolgáltatók által kínált innovatív internetes szolgáltatásokhoz és közösségi oldalakhoz, mint például a Facebook, a Twitter vagy a Youtube, amik lehetővé teszik számukra, hogy saját tartalmat hozzanak létre, és megosszák élményeiket a közösséggel.

A szolgáltatók csak úgy képesek a saját márkájukat (brand) az adatszolgáltatásokhoz kötni a felhasználók szemében, ha a fentiekkel megegyező, vagy még azoknál is jobb élményt képesek nyújtani. A webes szolgáltatások azt jelentik, hogy a szolgáltatóknak nyitottnak kell lenniük, hogy kiaknázhassák a globális fejlesztői közösségek kollektív tudását, ezáltal növelve a saját szolgáltatásaik értékét. A nyitottság révén a vállalatok oly módon fejleszthetnek alkalmazásokat, ami korábban komoly anyagi és belső erőfeszítéseket igényelt volna.

A kiemelt szolgáltatók már felismerték az alkalmazásfejlesztőkkel - főképp a webes programozókkal - való együttműködés jelentőségét a hálózati szolgáltatásaik megújításával, az adatalapú szolgáltatásokhoz kapcsolódó költségek leszorításával és a különböző felhasználói csoportokat célzó ún. long tail ("hosszú farok") típusú alkalmazásokhoz szükséges működési tervekkel kapcsolatban.

Egy webfejlesztő-közösség alkalmazásával a szolgáltatók személyesebbre szabhatják a felhasználói élményt, és a különböző vásárlói csoportoknak azt nyújthatják, amit azok szeretnének: környezetfüggő alkalmazások és szolgáltatások, amik specifikusak, de képesek nyílt API-kkal való kommunikációra az élmény további fokozása érdekében.

Mivel a long tail üzleti modell a tömegpiacot célozza, a szolgáltatók komoly bevételt generálhatnak kiaknázva az Internet és fejlesztőinek gazdagságát. Ráadásul az alkalmazásfejlesztés, a marketing és terítés költségei a fejlesztőket terhelik, miközben a szolgáltató minimalizálhatja a befektetéseit. Ennek eredményeképp az ilyen webalkalmazásokból származó profit magas lehet, noha a bevételek szűkösek.

Néhány szolgáltató felismerte továbbá, hogy a mobil szélessávú szolgáltatásokból származó bevételek nem lesznek képesek ellensúlyozni a hang-alapú szolgáltatások kieső bevételeit. Emiatt másodlagos bevételi forrásokat keresnek, és megpróbálják megérteni a az eddigi zárt megközelítéstől eltérően kínált adatszolgáltatások stratégiai, technikai és kulturális vonatkozásait.

Egyes nagy szolgáltatók tehát most a környezetfüggő mini- és webalkalmazások jelentette internetes szolgáltatásokra építik stratégiájukat. Ezen vállalatok célja, hogy az egyszeri fix díjakon alapuló (flat-rate) szélessávú szolgáltatásoktól a tartalomalapú szolgáltatások létrehozása irányába mozduljanak el, amik lehetővé teszik számukra, hogy különböző felhasználói csoportok számára hozhassanak létre a nekik megfelelő szolgáltatásokat és alkalmazásokat.

Azért, hogy differenciálhassák az alap és prémium szolgáltatásaikat, értéknövelt tartalmakat és innovatív alkalmazásokat kell kínálniuk. Néhány szolgáltató már megkezdte ezeknek a "widget ökoszisztémáknak" a létrehozását, ami ezen szolgáltatások alapját képezi majd. Ilyen vállalat például az Orange (Widgets Experience), a Vodafone (360 Web Store) és a T_mobile (web'n'walk). [Ez utóbbi Opera alapú!]

A widget motorok fejlődése és kihívásai

A mobil minialkalmazások sok, különféle háttérrel rendelkező szoftvergyártót vonzanak, és ez olyan ösztönző környezetet hozhat létre, ahol a vállalatok a teljesítmény, a bemutatott technológiai innovációk és a közösség bevonásának képessége alapján versenyezhetnek egymással.

Ezen felül a a böngészők renderelő motorjában bemutatkozó újításokból, a beépülők által nyújtható környezetfüggő webalkalmazásokból, az eszközök natív funkcióit kiaknázó (szoftveres) felületekből [lásd gyorsulásérzékelő, GPS, Bluetooth, fájlkezelő...], vagy éppen a HTML5-höz hasonló nyílt szabványok fejlesztése érdekében tett erőfeszítésekből a minialkalmazások közvetlenül is nyerhetnek.

Ezek elősegíthetik az új funkciók támogatását, például a hálózat nélküli böngészést, vagy külön beépülő nélküli multimédia-támogatást. A minialkalmazások a HTML5-nek köszönhetően több interaktív funkciót képesek nyújtani, valamint natív támogatást a hang, grafika, animáció és videolejátszás terén.

A kihívásokkal is szembesülni kell

Töredezettség: A nyílt webes szabványok alkalmazása, a mobilszolgáltatók, készülékgyártók és szoftverfejlesztők nyílt eszköz és hálózati API-k használatára tett erőfeszítései ellenére a töredezettség komoly kihívást állít a sikeres elterjedés elé. A különböző gyártók különböző platformjai közötti átjárhatóság hiánya valószínűleg megmarad, ami súlyosan érintheti a felhasználói élményt - a felhasználók nem lesznek képesek megosztani élményeiket a barátaikkal, akik más megoldásokat, alkalmazásokat, szolgáltatásokat és eszközöket használnak.

Ez a hiányosság ronthatja a minialkalmazások és szolgáltatások eladhatóságát, és jelentősen nehezítheti a fejlesztők helyzetét, és elriaszthatja őket ezen megoldások használatától. Jó néhány törekvés létezik (például W3C, OMPT BONDI, JIL, GSMA, OpenAjax Alliance), ami megkísérli homogenizálni az API-kat, szabványosított fejlesztői környezetet adva a fejlesztők kezébe.

Ugyanakkor ezeket a kezdeményezéseket gátolhatja a különböző szolgáltatók közötti versengés. Ez az egységesítések kezdeményezőit arra szorítja majd, hogy az általános standardokon túl egyedi képességeket is beépítsenek, ami bizonyos fokú megkülönböztetést tesz lehetővé a különböző widget platformok között.

Használhatóság: Ahogy a minialkalmazások egyre elterjedtebbé és támogatottabbá válnak , számuk exponenciálisan növekedésnek indul majd. Ugyanakkor a készülékek kijelzőjének mérete limitált marad; számos minialkalmazás mobilkészülékre történő átültetése valószínűleg csak a használhatóság rovására lehetséges. A készülék beépített funkcióit, például a gyorsulásmérőt, vagy az új interakciós lehetőségeket, mint a többujjas gesztusokat, vagy a fejlett három dimenziós kezelőfelületeket például ki lehet használni az alapképernyőn ülő widgetek használatánál, kezelésénél és kiválasztásánál.

A bejegyzés trackback címe:

https://magyaropera.blog.hu/api/trackback/id/tr381860303

Trackbackek, pingbackek:

Trackback: Miért fontosak az Opera minialkalmazások? 2010.04.04. 18:20:07

Tegnap az Opera - a 10.51 megjelenése mellett - fontos bejelentést tett. Bemutatta ugyanis az üzleti felhasználóknak a mobiltelefonokra szánt új minialkalmazás motorját, ami immár a keresztplatformos felhasználói felületet használja.

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

HelloWorld 2010.04.05. 14:27:59

A cikk röviden arról szól, hogy a minialkalmazásoknak igazából a mobilszférában van létjogosultságuk, a desktop szegmensben közel sem annyira fontosak, bár nem is mondhatjuk azt, hogy ne lenne szükség rájuk.

Mesmoryser 2010.04.05. 18:52:39

@HelloWorld: Az interjú kifejezetten és kizárólag a minialkalmazások mobil vonatkozásával foglalkozik, így téves lenne belőle a desktop létjogosultságra következtetni.

(Magánvélemény: desktopra van kb 5-10 használható minialkalmazás, a többi említésre sem méltó. Öröm az ürömben, hogy készülnek már nagyon ígéretes minialkalmazások, például a Unite Media Player widgets.opera.com/widget/15592/ )

cousin333 · http://magyaropera.blog.hu 2010.04.05. 18:59:28

@HelloWorld: A minialkalmazások lényege az volna, hogy minden eszközön működik, vagy kis erőbefektetéssel (pl. külön CSS) optimalizálható rá.

@Mesmoryser: Sajnos ez így van. Az említett alkalmazást az Opera dolgozói készítették. Valahogy az eddigieknél is komolyabban kellene bevonni a közösséget a fejlesztésbe (például az eddigieknél is több, jobb saját - azaz Opera gyártmányú - minialkalmazással, illetve szerintem már régóta kellene egy stabil mobil böngésző widget futtatással. Ez még mindig nincs. Kicsit olyan érzésem van, hogy profi emberkékkel akarják megíratni a speciális alkalmazásaikat a telefonra, nem pedig Pistikék műveit megjelentetni.

penge™ · http://www.thevenusproject.com/ 2010.04.05. 21:39:51

@cousin333: Kivel "írassák" meg, mikor
1: Akinek ötletei lennének (mint például én) lövése sincs a programozásról.

2: Akinek lövése van a programozásról azok 80%-a Pistike 10%-a úgy van vele, hogy neki nincs rá szüksége, így nem igazán érdekli és maximum néhányan vannak, akik megpróbálkoznak valami hasznossal, ahelyett, hogy összedobnák a legegyszerűbbet, mint egy kereső, évek óta létező Operás funkciók pótlása, vagy egy adott oldal feed doboza és társai.

3: Aki profi programozó az max magának megírja saját használatra, de ingyen nem fog dolgozni.

Azok a profi programozók, akik szeretik is csinálni (úgy értem, szabadidejükben, ingyen is és szívesen meg is osztják), illetve olyanok, akik referenciamunkaként csinálják ingyen, hogy később pénzért csinálhassák azokból szoktak kijönni a valódi kincsek.

És ez igaz a Widgetekre, UserJS-ekre, a FF, Chrome kiegészítőkre és minden ilyesmire.

Mesmoryser 2010.04.05. 22:45:12

@penge™: És milyen nagyszerű ötleteid vannak? Hátha valaki (mondjuk én) kedvet kap a megvalósításukhoz :)

penge™ · http://www.thevenusproject.com/ 2010.04.06. 09:10:09

@Mesmoryser: Egy Update Checker alkalmazás, ami működik és fejlesztik, nem úgy, mint ez: widgets.opera.com/widget/5033/

És legalább olyan tudású, mint a Firefoxos megfelelője.

A második, ami szintén nem tudom megoldható-e, egy spacer az "always on top" funkcióhoz, így lehetne csinálni egy sok widgetből álló oldalsávot a saját Opera oldalsávtól függetlenül.

Egy újabb, ami biztosan megvalósítható, főleg mivel már a widgetek is használhatják a tálca értesítési területét: Egy naptárral egybeépített értesítő alkalmazás, ami kezeli az ismertebb kiterjesztéseket, Google Calendar kompatibilis, utóbbival képes fel-le szinkronizálni és hangjelzést is adni.

Rengeteg naptár meg értesítő van, de igazán komoly egy sincs.

Egy nem túl régi ötlet, ami a külön alkalmazásként futó widgetek kapcsán született, de nem tudom mennyire megoldható: Miután Operában sikeresen tönkretették az ua.ini-s megoldást és már csak a böngésző újraindítása után lehet átírni, nem tudom widgetekben megoldható-e külön, mivel azok is ugyanazt a presto motort használják.

Mert ha igen, akkor megoldható lenne és ezt ötvözve a Lucideer által készített widgetize alkalmazással pozitív reklámot lehetne csinálni az Operának, hogy működik vele myvip rejtett mód vagy a korábban nem tudom ki által linkelt GameStar-os nyereményjáték és a többi. Az MS saját fegyvere fordulna ellene, avagy fejlett beépített funkciókkal a user agent korlátozás ellen.

Hirtelen ennyi, inkább userJS-ekre és userCSS-kre lennének ötleteim.

cousin333 · http://magyaropera.blog.hu 2010.04.06. 17:03:19

Ötleteim nekem is volnának. Az "egyszerűbb": komplex hozzászólás (blogbejegyzés) szerkesztő, egyszerűen hozzáadható BBCode-okkal, kód szerkesztése, előnézet valós időben, beszúrható külön elemek, mint pl. Youtube video, Google Maps térképrészlet, MathML egyenlet... stb.

A bonyolultabb nem tudom, mennyire megvalósítható: lehetséges-e létrehozni egy böngésző-minialkalmazást. Kezdetnek alapfunkciókkal: honlap, címsor, füles böngészéssel, előre, vissza, újratölt gombokkal. Később ezt lehetne bővíteni, a különböző eszköztárakat pedig iGoogle (vagy Opera Portal)-szerűen lehetne átrendezni, gyakorlatilag tetszőlegesen. Extra eszköztárrakkal külsős funkciók is mehetnének (gyk. "kiegészítők"). Vélemény?

Fefy · http://blog.fefy.info/ 2010.04.06. 17:56:06

@cousin333: Elméletben és a gyakorlatban is megoldható a bonyolultabb (ami egyébként egyszerűbben megvalósítható (már ami az alap böngésző funkciókat illeti), mint a komplex hsz szerkesztő) ötleted. Egy jquery-hez hasonló framework kellene hozzá (lehet egy pre alpha verziót össze is dobok jquery-vel), iframe-el és div-ekkel megoldva...

Egyébként csak tesztként nézem majd meg, hogy mennyire megvalósítható az ötleted, ugyanis mostanában eléggé el vagyok havazva, de egy kis ujjgyakorlat soha nem árt :D

Nameless® · http://dirtywindows.hu/ 2010.04.06. 18:20:46

Én makacs user ként még mindig azt mondom, ennek a sz@rnak és a torrentnek semmi helye az operában,

Mind a kettőre van sokkal jobb alternatíva.

Nameless® · http://dirtywindows.hu/ 2010.04.06. 18:24:09

@Namelesske: A mobilba meg egyenesen kötelező! Symbian mobilon Dashboard ként is lehet használni, főleg E szériás nokián ahol beállítom rá Pl az Email gombot hosszú megnyomásra, nagyon vagány tud lenni. De örülnék tényleg ha eltünne a desktop operából, vagy PL unite alkalmazásként lehetne felrakni, mint Widget Engine. Rakja fel akinek kell :D

penge™ · http://www.thevenusproject.com/ 2010.04.06. 18:54:02

@Namelesske: Mivel nem lassít és ha nem használnod nem is tol semmit az arcodba, így miért csípi a szemed? :) Évekig én sem használtam, az akváriummal szórakoztam egy ideig, az touchTheSky jó lett volna, ha sidebar-szerűen meg lehetett volna oldalon, viszont mióta külön appként működik végre van használható MSN kliensem (a képírós ismerőseim nagy örömére). :D

@Fefy: Az Update Checker megoldható?

cousin333 · http://magyaropera.blog.hu 2010.04.06. 19:05:38

@Fefy: Akkor jó, mert van még hozzá ötletem. :)

A legjobb az elvileg nagyon rugalmas UI. Például minden eszköztárat (vagy akár gombonként!) külön lehetne nagyítani. Ikonok lehetnének SVG-ben is akár, így a pixelesedés sem lenne probléma. Ízléses effektekből is mehetne bőven (ki-és becsúszó oldalsáv).

Meg a kiegészítők is megoldhatóak, tulajdonképpen tetszőleges webes funkciókkal. Vagy a már említett hozzászólás-szerkesztőt is szépen bele lehetne integrálni.

Nameless® · http://dirtywindows.hu/ 2010.04.06. 20:44:43

@penge™: valahogy felesleges sorok a programkódba :D

Mesmoryser 2010.04.06. 21:44:28

@penge™:
Update Checker: van benne fantázia, de jó lenne, ha legalább linkelnéd az említett Firefoxos megfelelőjét, mert amit én találtam, az ugyancsak ősrégi.

Spacer alkalmazás: nem értem mire jó, hogyan működik.

Értesítő: pontosan mikről értesítene? Sosem használok naptárakat, így nem tudom, mi kéne bele.

User agent hamisító(?): nem látom sok gyakorlati hasznát. Lehet vele villogni, néha az ember elindítja és örül neki, hogy ilyen is van. Mint a többi párezer minialkalmazás.

@cousin333:
A bejegyzésszerkesztőre miért minialkalmazás formájában van szükség? Nem inkább userjs?

A böngésző minialkalmazás célját egyáltalán nem értem. Miért kell böngészésre egy minialkalmazás, amikor ott a böngésző? Meg lehet csinálni, egy darabig jó ujjgyakorlat, de ki fogja ezt használni és mire?

Az is lehet, hogy csak az én internethasználati szokásaim nem teszik szükségessé a fent felsorolt minialkalmazások szükségességét, de nem látom bennük azt, hogy emberek ezreinek könnyítenék meg a mindennapjait. Lehet hogy ez elsősorban a minialkalmazások hibája. Az általatok megálmodottak mind az Operát egészítenék ki hasznos kis apróságokkal, viszont a minialkalmazások pont erre nem alkalmasak. Egyáltalán nem épülnek be a böngészőbe (jó tudnak értesítési ablakot küldeni, éljen), külön startmenüből indíthatók, egyetlen előnyük, hogy egy hatékony renderelőmotor dolgozik alattuk. Ezt kihasználva kéne programokat kitalálni és nem az Opera hiányosságait beleerőszakolni külön programokba, mert azok ettől nem lesznek a böngésző részei.

Egyébként kicsi esélyét látom annak, hogy időt tudjak szakítani a minialkalmazás-programozás megtanulására, és a program elkészítésére, de ha lenne egy igazán jó ötlet, biztosan belevágnék. Gondoltam arra is, hogy szakdolgozatnak is tökéletes lenne egy minialkalmazás, de arra még van egy évem.

penge™ · http://www.thevenusproject.com/ 2010.04.06. 22:02:10

@cousin333: Az SVG ikonok nem zabálnának túl sok erőforrást?

@Mesmoryser: addons.mozilla.org/en-US/firefox/addon/3362 Az egyik lényege az lenne, hogy login-os oldalaknál is működjön és nem ártana az sem, ha figyelembe venné a reklámblokkolót (nem úgy, mint a Firefoxos, ami emiatt sok oldalon használhatatlan).

A Naptár olyan, hogy beírom: találkozó xy-nal 2010.04.06.-án értesítsen 2010.04.05.-én 13:00 perckor.

Aztán ez egyszer értesít a beállított dátumkor beúszó értesítéssel és hangjelzéssel, másodszor szinkronizálja magát Google Calendarral (vagy ami még jelenleg népszerű naptárszolgáltatás) és tud importálni/exportálni ical formátumból/formátumba. Bár ez utóbbi nem fontos, mert ha szinkronizál Google Calendarral, akkor azon keresztül is megoldható.

Dzsini 2010.04.06. 22:07:55

@penge™: calendarnál akkor ezekszerint RainLendar funkciókat vársz el (a lite mindezt tudja, a Pro még az Outlookkal is együttműködik, stb.)

Fefy · http://blog.fefy.info/ 2010.04.06. 22:55:47

@penge™: Azért a login-os oldalak figyelembevétele nem olyan egyszerű ám, mint azt sokan képzelik... Arról nem is beszélve, hogy nem szívesen adom meg az adataimat egy 3. személy által készített alkalmazásnak, ugyanis ez akár egy központi címre is küldheti az adatokat --> visszaélésre adhat okot...

Egyébként az svg pár kisebb méretű ikon esetében nem jelent akkora gondot... Maga a javascript alapú böngésző minialkalmazás kernel (na ezt szépen leírtam :D) látványosabb terhelést okozna.

@Mesmoryser: sztem az update checker-t simán http fejléc alapján meg lehetne csinálni... Ha jól emlékszem, akkor a http header-ben van egy módosítási dátum is, esetleg a nyers szövegre is lehetne egy md5 checksum-ot rakni, vagy a http header-ből kiszedni a content length-et (esetleg ezek együttesét vizsgálni egy megfelelő algoritmussal, amiben beállítható, hogy nagyjából x százalékos eltérés esetében jelezzen, hogy módosult az oldal). Az mondjuk hirtelen passz, hogy a header olvasható-e egy xmlhttprequest-el, de az elképzelésem kivitelezhető lenne...

cousin333 · http://magyaropera.blog.hu 2010.04.06. 23:15:25

@Mesmoryser: "Meg lehet csinálni, egy darabig jó ujjgyakorlat, de ki fogja ezt használni és mire?"

Részint pontosan azért, amit ezután írtál . Az Operát nem lehet kiegészíteni minialkalmazásokkal, de egy minialkalmazás alapú böngészőt igen. Ez lehetne az egyik értelme is a projektnek. Egy nagyon alap, de jól átgondolt böngésző, és egy egyszerű, de hatékony - webalapú - kiegészítő rendszer. Mint az FF kezdetekben. Egyszerű lenne, Presto és Carakan miatt kellően gyors is, szabadon alakítható, és olyan funkciókat is tudhatna, amit a mostani Opera nem (pl. teljesen szabadon állítható eszköztárak - lásd személyes sáv a címsáv alatt).

Azzal én is egyet értek, amit az új widget-motor is kihangsúlyoz: a minialkalmazások nem az Opera apró funkcionális hiányosságainak a pótlására lettek kitalálva.

@penge™: kis méretű, egyszerű, statikus SVG ikonok, főleg egy HW-es Vega háttérrel aligha okozhatnának gondot szerintem.

penge™ · http://www.thevenusproject.com/ 2010.04.07. 14:05:52

@Fefy: Írni nem tudom, de olvasni valamennyire igen. Annyira azért értek hozzá, hogy átnevezve a wgt-t .zip-re átnézzem, hogy adatokat lop-e, vagy sem. A userjs-ek forrását is mindig meg szoktam nézni. Viszont úgy lenne jó, ha loginos oldalaknál is működne.

zsüi_ 2010.04.07. 15:23:14

Eddig használtam egy gomb készítő minialkalmazást. 10.50 óta nem megy. Csinált a készítő egy unite alkalmazást helyette. Szerintem megér egy kattintást. Csekkoljátok: unite.opera.com/application/651/

Fefy · http://blog.fefy.info/ 2010.04.07. 22:54:51

@penge™: kicsit utánna jártam a dolognak és elvileg megoldható a loginos dolog is, szóval a korábbi állításom visszavonva, hogy nem olyan egyszerű (egyedül a nem süti alapú oldalaknál van egy gond, de majd ezekre is kitalálok vmit) :P

@cousin333: felraktam egy pre pre pre alpha verziót :D Lényegében egy címsorból, egy a címsorba begépelt url frissítése gombból (a kattintott linkek még nem kerülnek be az url mezőbe sajnos), valamint egy browser ablakból áll. (kb úgy néz ki mint egy alpha verziós wingogi :D)
A widget linkje pedig a következő: fefy.co.cc/doksik/widget.wgt (Egyébként ezt a hsz-t is a "home made" böngészőmből írtam)

Mesmoryser 2010.04.08. 15:45:38

@Fefy: Próbálj meg HTML5-ös url típusú inputot használni az url mezőben. Akkor benne lesznek az Opera böngészési előzményei, csak az a nagy kérdés, hogyan lehet rávenni, hogy a beírtat el is mentse.

Szerintem ezzel a virtuális böngészővel az a baj, hogy a JavaScript korlátai miatt sosem lehet benne Operát megközelítő tudású böngészőt írni. Lehet csinálni nagyszerűen testre szabható eszköztárakat, lehet írni hozzá nagyszerű kiegészítőket, de alapvető funkciók fognak hiányozni. Bár lehet, hogy a minialkalmazás API (már ha van) pótolja ezeket a hiányosságokat, azt még nem ismerem.

Fefy · http://blog.fefy.info/ 2010.04.08. 18:28:50

@Mesmoryser: Elvileg menthető minden előzmény, mivel a widget api biztosít akár fájlszintű hozzáférést is, de sajnos rengeteg hátránya van a minialkalmazásoknak...

Egyik nagy hátránya az említett url mező... mivel csak iframe-ben lehet teljes értékű weboldalt megjeleníteni, így kapásból egy xss probléma lép fel... Ugyanis idegen domain-es oldal tartalmát nem lehet sehogy lekérdezni (security exception hibával elszáll az egész, mint a győzelmi zászló). Ebből kiindulva a füles böngészés egy kicsit a lehetetlen kategóriába tartozik :D (Azt mondjuk nem értem, hogy az iframe-be betöltött oldal url-jét és címét miért nem lehet lekérdezni, de ez mellékes). Továbbá a linkek új fülön való megnyitása is esélytelen, mivel nincs context menü lehetőség.
Az egészet inkább egy nagy tudású rss böngészővé lehetne alakítani, aminek még talán lenne is értelme, de a szegényes api miatt másra nem nagyon lehet használni...

Egyébként 1 dolgot még elárulok... A minialkalmazások függetlenek az operától olyan szinten, hogy külön sütiket, külön jelszókelező van, valamint külön előzmények adatbázist használnak, szóval az url mező csak fél megoldás lenne...

@cousin333: A fentiek alapján szerinted folytassam a dolgot, vagy inkább dobjuk el az egész ötletet?

cousin333 · http://magyaropera.blog.hu 2010.04.08. 22:44:32

@Fefy: Gondoltam, hogy lennének vele problémák szép számmal. például a Vissza gomb mennyire megoldható?

Szerintem kár feladni a dolgot, mert sok okosat lehetne kihozni belőle. Pl. egy alap dolog, de lehet natív ablaka is, nem csak ez a "widgetes".

Viszont talán jobb lenne nem a böngésző funkciót duplikálni, amíg annyi sok más is van. Pl. Opera Update Manager. Persze nem az Operát frissítené, hanem minden mást. Például egy netes szerverről automatikusan leszedhetné az urlfilter fájl, vagy azt, ami egyes oldalakon a useragentet módosítja, vagy akár az aktuálisan használt témát frissíti... stb.

Ehhez szerintem minden adott. A minialkalmazás külön processz, lekérné a beállított frissítéseket, jelezné, ha van valami új, mutatna changelog-ot, megkérne, hogy zárd be az Operát, és frissítene szépen...

Vélemény?

penge™ · http://www.thevenusproject.com/ 2010.04.08. 23:03:06

@cousin333: Nekem tetszik az ötlet. a userJS-eket és a Unite App-okat is figyelhetné (plusz a többi widgetet), mert valahogy ezt is elég diszkréten kezeli az Opera, úgy kell a cache-ből kibányászni melyik verzió van meg.

A userJS-nél megoldható az autoupdate, ha van egy állandó cím, csak ebben az esetben a userJS-ben kell definiálni, ami így nehézkesebb, mintha csak simán a // @version 1.0 részt figyelné.

Bezárni nem kell az Operát újra is indíthatná, 10.5-től már van "Restart Opera" paraméter, ami használható a billentyűparancsoknál, mozdulatparancsoknál és sajátgomboknál is, akár kombinálva is.

Fefy · http://blog.fefy.info/ 2010.04.08. 23:30:51

@cousin333: Hát igen... Problémák vannak egész szép mennyiségben (lényegében csak hibák vannak :D), szóval a böngészős plugin-ezős dolog eldobva (max rss alapján egy betekintőt érdemes csinálni :)), viszont az update manager már nem olyan problémás.

Egyébként a vissza gomb még talán megoldható egy history.back()-el, viszont a frissítés esélytelen. Tegnap óta keresek megoldást a dologra (mármint a frissítésre, akár úgy is, hogy egy bug-ot is kihasználva), de eddig csak zsákutcába jutottam.

Szóval majd a hétvégén kitalálom még, hogy mi legyen... :) (Annyi biztos, hogy érdemes belevágni)