Mire figyeljünk a webfejlesztésben 2006-ban?
Anil Dash vette nemrég a billentyűzetét, hogy megjósolja, milyen trendek várhatóak a webfejlesztésben a következő évben, mire kell felkészülnünk, ha versenyképesek akarunk maradni a profik között is. Az ilyen jóslatok megfogalmazásakor ugyanakkor érdemes óvatosnak lenni, hiszen bizonyos divatos megoldások éppenhogy eltűnhetnek idővel, más hasznos technológiáknak viszont nem jelenhet meg kellő támogatása a kliens vagy szerver oldalon. Jóslatai mindenesetre igen érdekesek.
Blog bejegyzésében Anil elsősorban a felhasználói felületen tapasztalható trendekre tért ki, hiszen ez az, amit a végfelhasználó is érzékel, és ez alapján választ terméket, ugyanakkor egyáltalán nem feledkezett meg a szerver oldali megoldásokról sem. Lássuk mit tart fontosnak.
Kíváncsi vagyok olvasóink mit gondolnak, a fentiek közül mi csupán az aktuális divathullám sugallata, és mivel egészíthetnénk ki a listát.
■ Blog bejegyzésében Anil elsősorban a felhasználói felületen tapasztalható trendekre tért ki, hiszen ez az, amit a végfelhasználó is érzékel, és ez alapján választ terméket, ugyanakkor egyáltalán nem feledkezett meg a szerver oldali megoldásokról sem. Lássuk mit tart fontosnak.
- Diszkréten dinamikus effektek: A felhasználói felületek AJAX-osodásával, a hirtelen változások helyett fokozatosan el- és feltűnő elemekre kell felkészülnünk, hiszen ezek jobban érthető felületi változásokat jelentenek a felhasználó számára.
- Az E4X megállíthatatlan terjedése: Az XML-t jelentősen könnyebben kezelhetővé tevő E4X a JavaScript megoldásainkat sokkal egyszerűbbé teheti, amennyiben XML feldolgozást kell végeznünk. Mind a Firefox következő kiadásában, mind a Flash lejátszóban érkezik E4X támogatás, a Microsoft részéről csak idő kérdése az alkalmazkodás, ha nem szeretnének lemaradni.
- A JSON térhódítása: Sok esetben túlzás az XML adattovábbítás használata, ilyenkor jöhet jól a JSON, melyhez számos nyelvre elérhető támogatás, ráadásul a JavaScript natív objektum jelölését használja az adatok továbbítására, így webes környezetben különösen könnyen alkalmazható.
- XHTML és CSS korrekt használata: Még mindig sokan vannak, akik akár XHTML akár HTML formátumban nem készítenek érvényes weblapokat. Egy igazán programozható, Greasemonkey barát weboldal létrehozásakor azonban mindenképpen fontos, hogy jól struktúrált szerkezetet hozzunk létre. Ezen a területen még mindig van tér a fejlődésre.
- A betöltést jelző üzenetek visszatérnek: A Betöltés... illetve Loading... feliratok, melyeket nagy Flash mozik betöltésekor már megszoktunk a kiterjedt JavaScript kódok betöltési időszükséglete miatt ismét visszatérhetnek. Bár ez nem válik a fejlesztő dícséretére.
- Atom API támogatás: Az Atom tartalommegosztó formátum szabványosításával megnyílt a lehetőség az Atom programozói felület véglegesítésére, melynek előzetes verzióit már támogatja számos webalkalmazás. Ennek ismeretével helyzeti előnybe kerülhetünk a jövő évben.
- Ruby on rails előnyszerzés: Sok területen élveznek előnyt azok, akik időben felismerték egy technológia hasznosságát, és profira fejlesztették magukat a témakörben. A Ruby on Rails sokak szerint hasonló helyet foglalhat el, de számos terület van, ahol még nem teljesít jól, vagy nem is próbálták ki az alkalmazását.
- Okosabb önmarketing: És végül mit sem ér, ha mindezeket a technológiákat ismerjük és profin használjuk, ha nem tudjuk ezt kommunikálni a potenciális megrendelők, munkaadók felé. Tanuljunk meg okosan és hatásosan beszélni és írni arról, hogy mire vagyunk képesek!
Kíváncsi vagyok olvasóink mit gondolnak, a fentiek közül mi csupán az aktuális divathullám sugallata, és mivel egészíthetnénk ki a listát.
Okosabb önmarketing
--
Ámon Tamás - http://amon.hu
csak érintőlegesen
<Nincs cím>
(Megelőzve a flamet: a leírt dolgok erősen SZVSZ jellegűek...)
Üdvözlettel: Liebig Zsolt
SWEN Internet
PHP alapon is lesz
Háát.
Ez a helyzet bár nyilvánvalóan nem olyan, de emlékeztet arra a vitára, amikor az emberek a régi táblázatos layout mellett kardoskodtak két-három évig (lásd különböző levlista archívumaink). Az ellenérv akkor az volt, hogy bonyolult, a régi bevált, és különben sem éri meg váltani, mert ez egy divat. Azóta bebizonyosodott, hogy nem így van.
-boogie-
Rubyra még várni kell
Az Atom is szerintem várni fog még egy kicsit, szerintem az RSS is olyan helyzetben van, hogy el kell terjednie. Remélem nem mondtam marhaságot:-).
___________
by ChaTeve
Betöltés...?
csak ha tényleg preloader...
___________
by ChaTeve
Preloader
Ezután a HTML kód elején JavaScripttel megjeleníted (display -> block) majd onload eseményre ismét eltünteted.
Szerintem nem célszerű ilyet, max. speciális esetben.
Amúgy a backbase.com oldalon (Firefox-szal nézve) van ilyen Loading felirat.
Attila
korai alkalmazók
<Nincs cím>
Üdvözlettel: Liebig Zsolt
SWEN Internet
Nem tartom jó ötletnek a preloadert
Egy normálisan megtervezett tableless designet használó oldalon a lényeges tartalmi rész előbb jelenik meg, mint a többi sallang. Így már az oldal akkor használhatóvá válik, amikor a többi sallang (pl reklámok, képek) még csak töltődnek. Akkor miért várakoztassunk meg mindenkit?
És mi van azokkal, akik például nem kívánják az egész oldalt letölteni? Például nem akarják a képeket megnézni? Ebben az esetben akadjon ki a preloader? Láttam már rá példát.
Inkább a gzip-l tömörített adattovábbítás nagyobb térhódítását várnám el. Nagyobb terhelés a szervernek, viszont csökkenit az igényelt sávot és gyorsabb a letöltés. Az átlagfelhasználót meg nem érdekli a szerver, csak az, hogy gyors legyen.
Szerver terhelés - sebesség
Én ezt pont ellenkezőleg gondolom: egyre nőnek a sávszélek, ma már nem ritka, hogy valaki 150-200Kbps-os sebességgel rohangál, mindemellett a technológiák is egyre gyorsabb betöltődést tesznek lehetővé (ajax, css, dinamikus oldalak cache-elése, stb), tehát akkor miért kéne megint visszanyúlni a gyökerekhez, és kvázi a "néhány" modemesre optimalizálni, holott a fejlődés pont az ellenkező irányba mutat? Szerintem a legjobb sebességet pont nem a szerver dolgoztatásával kell elérni, ellenkezőleg: a lehető legjobban tehermentesíteni kell (lásd: az előbb már említett példák).
Egyébként a szerver terhelések kérdése pedig hazánkban pont olyan szinten van, hogy kevés webhely tulajdonos mondhatja azt: rendben, terheljék csak a vasat, majd veszünk nagyobbat, de legalább marha gyors oldalunk lesz. De elég csak megnézni a hazai hosting piacot, hogy egyesek milyen gépekkel képesek webtárhelyet szolgáltatni, na hát ott inkább ne terheljen senki semmit.
A preloadra pedig a fentebb már belinkelt backbase.com szerintem nagyon jó példa.
Üdvözlettel: Liebig Zsolt
SWEN Internet
<Nincs cím>
A backbase.com -mal csak egy nagy gond van: és ha nincs javascript, akkor hogy navigálunk rajta?
Próba?
Attila
Tényleg
Csak arra leszek kíváncsi, hányan veszik majd a fáradtságot/lesz ideje, hogy a hagyományos egyszerűbb helyet összetettebbet készítsenek.
Web API-k
Szóval:
Weboldalhoz Atom és RSS feed.
Webalkalmazáshoz meg API felület kell hogy tartozzon.
Ha van ilyen felület, akkor egyszerű beépíteni pl. asztali alkalmazásokba, pl. Google Sidebarhoz plugint írni, Firefoxhoz kiterjesztést írni vagy Greasemonkey scriptet, Dashboard, Konfabulator, Superkaramba widgetet készíteni, stb.
Attila
JavaScript nem lesz annyira nyerő
Személy szerint 2006-ra az AJAX és az (x)html+css szemantikailag is helyes használatát jósolom, ha már az egyik teljesül, már nagyott léptünk előre.
--
Aries
http://aries.mindworks.hu
Ruby effekt :)
Nekem kifejezetten bejön a preload; nem feltétlenül kell ezt kizárólag egyes oldalak/aloldalak betöltődésére érteni; szuper dolog pl. az is ha látom, hogy egy adott csatolmány feltöltése hol tart, vagy meddig kell várnom egy keresési folyamat végéig.
Atom - hát: na végre :) Bővebben csak annyit, hogy az Atom+RSS2+XML csatorna fenntartása egy oldalon nem okoz jelentős terhelést, de legalább a felhasználó választhat a kínálatból.
XHTML+CSS: sokáig úgy gondoltam, hogy az olyan intézmények, mint a Magyar Elektronikus Könyvtár, nem engedhetik meg maguknak, hogy oldaluk "szétszórt kódtöredékekből hirtelen" felhasználóbarát webhellyé álljanak össze - és: de, ez van. El is határoztam, hogy kb. megcsinálom azt, amit Douglas Bowman csinált a M$ címoldalával, megkísérlem centiről-centire modernizálni úgy, hogy a kinézet (ami, hát nem a legszebb) ne változzon.