Az alternatív lehetőségek száma nőtt ugyan az online térben, azonban a weboldalak továbbra is megkerülhetetlenek, mivel egy saját magunk által kezelhető, birtokolható, önálló digitális élményt kínálnak. Szemben a korábban felsorolt technológiák egy jelentős részével, a weboldalaknál közel teljes irányításunk alatt lehet a forráskód, ami sokkal komolyabb lehetőséget kínál a fejlesztők és designerek számára a közönség meggyőzésére, mint amit például a közösségi média platformok tudnak nyújtani.

És itt nem csak arról van szó, hogy a jó minőségű weboldalak segítségével hatékonyan növelhetik forgalmukat a cégek, hanem arról is, hogy ennek a forgalomnak a minőségét is javíthatják. Egy jó felhasználói élmény kínáló weboldal nagyon hatékony lehet abban, hogy a weboldalon tartsa a látogatókat, ahol aztán újabb tartalmakat fedezhetnek fel.

Weboldalak és közösségi média

A legtöbb cég számára ma már a közösségi média az egyik legfontosabb lehetőség az emberekkel való kapcsolat kialakítására és fenntartására. És bár sokan töltik az idejüket a közösségi médiában, az nem alkalmas egy átgondolt döntéshez szükséges információk megszerzéséhez vagy feladatok megoldásához.

A weboldalak a közösségi médiával szemben olyan előnyökkel rendelkeznek, mint a

• rugalmasság – a leginkább személyre szabható felületek, melyek pontosan képesek tükrözni egy cég értékeit.
• tulajdonjog – vagyis a weboldaladon a saját tartalmaidat teheted közzé, azt birtokolhatod, míg a közösségi médiában közzétett tartalommal az adott platform rendelkezik, azt saját elképzelései szerint terjesztheti vagy akár el is távolíthatja.
• felfedezhetőség – a weboldalak felfedezhetők a különböző keresőmotorok segítségével, melyek versenyeznek azért, hogy a legjobb találati listát kínálják egy-egy keresésre. Ugyanez a közösségi média platformokról nem mondható el.
• skálázhatóság – a weboldalak kihasználhatják a legújabb technológiákat annak érdekében, hogy javítsák a felhasználói élményt, míg a közösségi média platformok felhasználói élménye a vezetőség döntésén múlik.

Weboldalak és alkalmazások

Amikor a weboldalak kapcsán azt mondjuk, hogy a segítségükkel az internet egy részét birtokolhatjuk, akkor ugyanez felmerülhet az appok esetében is. Ugyanakkor azt is figyelembe kell venni, hogy az appok külső szolgáltatók által vannak szabályozva. Tehát, míg egy weboldal bármilyen webböngészővel bíró eszközről elérhető, addig egy app egy bizonyos operációs rendszerhez vagy platformhoz kapcsolódik. Az alkalmazásod terjesztéséhez be kell tartanod az áruház tulajdonosának követelményeit, amelyek ráadásul bármikor megváltoztathatók anélkül, hogy megkérdeznék a véleményedet róla.

Az appokkal szemben is érvényes az, hogy nagyobb rugalmasságot és skálázhatóságot kínálnak a weboldalak, mint az alkalmazások. Emellett költséghatékonyabbak: egy egyszerű weboldal akár egy hétvége alatt összerakható és elindítható, de a fenntartása is kevesebbe kerül, mint egy alkalmazásé. Ráadásul a felhasználók számára is könnyebben elérhető egy weboldal, hiszen csak kattintani kell egy linkre, vagy beírni a címét, míg egy alkalmazást le kell tölteni vagy meg kell vásárolni.

Weboldalak és podcastek vagy vlogok

Az kétségtelen, hogy a videók és részben a podcastek az elmúlt években jelentős teret hódítottak. Valóban hatékonyan képesek megragadni az emberek figyelmét, ugyanakkor passzív élményt kínálnak a nézőknek. Még akkor is, ha valamiképpen nyitottak a felhasználói interakcióra, alapvetően a passzív befogadásról szólnak ezek a típusú tartalmak.

Hozzájuk képest egy weboldal költséghatékonynak tekinthető, hiszen egy jó podcast-sorozathoz vagy a vlog-készítéshez komoly technikai háttérre lehet szükség, a gyártási munkák költségéről nem is beszélve. Azt is figyelembe kell emellett venni, hogy amíg egy jól megírt, örökzöld tartalom a weboldalakon évekig releváns maradhat, addig egy videó vagy egy podcast-rész gyorsan el tud tűnni a süllyesztőben.

A weboldalakon persze megjelenhetnek, beágyazthatók podcastek és videók is, ahogy bármilyen tartalom, miközben a podcastek vagy videók esetében csak egy podcastről vagy videóról van szó, semmi többről. Végül pedig arról sem szabad megfeledkezni, hogy egy weboldal sokkal kisebb méretű lehet, mint a podcastek vagy még inkább a videók, ami azt jelenti, hogy könnyebben és olcsóbban elérhetők a felhasználók számára, különösen, ha mobilnetet használnak.

Összességében tehát azt mondhatjuk, hogy 2023-ban továbbra sem mondhat le egyetlen cég sem a saját weboldalról, azok változatlanul az üzleti stratégia részét kell, hogy képezzék. Mint látható, számos előnyük van más technológiákkal szemben, elsősorban a rugalmasság, a költséghatékonyság, és a keresőoptimalizálhatóság.

Sokkal jobban a cég igényeire szabhatók, mint egy közösségi média oldal, és habár egy mobilalkalmazás lehet funkciókban gazdagabb egy weboldalnál, sok korlátozással kell szembenézni a különböző platformok és eszközök miatt.

A weboldalak tehát velünk maradnak és tovább fejlődnek az elkövetkező években is, annak ellenére, hogy mindig felbukkannak újabb és újabb ötletek a digitális tartalom terjesztésére.

The post Fontos még a webdesign 2023-ban? appeared first on Webshark Blog.

Először is nézzük meg, hogy pontosan mi is az a bot, hogy védekezni tudj ellene és megakadályozd, hogy feltérképezze az oldalad. A bot a „robot” szó rövidítése, egy olyan szoftver, melyet egy meghatározott, ismétlődő feladat elvégzésére programoztak.

A robotoknak két típusa van a neten: jóindulatú és rosszindulatú botok. Nem minden robot rossz, vagyis nem kell ádáz küzdelmet folytatva, távol tartani mindegyiket a weboldaladtól. A Google is botokat használ a weboldalak feltérképezésére, így ha blokkolod, akkor nem fog megjelenni a weboldalad a keresőben. Emellett nagyon sok más robot járja a webet, melyek megkönnyítik emberek munkáját azzal, hogy az ismétlődő feladatokat fáradhatatlanul elvégzik helyettük. Ezek a botok hasznos adatokat szednek össze, melyek alapján automatizálhatók és elvégezhetők feladatok.

A jó botok a háttérben futnak, nem támadnak meg felhasználókat vagy a weboldalt. A rossz botok ezzel szemben fenyegethetik a weboldal biztonságát, a nagyobb botnetek pedig DDOS támadást is indíthatnak. A rossz robotok segítenek személyes adatok ellopásában, káros linkeket helyeznek el a weboldaladon, spammelik az űrlapjaidat, esetleg leállítják az oldalt.

De ha nem is támadnak meg, milyen problémákat okozhatnak ezek a botok?

• Bizonytalanná teszik az adatokat
• Nem tudod, honnan érkezik a forgalom
• A jelentések megalapozatlanná válnak
• Terhelik a szervert, foglalják a sávszélességet

A gond csak az, hogy nem olyan könnyű minden robotot felfedezni, amely feltérképezheti a weboldaladat. Ehhez mélyre kell ásni, és ki kell szűrni a rosszindulatú példányokat. (Ha csak az analitikát akarod megtisztítani a botoktól, akkor a Google Analyticsről szóló anyagunkban erről ejtettünk néhány szót.)

A robotok alapvetően kétféle úton blokkolhatók. Az egyik a robots.txt, mely egy olyan fájl, ami a szervered gyökérkönyvtárában található (már ha be van állítva), és amelynek segítségével letiltható sokféle bot az oldalról. Tehát, ha például azt akarod, hogy a Google távol maradjon a weboldaladtól, akkor a robots.txt-ben ezt a két sort helyezed el:

User-agent: Googlebot
Disallow: /

Ebben az esetben a Google nem fogja indexelni a weboldalad. Ez akkor lehet indokolt, ha egy adott oldal mondjuk kétszer van jelen a weben és nem akarsz a duplikált tartalom hibájába esni. Természetesen nem csak a Googlebotot tilthatod ki, hanem bármely más botot is, melynek ismered a nevét. Ez nem mindig egyszerű, lehet, hogy sokat kell keresgélni utána.

Ha viszont minden botot ki akarsz tiltani a webhelyedről, akkor így fog kinézni a két sor:

User-agent: *
Disallow: /

Ez használható például abban az esetben, ha még nem akarod nyilvánosságra hozni a weboldalad. Gyakoribb, hogy csak egy bizonyos mappát akar a weboldaltulajdonos elérhetetlenné tenni, akkor meg kell adnia a mappa nevét a /…/ jelek között.

Nagyjából ennyi lenne, amit a botokról első körben tudni érdemes, az nyilván látszik, hogy a rossz botok kiszűrése nem megy könnyen, illetve nem egy automatikus folyamat. Próbálkozni mindenesetre lehet és talán érdemes is.

The post Mi az a robot a weben? És hogyan tartsd távol őket a weboldaladtól? appeared first on Webshark Blog.

Ez még így elég megfoghatatlannak tűnhet, így érdemes talán azzal kezdeni, hogy elmagyarázzuk, mi is volt a web 1.0 és a web 2.0. A történet a ’60-as évek közepén kezdődik, amikor megjelent az internet, vagyis olyan hálózatok, melyeket a tudósok és a hadsereg hozott létre. A hálózat működésére ekkor még az egyszerű szöveges üzenetküldés volt jellemző, amiből aztán kialakult az e-mail.

Nemsokára Tim Berners Lee közreműködésével létrehozták a World Wide Web koncepcióját. A ’90-es években az internet a legegyszerűbb HTTP és URL protokollokat használta, hogy összekössön számítógépeket egy hálózatban. Megjelentek a weboldalak, melyek statikusak voltak, és alapvetően szöveges tartalmakat kínáltak. Ekkor még közösségi média helyett csak az IRS protokollt használó egyszerű chatek működtek.

Mivel a közönség érdeklődése egyre inkább nőtt az internet iránt, így egyre több pénz folyt a fejlesztésekbe. Olyan nagy szereplők vetették meg a lábukat, mint a Microsoft, az Apple és a Google. A tartalmak elkezdek egyre összetettebbekké válni és egy idő után világossá vált, hogy a szöveges, egyirányú web 1.0 nem fogja kielégíteni a felhasználói igényeket.

Az úgynevezett dotcom lufi kipukkadása után megjelent az úgynevezett web 2.0, mely a 2000-es évek elejétől gyakorlatilag máig tart. A web 2.0-ra jellemző a közösségi hálózatok megjelenése, a videó és audio streaming, a felhasználói tartalomkészítés. Az eltelt több mint 20 év alatt persze nagy volt a fejlődés, hiszen eleinte még a ’80-as évekből eredeztethető technológiákat használtak, amik aztán folyamatosan fejlődtek a változó igények miatt. Az egyre több felhasználó miatt egyre szűkösebbnek bizonyultak azonban a keretek, melyek jellemzően központosítottak voltak.

Utóbbi azért fontos, mert néhány szereplő kezében összpontosulnak az adatok, a szerverek, a felhőalapú tárolás, stb., így ők adják a kereteket, a lehetőségeket, meghatározva magát az internetet. Nemcsak a cenzúra vádja merül fel velük szemben, hanem az is, hogy feloszthatják a netet geopolitikai jellemzők alapján. Egyre többen kezdik azt gondolni, hogy a web 2.0 sikere ellenére a helyzet megérett a változásra. Ráadásul felmerültek olyan problémák is, melyet ezen keretek között nem lehetett megoldani, ezért is alapvető változásra volt szükség.

Miről szól a web 3.0?

A változáson már a 2000-es évek közepén elkezdtek gondolkodni a fejlesztők, akik arra jutottak, hogy az internetnek szemantikusnak kell lennie, melyet az emberek és a robotok egyaránt jól tudnak használni. Ez az elképzelés azonban csak elmélet maradt, nem kapott elegendő támogatást.

A változást a blokklánc és az elosztott főkönyvi technológiák felemelkedése és terjedése hozta el, ugyanis ekkor ütött szöget a fejlesztők fejében, hogy a web 3.0-nak blokklánc alapokra kell épülnie. Az ötlet Gavin Woodtól, az Ethereum korábbi műszaki igazgatójától származott, aki egy teljesen új internet-generációt vetített előre.

De milyen összetevők jellemzik a web 3.0-át? Az egyik a tartalomcímzés változása, tehát, hogy a tartalomhoz való hozzáféréshez nem kell feltétlenül tudni, hogy az milyen szerveren található. Vannak már olyan technológiák, mint az IPFS, a Swarm, a Dat-protokoll, melyeknél a linkben magában írják le a tartalmat, azt, hogy hol található, hogyan szállítják. Az ilyen linkek úgy néznek ki, mint egy normál „hash”, ennélfogva nem igazán olvashatók. Ennek ellenére lehet számítani arra, hogy a megújuló interneten mégis működni fog, és felváltja a HTTP-paradigmát, illetve az URL-szabványokat.

Egy másik eleme a 3.0-ás webnek az úgynevezett számítási konszenzus. Jelenleg a blokklánc úgy néz ki, mint egy egyszerű adatbázis, melyből hiányoznak azok az apró részletek, melyek révén az adatbázis intelligens tudásgráffá lenne alakítható. Ugyanakkor a Cosmos vagy a Tendermint technológiák felhasználásával indexelhető lehet az internet úgy, hogy létrehozható legyen a blokklánc-technológiákra épülő tudásgráf.

Ezek a technológiák lehetővé teszik a felhasználók számára az adatokhoz való hozzáférést úgy, hogy azt ne akadályozzák azt különböző cégek, a cenzúra vagy bármely tényező. A Cosmos és a Tendermint már létező technológiák, melyek leírják, hogy miként kapcsolódhatnak a blokkláncok és juthatnak konszenzusra egy elosztott tudásgráf kialakításában. Ezek az adatok pedig decentralizált nyilvántartásokban szerepelnek.

A következő fontos jellemző az, hogy míg a web 2.0 esetében a felhasználók után rengeteg információ marad a weben – melynek oka az internet architektúrájában keresendő -, addig a blokklánc révén a felhasználók végre „szabaddá” válhatnak.

Ennek révén nem a felhasználó valós személyisége jelenik meg a weben, hanem csak karaktere, avatárja, mely pusztán egy adathalmaz lesz a blokkláncban. Ilyen crypto-személyiség persze nem csak valós személy lehet, hanem akár egy robot vagy bármely organizmus.

Végül pedig egy negyedik összetevője a web 3.0-nak, hogy ott a felhasználók szabadon – azaz cégek engedélye, irányítása, szabályozása nélkül – hozzáférhetnek a hálózathoz, azt módosíthatják, másolhatják az adatokat. Ez egy olyan architektúra, ahol a felhasználók eldönthetik, hogy meghagyják-e például a keresési lekérdezéseikkel kapcsolatos információkat vagy nem, esetleg kapjanak-e reklámokat vagy sem.

Az első próbálkozások már láthatók a web3-as böngészőknél: ilyen a MetaMask, mely egy böngésző az Ethereumon a Mist, mely a Parity csomóponttal működik együtt, vagy akár a már eléggé elterjedt Brave. Ezek a böngészők már magukban hordozzák a megújult internet vízióját, igaz egyelőre mindegyik valamiképpen függ a web 2.0-tól.

Mi lesz a weboldalakkal?

Hogyan tud megfelelni a weboldalad a 3.0-ás követelményeknek? A válasz azért nehéz, mert bár a web 3.0 már körül lett rajzolva, ugyanakkor a decentralizált és szemantikus web még messze van a megvalósítástól. Ugyanakkor van néhány olyan funkció, melyek már használhatók bármely webes felületen.

Az egyik ilyen a „felszabadított” felhasználói felület, mely gördülékenyebben használható és felhasználóbarátabb, mint a korábbiak. Egy ilyen típusú weboldal elkészítéséhez kellenek a megfelelő adatok és egy analitikai rendszer. A mesterséges intelligenciát használó keretrendszerek révén a jövőben jobban megérthetőek lesznek a felhasználói igények a megjelenésre vonatkozóan. Olyan adatokra alapozva, mint a kor, a nem, a hely, a foglalkozás és egyebek, a tapasztalt designerek pontosan meg tudják határozni a követelményeket.

Habár a megfelelő adatok használatával készülő hatékony weboldalak ma már bevett gyakorlatnak számítanak, a jövőben ez iparági szabvánnyá válik.

Emellett a weboldalakat optimalizálni lehet a szemantikus webre. A szemantikus web, illetve a szemantikus keresés lényege az, hogy megértsük, pontosan mit jelent az adott felhasználó számára egy keresőkifejezés, és ennek megfelelő válaszokat szolgáltassunk. A felhasználók egyre inkább elvárják, hogy a kereső értse azt, hogy ők mit akarnak. Ehhez persze kellenek a kifinomult és részletes adatok, adatelemzés a célközönségről, illetve a strukturált adatok használata a weboldalaknál.

Végül pedig a chatbotok használata, melyek szintén a szemantikus élményt teremtik meg. A chatbotokat már évek óta alkalmazzák, és talán a Te weboldaladon is van már egy. Ugyanakkor ezek még messze nem elég fejlettek, nem tudnak annyit, mint egy valós személy. A technológia azonban fejlődik, létezik például a GPT-3 (Generative Pretrained Transformer 3), mely egy képzett AI eszköz. Ez egy újgenerációs algoritmus – ami szemben a hagyományos AI-alapú chatbotokkal, melyek menet közben tanulnak -, mely már a szükséges adatokra van felépítve, így bármilyen tartalmat létrehozhat, melynek van nyelvi struktúrája.

Habár mindez még talán elég ködösen hangozhat, hamarosan gyakorlattá válik – és lassan érthetővé is -, hiszen a web 3.0 már itt kopogtat az ajtón. A segítségével egy igazságosabb online élmény lesz létrehozható, ahol a megfelelő válaszok születnek a felhasználói kérdésekre. Ahhoz, hogy Te is részese legyél a web 3.0-nak, nyitva kell állnod a változásra.

The post Mi az a web 3.0? És miért fontos a weboldalad szempontjából? appeared first on Webshark Blog.

Amikor az emberek weboldalakról beszélnek – vagy akár amikor mi írunk róluk -, akkor a statikus-dinamikus szembeállítás kérdése ritkán merül fel. Ugyanakkor, nem árt tudni róla annak, aki egy kicsit jobban belebonyolódik a webdesign világába.

Amikor weboldalakról vagy weboldalak tervezéséről beszélünk, akkor alapvetően azt bonjuk ki részletesen, hogy mitől lesz jó egy weboldal, hogyan lesz hatékony a webdesign, mi az, ami javítja a felhasználói élményt, hogyan használjuk a színeket, a betűket, a távolságokat vagy hogyan készítsünk tartalmat az oldalra. Azon ugyanakkor nem sokat szoktunk gondolkodni, hogy akkor valakinek dinamikus vagy statikus weboldalra lenne szüksége.

De mit is jelent az egyáltalán, hogy egy weboldal statikus vagy dinamikus? Egyszerűen fogalmazva a statikus oldal nem változik a felhasználói interakciók hatására, míg a dinamikus képes a változásra.

A statikus weboldalon tehát az elemek rögzítettek, illetve nem képesek a változásra annak hatására, hogy azon mit tesznek a felhasználók. Az ilyen weboldalak egy meghatározott számú aloldallal kerülnek kialakításra, és amíg a weboldal tulajdonosa ezek számát nem növeli, illetve tartalmukat nem módosítja, addig változatlanok.

Tehát, ha van egy kisebb weboldalad, mondjuk egy céges weboldal, ami bemutatja a céged működését, amivel szeretnél információkat átadni magadról az érdeklődő olvasóknak, akkor neked is statikus weboldalad van, és lehet, hogy nincs is többre szükséged.

Ezzel szemben a dinamikus weboldalak többet tudnak, mint a pusztán információs célzatú statikus megoldások. Úgy is hívják őket, hogy adatbázis-vezérelt weboldalak, aminek az az oka, hogy a megjelenő információk annak függvényében változnak egy-egy felhasználó számára, hogy mit tesz, esetleg honnan érkezik az adott felhasználó. Az ilyen weboldalak egyes oldalai tehát valós időben generálódnak le egy-egy felhasználó számára a róla gyűjtött adatok figyelembevételével.

Az ilyen weboldalak szerveroldali és kliensoldali szkripteket is használnak, a tartalmakat egy adatbázisból, vagy egy tartalomkezelő rendszer (CMS) segítségével jelenítik meg egy adott felhasználó számára. A webáruházak, a közösségi média oldalak is ebbe a körbe tartozhatnak, így dinamikus weboldal például a Facebook, az Amazon vagy a Netflix.

Amit még érdemes tudni a kétféle típusú weboldal közötti különbségről, hogy a statikus weboldalak megjelenítéséhez a HTML, a CSS, a JavaScript használata is elegendő lehet, míg dinamikus weboldalaknál olyan szerveroldali nyelveket is használnak, mint a PHP, a SERVLET, a JSP, az ASP.NET, stb.

Szintén lényeges tényező a kettő költsége közötti különbség, hiszen egy statikus weboldalnak egyszerűbb a fejlesztése és a fenntartása, így a költsége is jóval alacsonyabb, mint a dinamikusé, ahol a funkciók száma is jellemzően nagyobb.

Amit még esetleg érdemes megemlíteni, hogy keresőoptimalizálás szempontjából is jóval egyszerűbb a helyzet egy statikus weboldallal, többek között a gyorsabb betöltődés miatt, míg a dinamikus weboldalaknál egy-egy oldal dinamikusan generált jellege miatt nem feltétlenül lehet egy adott kulcsszóra optimalizálni, de gondot okoz az is, hogy ezek sokszor úgynevezett végtelen görgetésű oldalak, ahol a tovább tartalmak lefelé görgetésre generálódnak.

Alapvetően ennyit érdemes tudni, és nem igazán kérdés, hogy melyiket válaszd, hiszen vagy az egyikre, vagy a másikra van szükséged a weboldalad jellegéből kifolyólag.

Mindenesetre az elmondható, hogy egy dinamikus megoldás elkészítése, elindítása jóval összetettebb folyamat, ugyanakkor a későbbieket tekintve már lehet, hogy egyszerűbbé válik.

Tehát, ha egy szimplán információs weboldalra van szükséged, ahol bemutatod a céged, a termékeid és a szolgáltatásaid, ahol nincs szükség interaktivitásra, akkor egy statikus weboldal tökéletesen megfelel az igényeidnek, viszont ha egy komolyabb webáruházat készítesz, akkor már dinamikus weboldalban kell gondolkodnod.

The post Mi a különbség statikus és dinamikus weboldalak között? appeared first on Webshark Blog.

A webes szabványok azért fontosak, mert erősítik és következetessé teszik a web használatát. Minél inkább ragaszkodunk a betartásukhoz, annál használhatóbbá válik a web mindenki számára. Még akkor is ismerhetsz közülük néhányat, ha nem kódolsz weboldalakat.

Honnan is származnak a webes szabványok?

A kezdeti időkben a különböző böngészők nagyon eltérő technológiákat alkalmaztak, ami rendkívüli módon megnehezítette azt, hogy a weboldalak mindegyiken megfelelően jelenjenek meg. A világháló létrehozója, Tim Berners-Lee is érezte, hogy ebben a helyzetben valamit tenni kell, és megszületett a Wold Wide Web Consortium (W3C). A W3C küldetése az, hogy egységes szabványokat alakítson ki, melyek lehetővé teszik, hogy a web jó irányba fejlődjön.

A W3C nem az egyetlen olyan szervezet volt, mely szabványokat hozott létre az internet számára. A Web Standards Project a ‘90-es években jelent meg, és a W3C-t támogatta. Egyéni küldetése az volt, hogy olcsóbbá és egyszerűbbé tegye a web működését. Habár 2013-ban megszűnt, fontos szerepe volt abban, hogy a böngészők támogassák a HTML4-et és az XHTML-t.

Jelenleg is vannak a W3C-n kívül más szabványokkal foglalkozó szervezetek, melyek segítenek rendet tenni a weben. Néhány nagyobb szervezet, mely jelenleg is aktív:

• az Ecma már a ‘60-as évek óta létezik, célja a kommunikáció és az információs rendszerek szabványainak kialakítása. Emellett felelős az ECMAScript fejlesztéséért, mely szabványosított JavaScript.
• az Internet Engineering Task Force (IETF) célja az internet felépítésének erősítése, miközben egy nyitottabb környezetet hoz létre.
• a WHATWG közösség számos szabványt hozott létre az URL-ekkel, a kódolással, az API-kkal kapcsolatosan.

Ezek a szervezetek nem a pénzszerzés érdekében működnek. Az egyetlen céljuk az, hogy létrehozzák a szabad, ingyenes és hatékony internetet minden felhasználó számára.

Miért van szükségünk ezekre a webes szabványokra?

Röviden: a felhasználók számára megteremtik a “kiszámítható” webet. Ami nem azt jelentik, hogy lehetetlenné teszik a kreativitásod kibontakoztatását egy weboldal megtervezésénél, ugyanakkor meghatározzák, hogy miként működjenek, és a felhasználók miként lépjenek velük interakcióba. Ehhez ugyanis következetesen használt elemekre van szükség az egész weben. Ennek eredményeként pedig egy vonzóbb környezet jön létre a felhasználók számára. Tehát nem, hogy akadályozza a weboldalkészítőket, hanem hatékonyabbá válik a munkájuk, illetve mindannyian részt vehetnek egy jobb – jól felépített és akadálymentes – web kialakításában.

Milyen szabványokról beszélhetünk?

Érvényes HTML, CSS és JavaSript

A rosszul megírt kódok sok problémát okoznak a weboldal teljesítményét illetően. A HTML, a CSS és a JavaScript jelenti a web gerincét, ezért szigorú szabványok határozzák meg, miként írhatók meg, hogyan használhatók. A verziók ugyanakkor időnként változnak, ahogy megjelennek az újabbak, így például legutóbb a HTML5 vagy a CSS3.

A kódolás szabványosításával mindenesetre lehetővé válik a fejlesztők és a designerek számára, hogy azonos nyelvet használjanak, és hogy ezt a nyelvet minden böngésző és a többi szoftver is megértse.

Grafikára vonatkozó követelmények

A grafikára vonatkozó szabályok betartása a webdesignerek számára fontos elsősorban, ugyanakkor nem annyira szigorú szabványt jelent, hanem inkább az optimális használatról szól. A W3C-nak erre is van ajánlása:

• PNG a fotók számára
• SVG az adatvizualizációknál
• CSS az alap HTML kibővítésére
• Canvas API a gradiensek, formák és egyéb effektusok létrehozására
• WebCGM a vektorgrafikáknál

Tehát, ha azt akarod, hogy a weboldalad a lehető leghatékonyabb legyen, akkor ezeket az ajánlásokat érdemes komolyan venni.
Reszponzivitás

Az okoseszközök terjedése és típusaik megszaporodása miatt a mobil webnek is szabványokra volt szüksége. Ez azonban nem merült ki pusztán a reszponzív designban, hanem kapcsolódik hozzá néhány bevett megoldás is. Ezeket itt foglalta össze a W3C.

Az iránymutatások azonban nem csak a designra vagy a használt eszközökre vonatkoznak, hanem kiterjednek többek között a fizetések feldolgozására, a weboldal-biztonságra vagy a teljesítményre. A bevált megoldásokra vonatkozó ajánlások összessége itt tekinthető át. Várhatóan egyébként a jövőben még nagyobb hangsúly helyeződik a mobil webszabványokra, ahogy egyre több ember mobileszközökről éri el a weboldalakat.

Web architektúra szabályai

A web architektúrára vonatkozó szabványok arról szólnak, hogy a felületek mögött miként strukturáljuk az információkat. A szabványok vonatkoznak többek között:

• az URL-ekre és URI-kra,
• az XML-re,
• a HTTP-re és HTTPS-re,
• a karakterkészletekre,
• a kódolásra.

Amennyiben szabványokat használunk a web egyes részeinek címkézésére és azonosítására, akkor jobban használhatóvá válnak.

Akadálymentesség kialakításának szabványa

A Web Acsessibility Initiative (WAI – webes akadálymentesség kezdeményezés) része a Word Wide Web konzorciumnak. A szabványosított akadálymentesség rendkívül fontos, ugyanis nem csak azt befolyásolja, hogy a fejlesztők miként kódolnak vagy a designerek hogyan terveznek. A vonatkozó szabályok mindenkit érintenek, aki közreműködik egy weboldal elkészítésében: szövegírókat, tesztelőket, projektmenedzsereket, stb.

Habár komoly információmennyiségről van szó a szabályokat tekintve, ha olyan weboldalt szeretnél, mely jól kiszolgálja a nyilvánosságot, akkor ezeknek a szabványoknak a betartása fontos része a munkának.

(A bejegyzés ezen szöveg alapján készült.)

The post Mik azok a webes szabványok? És miért van szükséged a betartásukra a weboldaladnál? appeared first on Webshark Blog.

Azok számára, akik nem is igazán tudják, hova tegyék a HTTP-t, és mit is jelent ez számukra, a Smashing Magazine összefoglalója alapján a gyökereknél, azaz a HTTP mibenléténél kezdjük.

Mi az a HTTP, az SPDY és a HTTP/2?

A Hypertext Transfer Protocol a szerverek és a böngészők közötti kapcsolatot irányítja. 1991-ben jött létre, míg első javított verziója HTTP/1.1 névre hallgatott, és 1999 óta él velünk, de sokáig nem nyúltak hozzá. Pedig akkoriban a weboldalak még nagyon máshogy néztek ki, mint amilyenekkel most futhatunk össze a weben. Elsősorban a weboldalak mérete növekedett meg azóta, így ma egy átlagos weboldal 1,9 MB és több mint 100 egyéni forrás szükséges ahhoz, hogy megjelenjen az oldal a böngészőablakban. Az egyéni forrás alatt olyan elemeket kell érteni, mint egy kép, egy font, egy JavaScript vagy egy CSS fájl.

Manapság igen komoly küzdelem folyik a weboldalak sebességének javítása érdekében, és ebbe beletartozik az is, hogy csökkenteni kell a betöltendő elemeknek a számát, méretét, hogy még elfogadható sebességet érjünk el. A HTTP/1.1 nem igazán teljesít jól, amikor a mai követelményeknek kell megfelelnie.

Már 2009-ben két mérnök a Google-től bejelentette, hogy dolgoznak egy SPDY névre hallgató kutatási projekten, ami kiküszöböli a HTTP/1.1 néhány hiányosságát, és azóta már itt-ott használják is. Ennek az egyik legkomolyabb előnye az úgynevezett multiplexing, vagyis, hogy párhuzamosan több lekérés kiszolgálását is lehetővé teszi egyetlen TCP kapcsolaton keresztül. Emellett a böngészők priorizálhatják, hogy mi az, amit a legfontosabbnak tartanak egy weboldal megjelenítésénél. Csökkenti a HTTP header méretét és azok számát, valamint megjelenik a server push, vagyis, hogy a szerverek a legfontosabb elemeket már azelőtt elküldik a böngészőnek, hogy az lekérné őket. Ami még fontos, hogy mindehhez titkosított, azaz HTTPS kapcsolat szükséges a szerver és a böngésző között.

Az SPDY egyébként nem váltotta le a HTTP-t, inkább egy csatornát jelentett a protokollban és megváltoztatta azt a módot, ahogy a lekérések és a válaszok küldésre kerülnek. Ehhez támogatást igényelt mind a szerver, mind pedig a böngészők részéről. Ez ma már nem gond, a NGINX fel van készítve rá, és az Apache esetében is elérhetők a megfelelő csomagok a Google-től, ahogy a böngészők minden modern verziója is támogatja. Kivételt a Microsoft Edge jelent, mely az IE 11-től eltérően nem támogatja az SPDY-t. Támogatja viszont a HTTP/2-t, vagyis a HTTP protokoll legújabb verzióját.

Az SPDY-támogatás egyébként a Chrome-ból is ki fog kerülni még az idei évben, és valószínűleg a többi böngésző is követi ezt a lépést. Ugyanakkor a HTTP/2-t már a Firefox, a Chrome és az Opera is támogatja, valamint a Safari a 9-es verziótól.

Itt az ideje tehát, hogy ejtsünk pár szót a HTTP/2 lényegéről is. Ez a protokoll-verzió tulajdonképpen azt viszi tovább, amit az SPDY már tudott. Habár ennél nem követelmény a HTTPS kapcsolat megléte, a böngészők csak TLS (HTTPS) esetében támogatják a HTTP/2-t. Ez pedig azt jelenti, hogy csak akkor kezdhetsz gondolkodni a HTPP/2-re való váltáson, ha már HTTPS kapcsolattal elérhető a weboldalad.

2015 februárjában véglegesítették a HTTP/2 szabványt, így egy év elteltével a támogatás a legfrissebb verziójú böngészőkben már adott, ahogy a szervereknél is fokozatosan megtörténik a bevezetés. A W3Techs 2015 júliusában már közölt egy statisztikát a bevezetés gyorsaságáról, akkor azért még jócskán voltak elmaradások, de azóta sok idő eltelt.

A HTTP/2-ről egyszerűbben

Miután beszéltünk a szabványok fejlődéséről, most lássuk, hogy mit is tud a gyakorlatban a HTTP/2. Onnan induljunk ki, hogy amikor rákattintasz egy linkre egy weboldalon, akkor egy kérést kap a szerver. A szerver erre válaszol egy státuszüzenettel és az adott oldal fájllistájával. A böngésző ezután elkezdni lekérni a fájlokat.

A régi, azaz HTTP1.1-es protokoll esetében ez meglehetősen lassan zajlott, mivel egyesével mentek át a fájlok, és csak egyetlen vonalat használt az átvitelre úgy, hogy minden fájl esetén újra nyitotta és zárta azt. A HTTP/2 ezt a folyamatot felgyorsítja azzal, hogy folyamatosan nyitva tartja a vonalat és egyszerre jóval nagyobb adag áramlását biztosítja.

A Yoast által felhozott példa világítja meg talán a legjobban a működésbeli különbségeket: amikor van egy doboz Legód, akkor úgy állsz neki, hogy nézed az instrukciókat. Ez általában úgy épül fel, hogy tégláról-téglára, egyesével bemutatja, mit hova rakj. Vagyis egy időben egyetlen elemmel foglalkozol. Amikor azt elhelyezted, újra rátekintesz a leírásra, és megnézed, hogy a következő elemet hova kellene tenned. Ha mondjuk több ezer elem van a dobozodban, akkor ez a folyamat elég sokáig fog tartani. A HTTP1.1 valahogy így működik.

Ezzel szemben a HTTP/2-nél úgy történne, hogy egy nagyobb résznek tudod lekérni az összeállítási útmutatóját, és anélkül tudsz instrukciókat kapni az újabb elemek elhelyezéséhez, hogy rá kellene nézned az útmutatóra. Ha igazán gyors akarsz lenni, akkor akár az összes elemet lekérheted egyszerre, és egyből összeállíthatod a Legódat.

A lényeg tehát az, hogy a HTTP/2 egyszerre több dolgot tud kezelni: egy időben több lekérés történik egy – az átvitel során – folyamatosan nyitott kapcsolaton. Ez a legfontosabb a gyorsabb működés szempontjából. Ugyanakkor egy másik fontos dolog az úgynevezett szerver push: itt is egy lekéréssel indul a folyamat, azonban amikor a szerver észleli, hogy a HTML-nek további dolgokra van szüksége, akkor kérés nélkül küldi ezeket.

SEO szempontból elsősorban azért jó a HTTP/2, mert a weboldalsebesség rangsorolási tényező már évek óta. A mobil index indulásával pedig még fontosabbá vált. Miközben a weboldalak várhatóan csak egyre nagyobbak lesznek. A nagy weboldalak pedig sok elemből állnak: HTML, JavaScript, CSS, képek, stb. Ez pedig csak növeli a betöltési időt.

Egy másik fontos dolog a késleltetés, elsősorban a mobileszközöknél. Minél nagyobb a késleltetés, annál több idő, hogy egy kérést megkapjon a szerver, majd erre küldjön egy választ. Ez az oka annak, hogy érdemes CDN-t használni. Ezáltal csökkenthető az idő azok számára, akik egy közeli pontból neteznek.

Emellett persze vannak még további lehetőségek a szerverek finomhangolására a weboldalsebesség javítása érdekében, de a HTTP1.1 egy alapvető problémát jelentett. A HTTP/2 viszont sokkal könnyebbé teszi a folyamatok kezelését a szerverek és a böngészők számára, ezáltal pedig jelentős mértékben gyorsítja a weboldalt.

Az átállás sem túl bonyolult, és már az is lehet, hogy a szervered használja a HTTP/2-t.  Ezért ellenőrizd a szolgáltatódnál, hogy milyen lehetőségeid vannak. Emellett érdemes lehet a CDN-nel is megpróbálkoznod. A lényeg, hogy a HTTP/2 jelentős sebességnövekedést eredményez, ráadásul a biztonságot is fokozza, hiszen alapból HTTPS kapcsolatot használ.

Kötelező az átállás?

Mivel a HTTP/2 visszafelé kompatibilis a HTTP/1.1-gyel, így semmi gondot nem okoz, ha valaki egyáltalán nem foglalkozik a dologgal, és nem eszközöl módosításokat a weboldala esetében. Minden ugyanúgy fog működni, ahogy eddig is. A felhasználók sem fogják észrevenni, hogy HTTP/1.1-en, SPDY-on vagy épp HTTP/2-n érnek el bizonyos oldalakat. Csak egyetlen dolog fog feltűnni, amikor egyre több weboldal vált HTTP/2-re, hogy a Te oldalad valahogy sokkal lassabb lesz, mint a többieké.

Ahhoz, hogy Te is átállhass a HTTP/2-re, először is arra lesz szükség, hogy a szerver-szoftver támogassa már ezt a protokollt. Ezzel csak az a probléma, hogy ezt nem Te határozod meg, hanem a hosting-szolgáltatód. Mielőtt a weboldaladon változatásokat eszközölnél, annak a kérdésnek is érdemes egy pár percet szentelni, hogy a felhasználóid olyan böngészőket használnak-e már, mely támogatja az új protokollt. Azok számára, akiknek a felhasználói a legújabb böngészőkkel nézik a weboldalát, nyilván érdemes lenne minél hamarabb lépni az ügyben.

A weboldalak számára az egyik legnagyobb problémát az átállás kapcsán nem is az jelenti, hogy váltani kell HTTP/2-re, hanem sokkal inkább az, hogy ehhez alapvető követelmény a biztonságos kapcsolat, azaz a HTTPS. Új weboldalaknál érdemes már eleve ezzel indítani, illetve régi weboldalak esetén a redesign során meglépni a váltást.

Ez egyébként azért is hasznos, mert a Google is előnyben részesíti már a találati oldal kialakításánál a HTTPS kapcsolatú oldalakat, vagyis ezeket választja, ha adott egy oldalból HTTP és HTTPS verzió is, ráadásul a böngészők jelezni fogják külön, ha egy weboldal kapcsolata nem biztonságos, valamint a jövőben jó pár fontos HTML5-funkció sem lesz elérhető, csak biztonságos kapcsolaton keresztül.

A lényeg tehát az lenne, hogy ha a Te weboldalad is HTTP-t használ, akkor az első lehetséges alkalommal állj át HTTPS-re, majd utána valamikor érdemes váltanod HTTP/2-re!

Hogyan készülj elő a HTTP/2-re?

Ha épp elindítasz egy projektet, mely terveid szerint hosszú távú lesz, akkor érdemes előkészületeket tenned a HTTP/2-re való átállásra, még ha azt jelen pillanatban egyelőre nem teszi lehetővé a szervertámogatás hiánya. Az egyik dolog, hogy ha sprite-okat használsz, akkor készítsd el az oldal-specifikus vagy sprite-ok nélküli megoldást, így könnyebb lesz a váltás a nagy sprite-okról. Ugyanez a helyzet a data URI-kkal is, melyeket ha használsz a CSS-edinél, akkor a képeket készítsd fel a váltásra, amikor már nem fogod ezeket használni.

A CSS-ek és JavaScriptek összefűzésénél jobb teljesítményt érsz el HTTP/2 alatt a források megfelelő elrendezésével az egyetlen fájl helyett. Vagyis csak azok a fájlok töltődjenek be valamely oldal letöltésénél, amire az oldal megjelenítéséhez éppen szükség van. Ha már most ennek figyelembe vételével fejlesztesz, az később kifizetődő lesz számodra.

A HTTP/2-ről összességében elmondható, hogy teljesen más megoldásokat kell majd alkalmaznod, mint amit megszoktál HTTP/1.1 alatt. Az új protokoll visszaadja az irányítás nagy részét a kezedbe, ami azt is jelenti, hogy minden egyes projektnél szükség lesz új döntések meghozatalára.

Sok dolog nem került most szóba, amivel szintén foglalkoznod kell majd, ilyen például a szerver push lehetősége, melynek révén eldöntheted majd, hogy mely források kapnak prioritást, és utasíthatod a szervert, hogy ezeket előbb töltse be, mint a kevésbé fontos dolgokat. Az ehhez kapcsolódó megoldások a későbbiekben alakulnak még, így érdemes figyelni az egyre szaporodó gyakorlati példákat és felhasználni a tapasztalatokat.

Mikor válts HTTP/2-re?

Azon esetekben, amikor a szerverek felett nem Te gyakorlod a felügyeletet, a váltással várhatsz egészen addig, míg a szerverek készen nem állnak a HTTP/2-re. Persze már vannak olyan hosting-szolgáltatók, ahol felkészültek a HTTP/2-re, így ha előnye származik egy weboldalnak a váltásból, akkor meg kell tenni. Kérdés, hogy az adott weboldal felhasználóinak többsége készen áll-e rá, azaz alkalmas-e böngészőjük a HTTP/2 használatára. Mivel a HTTP/2 visszafelé kompatibilis, így a weboldalaknak nem muszáj bármit tenniük az átállás érdekében. Csak ahogy már korábban is említettük, optimalizálás hiányában lényegesen lassabb lesz a weboldal, mint a konkurenciáé.

Érdemes tehát figyelni az analitikai adatokat, és ha azt látod, hogy a felhasználóid többség már HTTP/2-képes böngészőt használ, akkor itt az idő a váltásra. Ez a legtöbb esetben egyébként már most is így van, így ez nem akadály. Különösen fontos lenne lépni akkor, hogy nagy a mobilról érkező forgalmad.

Ha pedig éppen most készítesz egy új weboldalt, akkor már mindenképpen érdemes a fejlesztés során HTTP/2-re optimalizálni, még akkor is, ha az indulásnál HTTP/1.1-et fogod használni a szerver-támogatás hiánya miatt, és emiatt kompromisszumokra kényszerülsz.

Röviden összefoglalva tehát úgy néz ki a folyamat:

1. Válts biztonságos kapcsolatra már most!
2. Készülj fel a HTTP/2-re a fejlesztés során!
3. Figyeld az analitikát!
4. Ellenőrizd a hosting-szolgáltatód készültségét!
5. Végül váltsd le a korábbi megoldásokat a HTTP/2-nél megfelelőekre!

Képek, CSS, JS és a HTTP-lekérések száma HTTP/2-nél

A HTTP/1.1 esetben a böngészőnek egyszerűbb egy nagy képfájlt megjelenítenie, mint sok kicsit, a sok lekérés miatt. Ezért célszerű ezeket a kis fájlokat egy sprite fájlba rendezni. Ez ugyanis egyetlen HTTP-lekérést jelent, így megelőzi a sok lekérés okozta problémát. Ugyanakkor, ha egy felhasználónak valamely oldalon mindössze egyetlen kis képet kell megjeleníteni, ahhoz is az egész sprite fájlt le kell tölteni.

A HTTP/2 esetében azonban ez már nem probléma a korábban is említett multiplex-képesség miatt. A legtöbb esetben a kis képek egyéni megjelenítése jobb eredményt hoz majd, a felhasználóknak pont azt a képet kell megjeleníteni, ami az általuk meglátogatott weboldal megtekintéséhez szükséges.

Ugyanakkor a sprite-ok használata sem elvetendő egyes esetekben, hiszen bizonyos képek sprite-okba rendezésével jobb tömörítés érhető el, így a letöltési méret kisebb lesz. Elsősorban tehát akkor érdemes használni a sprite fájlokat, ha a képek mind a letöltendő oldalon szerepelnek. Ugyanakkor az kijelenthető, hogy a HTTP/2 esetében már nem minden esetben a sprite a lehető legjobb megoldás.

A CSS-ek és a JavaScript fájlok esetében ugyanez a helyzet, tehát ezek összefűzése csökkenti a HTTP-lekérések számát. Ugyanakkor ez a megoldás gyakran azzal jár, hogy a felhasználóknak akkor is le kell tölteni az összes CSS-t és JS-t, ha a legtöbbet soha nem fogják használni. Természetesen a dolgot lehet optimalizálni a fájlok megfelelő elrendezésével, ez azonban elég sok munkával jár.

További probléma ezekkel az összefűzésekkel, hogy ilyenkor egyszerre ürülnek ki a fájlok a cache-ből. Nem tudod megtenni, hogy egyes fájlok esetében soha ne változzon a hosszú lejárati idő, miközben a kód gyakran változó részeinél rövidebb lejáratot határozol meg. Mindegyik le fog járni, még ha csak a CSS egyetlen sora, egyetlen oldalon is megváltozik.

De mivel a HTTP-lekérések már nem jelentenek gondot a HTTP/2 esetében, sokkal egyszerűbbé válik a CSS és JavaScript elrendezése is. Elég lesz csak annyit betölteni a kódból, amennyire a felhasználónak szüksége van, nem fog számítani, hogy sok-sok kis stíluslapot kell letölteni. Az alapján érdemes majd szervezni ezeket a fájlokat csoportokba, hogy milyen gyakran változnak.

Emellett a HTTP/1.1 esetében korlátozott a nyitott kapcsolatok száma. Amennyiben nagy a források száma, akkor megoldás lehet, hogy többféle domain alól kérjük le őket. A domain sharding használatával jobb letöltési idők érhetők el, ami azonban önmagában is problémát okozhat, nem beszélve arról, hogy ez milyen munkával jár. A HTTP/2 esetében nincs szükség erre a megoldásra, mivel a lekérések számának nincs korlátja. Sőt, a sharding használata rontja a teljesítményt, mivel további TCP kapcsolatokat igényel és megakadályozza a HTTP/2-t abban, hogy priorizálja a forrásokat.

The post Mi az a HTTP/2? És Te készen állsz már rá? appeared first on Webshark Blog.

A Forbes hasábjain, Denis Pinsky szedte össze gondolatait és osztotta meg a közönséggel az előbbiekkel kapcsolatban. Szubjektív a dolog persze, de úgy érezzük, hogy mindenkinek tanulságos lehet, így elétek tárjuk.

Üzenet az ügyfeleknek

Ahhoz, hogy egy weboldal jól működjön, többnek kell lennie, mint egy rakás szép kép. Sajnos azonban, úgy tűnik, hogy sok ügyfél ezt nem igazán érti meg. Ők azt gondolják, hogy egy weboldal elkészítése mindössze azt jelenti, hogy összedobunk egy jól kinéző felületet. Ugyanakkor nem veszik figyelembe, hogy egy weboldalhoz mindig tartozik egy hosszú funkciólista is, melyet szintén le kellene fejleszteni.

Az ügyfeleknek korlátozott a tudásuk azzal kapcsolatban, hogy milyennek kellene lennie egy weboldalnak. Ők úgy gondolnak rá, mint egy képre, amely ott van valahol a weben, miközben több millió felhasználót csalogat magához, akik aztán vásárlóvá konvertálnak. A weboldalak azonban nem így működnek, és ezt az ügyfeleknek is meg kell érteniük.

Ráadásul az ügyfelek mindig többet akarnak, mint amit a költségvetésük megenged számukra. Hollywoodi eredményeket szeretnének látni, miközben a büdzséjük csak egy garázsstúdióra elegendő. Pinsky ezért arra hívja fel az ügyfelek figyelmét, hogy lehetőleg használják a józan paraszti eszüket, és ne felejtsék el azt sem, hogy annyit kapnak, amennyiért fizetnek. Ha egy valóban hatékony, kifinomult weboldalt szeretne valaki, akkor annak bizony költsége van.

Üzenet a fejlesztőknek

A fejlesztőkkel az a probléma, hogy nagyon sokan közülük valamiféle furcsa extrának tartják az egyébként kötelező jellegű digitális marketing funkciókat, amikor weboldalt ajánlanak az ügyfélnek. Pedig ezeket az alapösszetevőket nem lehet opcionális lehetőségekként kezelni, amiért plusz díjat számíthatnak fel. Egy céges weboldal ugyanis nem statikus prezentáció, az azért készül, hogy az interakciók középpontja legyen.

Meg kell tehát szüntetni az olyan weboldalak készítését, melyek nem teljes mértékben funkcionálisak. Már az alapcsomagnak is része kellene, hogy legyen az összes digitális marketing eszköz, ami szükséges ahhoz, hogy egy weboldal valóban működjön, és hasznos legyen mind az ügyfelek, mind a tulajdonosaik számára. Ha egy ügyfél nem akarja megfizetni egy ilyen weboldalnak a költségét, akkor először edukálni kell, azaz megismertetni vele a funkciókban rejlő potenciált, ahelyett, hogy ezeket a funkciókat egyszerűen lehagynánk az oldalról.

Ne hagyd, hogy azt gondolják, egy alap-weboldal lehet kevesebb is, mint amit Te kínálasz nekik! És ha még mindig valami használhatatlan weboldalhoz ragaszkodnak? Akkor nem kell elvállalni a feladatot – tanácsolja Pinsky, aki azt is összefoglalta, hogy szerinte milyen követelményeknek kell az idei évben megfelelnie egy weboldalnak.

2016-ban egy weboldalhoz az alábbiak szükségesek:

• Reszponzív, mobilbarát design, mely könnyen használható minden eszközön, és alapvetően mobil élményre van tervezve.
• Gyors betöltődés, valamint optimalizáció a lassú internetkapcsolattal rendelkező felhasználók részére.
• Webanalitika, mely méri a forgalmat, a célokat és a konverziókat.
• Az összes fontos on-page SEO elem, beleértve az XML oldaltérképet.
• Egy olyan eszköz, melynek segítségével az ügyfelek új landing oldalakat tudnak készíteni promóciós kampányaikhoz.
• Egy CMS, melynek segítségével az ügyfelek új tartalmakat tehetnek közzé, és kezelhetik a már meglévő tartalmaikat.
• E-mail címeket gyűjtő űrlapok, melyek szinkronizálva vannak az ügyfél e-mail marketing rendszerével.
• Az alapvető biztonsági és adatvédelmi protokollok, mint például az egyszerű biztonsági ellenőrzések.
• Integrálja a releváns közösségi média csatornákat.

Ha az ügyfelek és a fejlesztők együtt tudnak dolgozni ezen minimum követelményeket figyelembe véve, akkor komoly fejlődést láthatnánk abban, ahogy a cégek online kapcsolódnának a vásárlóikhoz – véli. Csináljuk tehát jobban: használjuk a józan eszünket és a kommunikációt, hogy jobbá formáljuk a webet! Nos, ezzel mi is egyet tudunk érteni, hiszen ahogy szoktuk is mondani, együtt alakítjuk a webet, és nem árt, ha az jól használható és hatékony.

The post Milyen követelményeket kell teljesítenie a weboldaladnak 2016-ban? appeared first on Webshark Blog.

1. Sok a mobilos látogatód? Tegyél eléjük desktop oldalt!

Nincs annál idegesítőbb, mint amikor nagykijelzős mobiltelefonunk böngészője egy olyan weboldalt tölt be, aminek sem mobilnézete, sem nem reszponzív, sem nem adaptív, és ha mégis hajlandóak vagyunk rázoomolni a szövegre, akkor is ide-oda kell rángatni a kijelzőn az ujjunkat, hogy akár egy sort is el tudjunk olvasni. És az is csak akadozva megy. Ez a leghatékonyabb tömegpusztító fegyver. Neked is bevált, ugye?

2. Lassítsd le az oldalad!

A mobilról érkező látogatók elriasztásának másik eszköze – ha netán mégis van mobil-barát oldalad -, hogy kellően nagy méretű oldalt készítesz. Aminek betöltési sebessége egyáltalán nincs optimalizálva, semmiféle tömörítés nincs, így 5-6 vagy akár 10 másodpercet is igénybe vesz, mire egy mobiltelefonon betöltődik, lehetőleg terhelve a telefont és a mobilnetet is. Olyannyira, hogy a látogató csak szorítsa minél tovább a mobilját, gyöngyözzön a homlokán az izzadság, mire összeáll a weboldalad a kijelzőjén. De ha mégis akad olyan, aki megvárja ezt a pillanatot, akkor se add fel, itt a következő tippünk.

3. Legyél igazi művész!

Rúgd fel a megszokottat, az unalmast, legyél eredeti, amikor weboldalad tervezitek! Minden máshogy legyen, ahogy azt a látogatók megszokhatták, hiszen az egyformaság unalmas. Az a legjobb, ha a weboldaladra érkezéskor egyszerűen fogalmuk sincs a látogatóknak, hogy

• miről szól az oldalad,
• mit kínálsz nekik,
• hol kezdjék a navigálást,
• sőt, egyáltalán nem találják a menüt.

Ehhez azért elég kreatívnak kell lenned, kerülnöd kell mindenféle hagyományos elrendezést, lehetőleg a szövegeket is. De ha mégis van ilyesmi, akkor a címek ne legyenek észrevehetők és a kisbetűs mondatok legyenek minél semmitmondóbbak. A legjobb persze, ha csak képekben tobzódik a weboldalad, és azok kellően absztraktak, művésziek, emberek, arcok meg se jelenjenek rajtuk, annak érdekében,hogy semmiféle fogódzót ne találjon a látogató.

A logód úgy helyezd el, hogy eszükbe se jusson, hogy az lenne a logód, és a menüt is szerencsés oda rakni, ahol senki sem keresné. Ezért a bal felső sarkot mindenképpen kerüld el, a többi rád van bízva. Mindezt azért, hogy meg kelljen küzdenie a látogatónak az azonosításért, vagyis érted. Ne add könnyen magad! Mindennek legyen valami szokatlan helye, a navigáció egy labirintusra hasonlítson. A legjobb, ha új technikákkal kísérleteztek, valami designcsodát hoztok létre, ahol minden úgy siklik és mozdul, ahogy senki sem várná. Például egy bénán összerakott parallax designnál nincs kegyetlenebb. A kulcsszó: eredetiség!

4. Az atombomba: a zenélő weboldal

Zenét a látogatónak, hangot, fényeket, hadd szóljon az a site! Leállíthatatlanul: tehát semmiképpen ne legyen rajta, vagy ne legyen megtalálható a kikapcsolás lehetősége. Reméljük nem kell magyarázni, miért ez számít a weboldalak atombombájának. Sajnos az eredeti technika kezd kiszorulni, egyre kevesebben bátrak, de azért léteznek ennek modernebb variánsai, ilyen például az automatikusan induló videó. Igazi pusztító, amikor valakinél fel van tekerve a hangerő, és a Te videódat, zenédet kénytelen hallgatni végig, amíg ott van az oldaladon. Nem is fog sokáig maradni, Te pedig fellélegezhetsz.

5. Variálj 4-5 féle betűtípust, lehetőleg különböző színekben és méretben!

Ha mindezek már adottak, akkor további fegyverekhez kell nyúlnod a látogatók elriasztására. Az egyik például az, hogy mindenféle konzisztencia nélkül, többféle betűtípust használsz az oldalon. A többféle szín, méret csak még hatékonyabbá teszi ezt a változatosságot. Lendületes, izgalmas és kreatív lett az oldalad, igaz? Gyors lesz a látogatók távozása is. És ezt a menekülést lehet tovább gyorsítani, csak megfelelő hátteret kell választani a szöveghez, például, hogy alig legyen kontrasztkülönbség, vagy pedig egy erős háttérszínre írod rá a színes szöveget. Lehetőleg kellően apró betűkkel.

6. Használj erőszakos, bezárhatatlan pop-up ablakokat!

Az a legjobb, ami mindjárt az oldaladra érkezés után felnyílik, a kijelző közepén elhelyezkedve betölti a teljes képernyőt, és sehogy sem lehet megtalálni a kis X ikont vagy bezárás feliratot, mert nem a jobb felső sarokba helyezed, hanem valami eldugott helyre. Csak ügyesen! Simuljon bele a designba, és egy meglepő helyen telepedjen meg. Nagy sikere lesz. Ez a technika bannerrel is működik.

7. A call to action gombod legyen láthatatlan

Nincs annál szofisztikáltabb kiszúrás a látogatóval, mint amikor végigolvassa a szerencsétlen a szövegedet, majd kifolyik a szeme, közben szól a zene, ennek ellenére rendelni akar tőled, fel akar iratkozni, viszont Te apróbetűsen, szürkén, láthatatlanul helyezed el a call to action gombot. Azaz, ha akarja, akkor se tud rendelni, vagy bármit mozdulni előre, mert egyszerűen nem találja, hogy ezt hol teheti meg. Sem fent nincs, sem lent, valahol középen a szövegben lehet, vagy talán egy kép, esetleg alatta a link? Merthogy minek is rendelje meg? Csak a macera van vele.

8. A formjaidban még a látogató macskájának nevét is kérdezd meg!

De, ha mégis megtalálja a láthatatlan linkedet és feldobod neki a formot, akkor már csak egy lehetőséged marad: legyen végtelenül hosszú, több oldalon, több kattintással kitölthető. Csak így van esélyed arra, hogy valaki a felénél megunja, és inkább egy másik oldalon szerezze meg ugyanazt, amit nálad akart. Lehetőleg minden apró részletet bele kelljen írnia, hosszasan kígyózzanak lefelé a kitöltendő mezők, és egymás után az oldalak a folyamatban.

És még egy aljas trükk a végére, amit, ha minden kötél szakad, még bevethetsz: ha valaki ki is töltötte, és lenyomja az OK-t, akkor küldj egy hibaüzenetet, mert kihagyott egy mezőt, amit Te gondosan úgy helyeztél el, hogy ne vegye észre. Viszont ekkor töröld ki az összes válaszát, hogy újra ki kelljen tölteni az egészet. Ezt szeretni fogják, hidd el!

Te melyik riasztót építetted már be a weboldaladba?

The post 8 tipp: hogyan kergessük el látogatóinkat a weboldalunkról? appeared first on Webshark Blog.

Ennek a megoldásnak van jó és rossz oldala is. SEO szempontjából egész jó módszer, hiszen sok hivatkozás mutat majd így az oldalunkra, valamint az így megosztott tartalmat nem lesz nehéz felkeresnie az érdeklődőknek.

Azonban ez a módszer sok esetben bosszantó is lehet, például ha sokszor másulunk egy adott oldalról, ahol alkalmazzák ezt a megoldást. Véleményem szerint a legnagyobb probléma, hogy a felhasználó nem tudja, hogy a kimásolt szöveget más formában kapja vissza, hiszen nem ez a megszokott megoldás.

A módszer használata, mint oly sok dolog számos tényezőtől függ és nekünk kell eldöntenünk, hogy használjuk-e, vagy sem.

Megvalósítás

A függvény hívását a dokumentum oncopy eseményéhez kötjük, ami ahogy a neve is utal rá, akkor fut le, ha valaki szöveget másol a dokumentumunkból.

A függvény elején található feltétellel meghatározzuk, hogy csak a content osztály kijelölővel rendelkező elemeinken fusson le a kijelölés, ami ebben az esetben a tényleges szöveges tartalom.

Az if-ben található window.getSelection()-el visszakapjuk a kijelölt objektumot, a containsNode-al pedig ellenőrizzük, hogy a kijelölés a content class-al ellátott területen belül található-e.

Ezt követően létrehozzuk a kijelöléshez hozzákapcsolandó szöveget, amit aztán egybefűzünk a kijelölés szövegével. Mivel a kijelölésünket, csak úgy tudjuk módosítani, hogy egy meglévő elemmel és annak tartalmával lecseréljük az aktuális kijelölést, létre kell hoznunk egy új HTML elemet amibe innerHTML-el beillesztjük az új szövegünket. Ezt az elemet a kijelölés frissítése után töröljük!

WordPress

WordPress esetében a fenti kódot functions.php-n vagy egyedi bővítményen keresztül is beilleszthetjük. Ehhez használjuk a wp_head akció hook-ot, az alábbi módon!

Összefoglalás

Főként a rendszerünkön múlik, hogy milyen hivatkozást állítunk elő. Ha a sablonfájl fejlécében helyezzük el a kódot, úgy könnyedén adhatjuk hozzá a CMS-ünk által nyújtott, a megfelelő hivatkozás lekérdezésére szolgáló függvényeket.

The post Olvass tovább link hozzáadása az oldaladról kimásolt szöveghez appeared first on Webshark Blog.