# Blog – fps ecosystem agency
> Az fps ecosystem agency blog posztjai.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About this site
URL: https://blog.fps.hu/about/
Last updated: 2026-07-30T16:37:43.000Z
fps blog is an independent publication launched in July 2026 by kolboid. If you subscribe today, you'll get full access to the website as well as email newsletters about new content when it's available. Your subscription makes this site possible, and allows fps blog to continue to exist. Thank you!

### Access all areas

By signing up, you'll get access to the full archive of everything that's been published before and everything that's still to come. Your very own private library.

### Fresh content, delivered

Stay up to date with new content sent straight to your inbox! No more worrying about whether you missed something because of a pesky algorithm or news feed.

### Meet people like you

Join a community of other subscribers who share the same interests.

---

### Start your own thing

Enjoying the experience? Get started for free and set up your very own subscription business using [Ghost](https://ghost.org/?ref=blog.fps.hu), the same platform that powers this website.
## Posts
### fpsesek a UX Budapest podcastban
URL: https://blog.fps.hu/fpsesek-a-ux-budapest-podcastban-interju/
Last updated: 2026-08-24T10:41:24.000Z
Jártunk a **UX Budapest** podcastban.

Dutka mester és kolboid képviselte az fps ecosystemet egy jó hangulatú beszélgetésben, ahol több mint 20 év UX tapasztalatáról, a szakmáról, a szemléletünkről, a mindenapi életünkről meséltünk.

Hallgasd meg Youtube-on:

Vagy ha neked úgy jobb, akkor hallgasd Spotify-on:
### Rábíztam egy UX elemzést az AI-ra. Mi lett belőle?
URL: https://blog.fps.hu/kivaltja-az-ai-a-ux-designert-kiprobaltam-egy-egyszeru-feladaton/
Last updated: 2026-07-21T13:21:55.000Z
Kaptam egy önmagában nem túl bonyolult feladatot: egy portál keresési, találati és adatlap oldalaira kellett UX expert review-t készítenem. Rendelkezésre állt hozzá egy kérdéssor a célközönségről, a célokról és az USP-ről, egy iparági kutatási anyag, illetve Google Analytics és Clarity hozzáférés.

A kiinduló hipotézisem az volt (amit egyre több helyen olvasni), hogy ilyesmire az AI ma már bőven elég jó. Nem kell vele sokat foglalkozni, a designernek legfeljebb át kell néznie az eredményt, ilyen témákban gyakorlatilag kiváltja az embert. Mivel épp jött egy ilyen feladat, gondoltam, megnézem, tényleg így van-e.

## A teszt

Két modellel dolgoztam párhuzamosan: **Claude Fable 5** és **ChatGPT-5.6 Sol**, természetesen előfizetéssel. Mindkettőnek beadtam inputként mindent, amit kaptam: briefet, a kérdés-válaszokat, a kutatási anyagot, a GA exportokat, a Clarity heatmapeket, attention mapeket és scroll mapeket, valamint a szükséges URL-eket. A feladat pontosan meg volt határozva: készítsenek egy UX expert review dokumentumot, konkrét céllal.

Fontos, hogy nem egyetlen prompttal dolgoztam, hanem strukturáltan, több lépésben bontottam a feladatot, és arra kértem, hogy a megállapításait lehetőleg a GA és Clarity adatokkal támassza alá, ne csak feltételezzen. Vagyis nem a „mindent bele egy promptba" megközelítést teszteltem, hanem azt, amit egy tudatos munkafolyamatból ki lehet hozni.

És természetesen párhuzamosan én is végigcsináltam az elemzést kézzel (mint az állatok), hogy legyen mihez hasonlítani.

## Amit tapasztaltam

Előre bocsátom: ez egy tapasztalati beszámoló, nem kontrollált kísérlet. Egyetlen projekt, egyetlen szakértő (jómagam), és a saját elemzésem sem abszolút mérce. Az alábbiakat ennek fényében érdemes olvasni.

Mindkét modell összerakott egy elemzést, de bőven volt bennük irreleváns, sőt nem is valós probléma. Voltak hasznos meglátások is, de azokat is inkább csak szövegi és strukturális szinten tudtam beépíteni. A Claude érezhetően pontosabb volt a ChatGPT-nél, legalábbis szövegezésben és struktúrában, de ez az én szubjektív benyomásom, nem kontrollált mérés. Egy különbség objektív volt, mégpedig hogy a Claude egyetlen dokumentumban elő tudta állítani az eredményt, a ChatGPT csak részben, ez viszont inkább kimeneti formátum kérdése, nem elemzési minőségé.

El kell ismerni: akadt olyan probléma, amit én nem vettem észre, és ez hasznos volt. De több olyan is volt, amit viszont az AI nem vett észre.

Ez egyébként egészen jól rímel egy 2025-ös kutatásra, amely a GPT-4o-t Nielsen usability heurisztikái alapján tesztelte:

> A GPT-4o a szakértők által azonosított usability problémák nagyjából ötödét (21%) találta meg, ugyanakkor több új, részben téves problémát is felvetett. Ezért kiváló első UX review eszköz, de önmagában még nem helyettesíti a szakértői értékelést.

[Can GPT-4o Evaluate Usability Like Human Experts? (2025)](https://arxiv.org/abs/2506.16345?ref=blog.fps.hu)

Ennél a Nielsen-féle usability heurisztikáknál valamivel komplexebb projektnél lényegében ugyanezt tapasztaltam.

## Hogyan állt össze végül az anyag

Az elemzést a végén a Claude-dal közösen tettem össze. Beadtam neki a saját meglátásaimat, és folyamatos beszélgetésben alakítottuk, mit vegyen ki és mit tegyen be. Átnézte nyelvhelyesség, következetesség és hasonló szempontok szerint, és javasolt módosításokat. Ez a rész iszonyatosan hasznos volt.

Az időt nem mértem pontosan, de érzésre: ha mindent egyedül csinálok, az összességében nagyjából 15%-kal több időbe telt volna.

Szóval az AI szuper társ és segítő partner, amivel gyorsítom és pontosítom a munkámat, de jelenleg nem képes kiváltani. Továbbra is erős partner, és együtt jobbak vagyunk, mint valaha.

![ai-human-handshake.jpg](https://blog.fps.hu/content/images/2026/07/ai-human-handshake.jpg)

Felmerülhet, hogy talán egy böngészős walk-through jobb lett volna: ma már van rá mód és eszköz, hogy a modellek élőben, böngészőben járják végig az oldalt, ne csak a statikus adatokból és URL-ekből dolgozzanak. Nem tudom biztosan, mert nem futtattam, de erős a gyanúm, hogy ez sem vezetett volna jobb eredményre, mert a lényegi korlát nem a hozzáférés, hanem az ítélőképesség, vagyis a kontextus és a célok megértése, a súlyozás, a valós probléma és a zaj elválasztása.

Amit viszont tényleg kipróbálok legközelebb, az egy saját agent skill erre a feladatra. Ebbe a bevált usability heurisztikákat, a szakmai tapasztalattal kialakult súlyozást és azt a szakértői nézőpontot kódolom, amivel egy UX-es végignéz egy felületet, majd projektről projektre csiszolom. A tét nem az, hogy helyettem döntsön, hanem hogy a saját szakértői mércém újrahasznosítható, konzisztens formába kerüljön. Ezt fogom legközelebb megnézni.

Ez amúgy egybevág azzal, amit a téma szakirodalmában látni: [a Baymard 95%-os pontosságú AI heurisztikus kiértékelést](https://baymard.com/blog/ai-heuristic-evaluations?ref=blog.fps.hu) nem jobb prompttal ért el, hanem azzal, hogy a modellt a saját, kutatott UX-tudásbázisukra kötötték. Igaz, ez náluk szűken usability heurisztikákról szól, ami jóval egyszerűbb történet, mint egy ilyen komplexebb, kontextusfüggő review, de az elv ugyanaz. A pontosság nem a modellből jön, hanem a beletáplált szakértői keretből. Épp ezért érdemes a saját mércét egy skillbe kódolni.

## És hosszú távon?

Azzal tisztában vagyok, hogy előbb-utóbb ki fogja váltani a munkánkat az AI, ez gyakorlatilag nem kérdés. Az egyetlen kérdés, hogy ez mikor következik be.

Olvastam róla, hogy egyfajta lassulás, megtorpanás jelei mutatkoznak. A [Reuters 2024 végi cikke](https://www.reuters.com/technology/artificial-intelligence/openai-rivals-seek-new-path-smarter-ai-current-methods-hit-limitations-2024-11-11/?ref=blog.fps.hu) szerint több vezető AI-kutató, köztük Ilya Sutskever, arról beszél, hogy a modellek előtanításának (pretraining) puszta felskálázása elérte a határait. A további előrelépést egyre inkább új megközelítések hozzák, például az „o1"-féle, lépésről lépésre gondolkodó modellek, nem a nagyobb méret. Vagyis a fejlődés nem állt meg, de a hangsúly a mérettől az okosabb módszerek felé tolódik.

Persze a háttérben folyamatosan zajlanak más és más fejlesztések, kutatások, úgyhogy nem kérdés, hogy az AI hosszú távon totális teret nyer.

Nemrég futottam bele egy oldalba, amely szerint még van pár jó évünk, különösen a kutatás és a komplex tervezés területén, ahol mindenütt használjuk az AI különböző modelljeit, hiszen gyorsítják, pontosítják és segítik a munkát.  
**[Nézd meg, a te munkádat mikor váltja ki az AI](https://doomsdate.app/?ref=blog.fps.hu)**!

Amíg pedig itt tartunk, én modellenként váltogatom, melyiket mire használom, szóval ne felejtsd el, hogy minden LLM másra és másra jó.  
**[Nézd át ezt a 2026-os LLM Compass-t](https://work2flow.ai/llm-compass/?ref=blog.fps.hu)**!

![ai-passes-pen-to-human.jpg](https://blog.fps.hu/content/images/2026/07/ai-passes-pen-to-human.jpg)

## Mit csinálj holnaptól?

**Kezdd el**: használd az AI-t első körös partnerként, etesd meg a valós adataiddal, dolgozz lépésekben, és kódold a saját heurisztikáidat és súlyozásodat egy újrahasznosítható promptba vagy skillbe.

**Hagyd abba**: ne közöld az AI kimenetét változtatás nélkül, ne várd, hogy egyetlen prompt kiváltson egy egész munkafolyamatot, és ne add ki a kezedből az ítéletet. A súlyozás, a priorizálás és az üzleti kontextus a tiéd marad.

És ne ess pánikba, hogy holnap elveszi a munkádat (még :D). Nem veszi, de aki megtanulja irányítani, az lehagyja azt, aki nem.
### Bonyolult problémától a letisztult termékig
URL: https://blog.fps.hu/bonyolult-problematol-a-letisztult-termekig/
Last updated: 2026-07-17T08:16:54.000Z
**Az egyszerűség anatómiája egy hitelválasztó terméken keresztül**

A hitelfelvétel sok ember számára nem csak pénzügyi döntés, hanem érzelmi teher is. A rengeteg termék, a hosszú leírások és az ismeretlen fogalmak mellett ott van a végén a kérdés: biztos, hogy jó döntést hozok?

Ebben az esettanulmányban azt mutatjuk be, hogyan jutottunk el egy komplex banki problémától egy letisztult, edukatív digitális termékig az Erste hitelkampányához kapcsolódva.

## A feladat

Az ügyfelünk, az Erste egy több csatornán futó kampányt tervezett hiteltermékei támogatására. A kampány egyik központi eleme egy új weboldal volt, ahová a kommunikáció terelte volna az érdeklődőket.

Ennek az oldalnak egyszerre több fontos feladata volt:

- érthetően bemutatni a különböző hiteltermékeket,
- segíteni a felhasználót a számára megfelelő megoldás kiválasztásában,
- lehetőséget adni előzetes kalkulációra,
- és támogatni a hiteligénylés elindítását.

Mindezt úgy kellett megvalósítani, hogy a folyamat egyszerű, átlátható és könnyen követhető maradjon még azok számára is, akik nem jártasak a pénzügyi termékek világában.

Emellett fontos szempont volt az edukáció is: a felületnek nemcsak információt kellett adnia, hanem segítenie kellett a felhasználót abban is, hogy magabiztosabban tudjon dönteni.

## A probléma

A hiteltermékek világa alapvetően összetett: sokféle konstrukció létezik, különböző célokra, eltérő feltételekkel. Futamidő, THM, igénylési szabályok – ezek mind változnak termékről termékre, ami már önmagában is megnehezíti az eligazodást.

Ehhez jön, hogy egyetlen termék esetében is jelentős mennyiségű információt kell átadni. Amikor pedig több lehetőséget kell összehasonlítani, ez az információmennyiség gyorsan túlterhelővé válik. A felhasználók ilyenkor könnyen elvesznek a részletekben, és végül nem látják a valódi különbségeket az egyes lehetőségek között.

A helyzetet tovább nehezíti, hogy a célközönség jelentős része nem rendelkezik mélyebb pénzügyi ismeretekkel. Sok esetben még az alapfogalmak sem egyértelműek, így a döntés nemcsak bonyolult, hanem bizonytalan is.

Ráadásul a felhasználók gyakran nem tudják pontosan, melyik hiteltípus illik hozzájuk. Nemcsak a lehetőségek közül kell választaniuk, hanem azt is fel kellene mérniük, hogy egy adott konstrukció mennyire passzol az élethelyzetükhöz és a szokásaikhoz.

Mindezek mellett a hitelfelvétel sokak számára egy komoly, nagy súlyú döntés. Ez természetes módon stresszt is hoz magával, ami tovább nehezíti az átgondolt választást.

## A kutatás

Első lépésként egy **best practice kutatással** feltérképeztük a piacon elérhető megoldásokat. Azt láttuk, hogy bár számos hitelösszehasonlító oldal létezik, ezek valójában nem segítik érdemben a döntést. Többnyire csak különböző pénzintézetek adott hiteltípusra vonatkozó ajánlatait hasonlítják össze, de nem segítenek abban, hogy milyen hitelt válasszak magamnak. Sem a magyar piacon, sem pedig nemzetközi szinten nem találtunk megoldást.

Ugyanakkor találtunk egy teljesen más területről érkező megoldást, ami inspiráló volt számunkra, a randiapp-ot, a Tindert: az egyszerű, gyors döntésekre épülő, intuitív működés, ami sokak számára ismerős digitális élmény volt.

![](https://blog.fps.hu/content/images/2026/05/hitelvalaszto-ui-design.png)

  
A kvalitatív kutatás során olyan szakemberekkel **interjúztunk**, akik napi szinten menedzselik és vesznek részt hiteligénylési folyamatokban és közvetlen kapcsolatban állnak a célközönséggel, például **banki tanácsadókkal** és **termékmenedzserekkel**. Interjúztunk **felhasználókkal**, akik éppen hitelt vettek fel vagy a közeljövőben tervezik azt. Az interjúk feldolgozásában AI-támogatott eszközöket használtunk (Dovetail, tl;dv), amelyek segítettek gyorsan átlátni a visszatérő mintákat és kiemelni a legfontosabb megállapításokat.

**Másodlagos kutatással** kinyertük a felhasználói döntési helyzetekre vonatkozó információkat korábbi, az Erste számára készült mélyinterjús kutatásainkból. **Netnográfiai kutatással** és az ügyfélszolgálatra érkező **panaszok elemzésével** tártuk fel a célközönség igényeit és fájdalompontjait.

Végül pedig a hiteltermékek feltételeinek feldolgozásában szintén AI-t használtunk: Gemini segítségével tudtuk kigyűjteni és rendszerezni azokat a jellemzőket, amelyek valóban számítanak a választás során.

## Az ötlet

A kutatás során világossá vált számunkra, hogy a legtöbb meglévő megoldás arra épít, hogy a felhasználó képes különböző hiteltermékeket részletesen összehasonlítani.

A valóságban azonban ez ritkán működik így.

A legtöbb ember nem termékeket akar elemezni, sőt nagyrészt a termékeket sem ismerik, nem tudnak a létezésükről sem. Az emberek egyszerűen azt szeretnék tudni:

**mi a jó döntés az ő számukra**.

Ezért a folyamatot nem a termékek bemutatásával kezdtük, hanem a felhasználóval.

A kutatásból az derült ki, hogy hitelfelvételkor a felhasználók rengeteg termékkel és információval találják szembe magukat, amit nehéz átlátni és feldolgozni. Ez sokakat elbizonytalanít: vagy feladják, vagy banki tanácsadóhoz fordulnak. Ezt a jelenséget házon belül „komplexitásproblémának” neveztük.

Ezért a megoldásunk lényege az lett, hogy az információkat fokozatosan, lépésről lépésre adagoljuk, és végigvezetjük a felhasználót a folyamaton – így elkerülhető az információs túlterhelés.

Első lépésként egy **rövid, néhány kérdésből álló folyamattal** kezdtünk, amely segít megérteni az igényeit és a helyzetét. Ebben a szakaszban tudatosan kerüljük a szakzsargont és a részletes pénzügyi adatokat – csak annyi információ jelenik meg, amennyi az adott döntési ponthoz szükséges.

Ahol elkerülhetetlen, a rendszer közérthetően magyarázza el az alapfogalmakat, így az edukáció már a folyamat elejétől megjelenik. Ez különösen fontos az Erstének is, mert az Erste küldetésének fókuszában a „financial health” áll. Az edukáció minden esetben kontextushoz kötötten, a szükséges minimumra szorítva történik, hogy ne terhelje túl a felhasználót.

A válaszok alapján a rendszer szűkíti a lehetőségeket, és eredményként egyértelmű ajánlást ad:

- mely hiteltermékek a megfelelőek, melyeket ajánljuk,
- melyek jöhetnek még szóba,
- és melyeket nem ajánljuk.

Ezt követően a felhasználó egy már **szűrt, átlátható listát** kap, rövid leírásokkal és opcionálisan elérhető részletes információkkal.

A folyamat végén egy kalkulátor segíti a konkrét döntést, és innen akár az **online igénylés is elindítható**.

## A csavar

A koncepció első verzióját gyorsan prototípussá alakítottuk, és bemutattuk az ügyfélnek.

![](https://blog.fps.hu/content/images/2026/05/hitelvalaszto-wireframes.jpg)

  
A döntési logika mögött rendkívül sok elágazás és feltétel állt, amit ebben a formában nehéz volt átlátni és a jövőben kezelni a változásokat. A hiteltermékek kondíciói gyakran változnak, sőt a tapasztalatok szerint új hiteltermékek jelennek meg és vannak, amelyek egyszerűen megszűnnek. 

Világossá vált, hogy ebben a projektben nem egy, hanem **két célcsoportunk** van:

- Az egyik a végfelhasználó, aki egy egyszerű élményt kap.
- A másik maga az ügyfél – azok a szakemberek, akiknek ezt a rendszert fel kell építeniük és karban kell tartaniuk.

Ezért egy olyan háttérmegoldás felé indultunk el, amely nemcsak jól használható, hanem strukturáltan kezelhető is.

Egy rendszert képzeltünk el, amely képes a komplex döntési logikát átlátható formában kezelni, és akár automatikusan tesztelhető folyamattá alakítani – így a teljes működés nemcsak megtervezhető, hanem folyamatosan ellenőrizhető és fejleszthető is.

## A megoldás

A végső megoldás egy két szinten működő rendszer lett.

A felhasználó oldalán egy egyszerű, vezetett folyamat jelenik meg, amely kérdéseken keresztül segíti a döntést, majd egy szűrt, releváns terméklistát és kalkulációs lehetőséget kínál.

A háttérben azonban egy strukturált logika működik, amely képes kezelni a különböző termékek feltételeit, az ezekhez tartozó szabályrendszert, valamint az ezekből következő ajánlásokat.

![](https://blog.fps.hu/content/images/2026/05/hitelvalaszto-editor.png)

  
A megoldás nem egy egyszeri tervezési folyamat eredménye volt, hanem egy több hónapon át tartó, szoros együttműködés az ügyféllel. A koncepciót folyamatosan iteráltuk: újabb és újabb prototípusokat készítettünk, amelyeket rapid tesztekkel validáltunk, és ezek eredményei alapján finomítottuk tovább a rendszert. 

Ez a megközelítés végül lehetővé tette, hogy:

- a rendszer könnyen frissíthető legyen új termékekkel,
- több szakértő párhuzamosan dolgozhasson rajta,
- és a teljes folyamat egyszerűen tesztelhető maradjon.

## Az eredmény

Az eredmény egy olyan digitális termék, amely jelentősen leegyszerűsíti a hitelválasztás folyamatát. A felhasználók nem egy nehezen átlátható termékhalmazzal találkoznak, hanem egy vezetett úton haladnak végig, ahol mindig csak a következő döntéshez szükséges információ jelenik meg. Ez nemcsak érthetőbbé teszi a folyamatot, hanem segít abban is, hogy magabiztosabb döntések szülessenek.

![](https://blog.fps.hu/content/images/2026/05/hitelvalaszto-final.png)

  
Az ügyfél oldalán egy jól strukturált, szabályalapú rendszer jött létre, amely képes kezelni a különböző hiteltermékek feltételeit és az ezekhez tartozó döntési logikát. A megoldás rugalmasan frissíthető, új termékekkel bővíthető, és több szakértő együttműködésével is hatékonyan karbantartható. Az end-to-end mérések alapján a végtermék kiemelkedő konverziót ért el, ami egyértelműen visszaigazolta a megközelítés működőképességét. 

A projektet az ügyfél kifejezetten pozitívan értékelte, különösen a megoldás egyszerűsége és átláthatósága miatt. Számunkra pedig ez egy olyan munka volt, amire kifejezetten büszkék vagyunk: sikerült egy komplex problémát úgy leegyszerűsíteni, hogy az valódi értéket teremt mind a felhasználók, mind az üzleti oldal számára.

## A tanulság

A projekt során az egyik legfontosabb felismerésünk az volt, hogy bár az AI rengeteg ponton hatékonyan tudja támogatni a munkát, nem jelent minden problémára kész megoldást.

Kifejezetten célunk volt, hogy az ajánlási logikában is nagy szerepet kapjon. A gyakorlatban azonban hamar kiderült, hogy egy pénzügyi termékekkel dolgozó rendszer esetében ez komoly korlátokba ütközik:

- Az AI által generált ajánlások nem voltak kellően megbízhatóak. Előfordult, hogy pontatlan vagy következetlen eredményeket adott, és ugyanazokra a bemenetekre sem mindig ugyanazt a javaslatot fogalmazta meg. Egy ilyen típusú rendszerben, ahol a döntések pénzügyi következményekkel járnak, ez nem elfogadható.
- Emellett az üzleti szempontok érvényesítése sem volt megfelelően kontrollálható. Nem lehetett biztosítani például azt, hogy bizonyos termékek milyen sorrendben vagy milyen feltételek mellett jelenjenek meg az ajánlásokban.
- Jogilag és működési szempontból is kockázatos lett volna egy ilyen megoldás: nem volt teljes mértékben visszakövethető, hogy egy adott ajánlás hogyan született, ami problémát jelenthet egy esetleges ügyfélpanasz vagy vitás helyzet esetén.
- További kihívást jelentett az is, hogy a működés egy külső szolgáltatótól függött volna, ami az üzembiztonság és a költségek szempontjából is bizonytalanságot hozott.

Mindezek alapján végül egy olyan irányba mentünk tovább, ahol az AI-t támogató eszközként használjuk – például kutatásban, elemzésben és információfeldolgozásban –, de a kritikus döntési logikát egy jól kontrollálható, szabályalapú rendszer kezeli.

A projekt legfontosabb tanulsága számunkra az volt, hogy egy jó digitális megoldás nemcsak a végfelhasználók számára kell, hogy működjön, hanem az ügyfelünk számára is: üzleti, jogi és működési szempontból is stabil alapokon kell állnia.

És talán még ennél is fontosabb: a felhasználók nem több információt szeretnének, hanem több magabiztosságot a döntéseikben. Ezt pedig egy jól felépített, vezetett folyamat sokkal hatékonyabban tudja támogatni, mint bármilyen technológiai varázslat.

[Próbáld ki a hitelválasztót!](https://hitelvalaszto.erstebank.hu/igenyfelmero/?ref=blog.fps.hu)
### Hatékony UX Research = Stakeholder Experience Design
URL: https://blog.fps.hu/hatekony-ux-research-stakeholder-experience-design/
Last updated: 2026-07-17T08:17:06.000Z
UX kutatóként valószínűleg nagyon a karriered elején jársz, esetleg baromi mázlista vagy a céged design érettsége terén, ha még egyszer sem élted át az alábbiakat:

1. Szívedet-lelkedet beleadtad egy kutatási riportba, csak azért,
2. …hogy aztán a kutya se törődjön vele.

Ott hever a riportod, elveszve az üzenetek tengerében. Csendben és magányosan, elhanyagolva a döntéshozók által, akik soha meg sem nyitották. Ekkor úgy érzed magad, mint egy meg nem értett művész, vagy elkezdesz a marxi-elidegendésről olvasni, esetleg karrierváltáson gondolkodni… De van megoldás.

### Disclaimer: Ezek nem az én gondolataim (bárcsak azok lennének)

*Minden [Nikki Anderson](https://www.nikkiandersonux.com/?ref=blog.fps.hu)\-tól származik, aki a [UXCON Vienna 2024](https://www.uxcon.io/?ref=blog.fps.hu)\-en tartott előadást*, ahol az ő nyers őszintesége rávett, hogy végül ne a „UX kutatás VR-ban” témáról írjak.

Nikki évekig küzdött azokban a szerepekben, amelyeket mindannyian túl jól ismerünk, és megvannak a „harci sérülései” is, hogy ezt bizonyítsa.

A karrierje elején rendszeresen leüvöltötte a munkatársait. Gyakran zengett a tárgyaló:

> „Ez az egész a felhasználókról kellene hogy szóljon!!!4”

– meséli, majd nevetve hozzáteszi:

> „Nem igazán léptettek elő… Csak áthajigáltam az insight-okat a kerítésen.”

**Aztán valami megváltozott.**

Az előadásának végén megosztotta, hogyan fejlődött az ő hozzáállása addig, hogy:

> „Amikor elkezdtem **így beszélni,** hirtelen elkezdtek sokasodni a meetingjeimen.”

Ha kíváncsi vagy mit is értünk **„így beszélni**” alatt, és hogy lehet beletanulni közgaszdász PhD nélkül, tarts velem.

## Kik a kutatók felhasználói?

A fő felhasználóink nem azok a végfelhasználók, akiket olyan szenvedélyesen képviselünk.  
**Az igazi felhasználóink azok a fránya stakeholderek** – ugyanazok, akik eltűnnek az e-maileink elől, és úgy kezelik a gondosan összeállított jelentéseinket, mintha valami 99 oldalas nyűg lenne.

Mi meg verjük a design empátia harci dobjait, küzdünk a felhasználó hangjáért, és közben elfelejtjük, hogy azok az emberek, akik olvassák a jelentéseinket szintén felhasználók!

Ha ők **„nem értik”,** az elsősorban a mi hibánk.

## Dilemma a kapitalizmusban: Felhasználói empátia vs. profit margin

Ó, és ne feledjük a kedvenc narratívát: *a harcot a „gonosz” vállalati vezetők és a tiszta, ártatlan felhasználók között.* Imádunk beszélni a felhasználói empátiáról, az emberközpontú designról, és arról, hogy megvédjük a felhasználó érdekeit, mintha valami epikus csatát vívnánk a profitot hajhászó vállalatok ellen.

De ácsi. Ha a nagy, gonosz kapitalista gépezet nem marad nyereséges, mi történik?  
**Nincs termék, nincs szolgáltatás, nincs felhasználó.\***

Ha a vállalat nem keres pénzt, a felhasználónak, akit annyira fontosnak tartasz, semmije se marad abból, amit nyújtani tudunk neki.

*(\* ez az érvelés sántít a techóriásoknál, hiszen ott a felhasználónak lehet, hogy nincs valódi alternatívája. Gondolj mondjuk a Goolge-re vagy a Metára.)*

## Önreflexió: Elbukunk a stakeholdereink előtt?

**Legyünk őszinték:** ha ugyanolyan empátiával lennénk a stakeholdereink felé, mint a felhasználók iránt, vajon figyelmen kívül hagynák a kutatásainkat? Ha mi tervezők vagyunk, akkor **miért nem alkalmazzuk a design alapelveit a saját leszállítandóinkra?**

Itt az ideje újragondolni a megközelítésünket. Le kell állnunk azzal, hogy arra várjunk, hogy a stakeholderek jöjjenek hozzánk a mi feltételeink szerint. Helyette kezdjünk el az ő nyelvükön beszélni.

Ahogy Judd Antin is rámutatott, *a UX research szakma válságban van (talán emlékszel mekkora balhé volt az írásából pár éve: [The UXR Reckoning is here?](https://medium.com/onebigthought/the-ux-research-reckoning-is-here-c63710ea4084?ref=blog.fps.hu)).* Kevesebb nyitott UX pozíció (-70% csökkenés 2021 és 2022 között), nagyobb szkepticizmus a vezetőség részéről, és egyre nagyobb nyomás, hogy bizonyítsuk relevanciánkat.

## Hogyan tedd fontossá a kutatásaidat?

Ha azt szeretnéd, hogy a kutatásaid **ne porosodjanak**, hanem **valódi hatást érjenek el**, akkor itt az idő, hogy megismerkedj a *Three C's Frameworkkel.*

Nézzük meg, hogyan használhatod ezeket annak érdekében, hogy a kutatásod ne csak informáljon, hanem transzformáljon is.

A három C keretrendszer dióhéjban:

1. **Context**: Állítsd be az insight-jaidat a nagyobb üzleti probléma kontextusában!  
Mi az a probléma, amit a vállalat meg akar oldani, és hogyan járul hozzá a kutatásod ennek megoldásához?
2. **Connection**: Kapcsold össze egyértelműen a kutatási insightokat a vállalat üzleti céljaival (pl. bevétel, költségcsökkentés, felhasználói elégedettség)!  
Fordítsd le a kutatásodat üzleti hatásra.
3. **Consequence**: Mutasd be az inaktivitás költségeit!  
Mi történik, ha a vállalat nem cselekszik a megállapításaid alapján? Számítsd ki a kihagyott lehetőségeket vagy kockázatokat.

Példákkal kiegészítve:

### 1\. Kontextus (Context)

**Állítsd be az insight-jaidat egy nagyobb üzleti probléma keretében!** Mit próbál megoldani a vállalat, és hogyan segíti a kutatásod ezt? Szoktad olvasgatni a negyedéves jelentéseket? Lehet itt az ideje.

*Például: „Ahogy a 20%-os online értékesítési növekedést célozzuk meg ebben a negyedévben, a felhasználók checkout közbeni zavarodottsága jelentős akadály.”*

### 2\. Kapcsolódás (Connection)

Most **tedd személyessé**! Hogyan kapcsolódnak a megállapításaid közvetlenül az üzleti célokhoz?

*Például: „A checkout folyamat egyszerűsítése 30%-kal csökkentheti a kosárelhagyást, ami évente potenciálisan 6 millió dollárnyi elveszett bevétel visszaszerzését jelentheti.”*

### 3\. Konzekvencia (Consequence)

És itt jön a lényeg: **mi történik, ha nem cselekednek a kutatásod alapján?** Mutasd meg a kockázatokat!

*Például: „Ha ezt a problémát nem kezeljük, havi 500 ezer dollárt veszítünk az elhagyott kosarak miatt, miközben a versenytársaink már gördülékenyebb checkout élményt kínálnak.”*

![Kérdezd meg a stakeholdereidet, melyik hangzik jobban](https://blog.fps.hu/content/images/2024/10/-3C-keretrendszer-egy-peldaban-1.png)

## Oké, de nem én vagyok a ROI-s biznisz ember a csapatban…

Ha te is olyan vagy, mint a legtöbb UX kutató, akkor a megtérülési ráta (ROI) kiszámítása hallatán legszívesebben elszaladnál. De a kutatásod kvantifikálása nem kellene, hogy félelmetes feladat legyen. Egyszerű képletek vannak arra, hogy megbecsüld, majd megmutasd, milyen valódi üzleti hatása van a munkádnak. Nézzük meg lépésről lépésre!

### Költségmegtakarítás a hibák korai javítással

##### *(Cost Savings from Reduced Rework)*

**Vegyük az időben felfedezett hibák számát, szorozzuk meg az átlagos javítási idővel, az alkalmazottak órabérével és az érintett dolgozók számával.**

**Képlet**:  
*(felfedezett hibák száma) \* (átlagos javítási idő) \* (órabér) \* (érintett dolgozók száma)*

**Példa**: *50 hiba időben történő felfedezése, amelyeket egyenként 2 órába telt javítani, összesen 25 000 dollár megtakarítást eredményezett a termék élővé tétele előtt.*

### Bevételnövekedés a megtartás javításával

##### *(Revenue Increase from Improved Retention)*

**A felhasználói megtartás javítása közvetlenül hat a bevételre.** Ha növeled a megtartási arányt, és megszorzod azt az éves ügyfélértékkel, valamint az ügyfelek számával, látni fogod, hogy mennyi további bevételt generálhatsz.

**Képlet**:  
*(megtartási arány növekedése) \* (éves ügyfélérték) \* (ügyfelek száma)*

**Példa**:  
*A megtartás 10%-os javulása, amikor minden ügyfél évente 1 000 dollárt hoz, évi 1 millió dollár további bevételt jelentett 10 000 ügyfél esetén.*

### Költségmegtakarítás az ügyfélszolgálati jegyek csökkentésével

##### *(Cost Savings from Reduced Customer Support)*

**Az ügyfélszolgálati jegyek csökkentése időt és pénzt takarít meg.** Ezt úgy számolhatod ki, ha megszorzod a csökkentett jegyek számát, az egy jegy megoldásához szükséges időt, az ügyfélszolgálati ügynökök órabérét, és az ügynökök számát.

**Képlet**:  
*(csökkentett tiketek száma) \* (átlag idő tiketenként) \* (supportos órabére) × (supportosok száma)*

**Példa**:  
*Havi 400 tiket csökkentése 30 000 dollár megtakarítást eredményezett az ügyfélszolgálati költségekben, miközben minden jegy megoldása 15 percet vett igénybe.*

Ehhez nem kell közgázból PhD, csak egy Google táblázat és néhány extra kérdés a stakeholderektől.

## Kutatás-alapúvá válni, nem kutatásba temetkezni

**A UX kutatók útja nem könnyű.** De ha azt akarjuk, hogy komolyan vegyenek minket és relevánsak maradjunk, **többet kell tennünk, mint a felhasználókért való lobbizás.**

**Magunkért is lobbiznunk kell** azzal, hogy **megfogalmazzuk munkánk üzleti értékét, összehangoljuk insight-jainkat az üzleti célokkal, és mindent a nagyobb stratégia kontextusában mutatunk be.**

Mert a nap végén, **ha a munkánknak nincs hatása, a cég nem lesz ott, hogy törődjön a felhasználókkal vagy velünk.**

> „Tudom. A felhasználók fontosak… a vállalatok is… de ez… mindkettőn segít.”

– *Nikki*
### Egy designer gondolatai az AI képalkotásról
URL: https://blog.fps.hu/egy-designer-gondolatai-az-ai-kepalkotasrol/
Last updated: 2026-07-17T08:17:17.000Z
A házimunkák fogorvosi kontrollja a porszívózás. Minden alkalommal utálja az ember, és már előre zavarja, hogy lassan itt az ideje. Annyi a különbség, hogy porszívózni sűrűbben kell, illetve a technika már ad rá alternatívát, nem úgy mint a fogorvosra. Úgy döntöttem pár éve, veszek egy robotporszívót. Egylégterű a lakás, nincsenek magas küszöbök, nincs lépcső…ideális. Pár használat után felmértem mit kell elpakolászni előtte, miket csavar fel és hol akad el rendszeresen meggátolva, hogy magára hagyhassam. Ahogy egyre többet használtam kiderült, helyettesíteni nem tudja a porszívózást. Ha nincs időd, gyors tisztításra megfelelő. Segítség, de nem megoldás. *Valahogy így vagyok az AI kép generálással is.*

A designerek között az AI már több mint egy éve állandó téma. Szinte mindenki ellene van. Előkerül problémaként az anyagok minőségének romlása, a szerzői jogok semmibevétele, a munkák elvesztése, illetve a dilettánsok megjelenése a szakmában. Nem szeretnék nagyokat mondani (van bőven elég szakember, aki megteszi helyettem), inkább kérdések és gondolatok merülnek fel bennem.

### Munkahelyek

A játékiparban már elkezdődött a grafikusok kiszórása és elkezdték a kiegészítő elemeket mesterséges intelligenciával pótolni. Ez leginkább egyelőre a recessziónak köszönhető és [számtalan cikk](https://index.hu/tech/godmode/2019/07/11/tulora-videojatek-ipar-rockstar-games-bioware-epic-games-riot-games-nintendo/?ref=blog.fps.hu) látott napvilágot arról, milyen szinten égetik ki a játékiparban dolgozókat, illetve mennyire [toxikus](http://https//www.gsplus.hu/hir/az-ea-egyik-vezetoje-szerint-a-jatekiparban-levo-toxikussag-nagyon-komoly-gond-306960.html/?ref=blog.fps.hu) a környezet. Ez az ipar is átalakulóban van, ami véleményem szerint nem is baj. Rendesen visszaélnek az ott dolgozók lelkesedésével és elkötelezettségével.

Hasonló a helyzet a filmes CGI világában, ahol a kiégés és a túlhajszolás mindennapos. Ugyanakkor érdekes példa a Godzilla Minus One idei legjobb vizuális effektusok Oscarja, amit egy pár emberből álló csapat és egy a CGI-ban jártas rendező hozott össze, szemben mondjuk egy Marvel film közel száz fős VFX team-jével. A különbség az volt, hogy volt koncepció és szakértelem. A büdzsé egy hollywoodi szuperprodukció töredéke volt. A szakemberek nyertek a totális szervezetlen fejetlenséggel, és örűlt kérésekkel szemben.

Nem feltétlenül a „gép” jelenti a legnagyobb fenyegetést a munkahelyre, hanem az ember, a vállalati beidegződések, a szokások, a hagyományok, illetve az olyan mondatok, amik meggátolják a fejlődést, mint „hát ez egy ilyen szakma”. Ha a producerek géppel készítik ezeket az effekteket, ugyanúgy kérni fognak őrült dolgokat, hogy elfedjék a koncepció hiányát. Ugyanez igaz bármilyen munkahelyre, ahol vizuális szakemberek dolgoznak.

**A célt, a víziót és a szakértelmet ki lehet AI-jal váltani?**

Ha olyan munkád van, mint amikor Henry Cavill bajszát retusálod le a Superman utóforgatásain, akkor baj, ha azt kiváltja/segíti az AI?

### Jog

A jogi kérdés is érdekes dolog. Hogyan használhatja fel a gép az általam alkotott képet? Miben más ez, mint az inspirálódás? Talán a konkrét elemek átültetése lehet… Sokszor emelek át megoldásokat Behance anyagokból, bár azt is lopásnak érzem. Mindig megnyugtat, ha ezt sokan tesszük és elnevezzük *trendnek*. Attól nem tűnik akkora gaztettnek.

Az AI által készített kép valahogy mindig más, mindig sutább, kevesebb tartalommal, kevesebb részletgazdagsággal, vagy épp kevesebb elnagyoltsággal. A gépies, kölcsönzött empátia nem ugyanaz, mint a valós. De azt gondolom jogos igény, ha nekem egy stock fotóért fizetnem kell, amit teljesen átalakítok, akkor az AI alkotói miért nem fizetnek az én általam alkotott munkáért, amit felhasznál az algoritmus? Nehéz ezt tetten érni. Annyira absztrakt és elvont témakör ez, a jog pedig annyira racionális és „stabil” ágazat, hogy a kettő nehezen ér össze.

Később ilyen esetekben is emberek fognak dönteni. Ha egy jogi esetnél a bíró úgy dönt, nem kell fizetni, akkor őt nem érdekli a művészet? Ha úgy dönt, hogy fizetni kell, akkor a haladást gátolja? Nehezen tudom elképzelni, hogy készül majd egy törvény, miszerint minden képnél közlik az „inspiráló” alkotók listáját. Kötelező lesz jutalékot fizetni a felhasznált elemekért százalékos arányban? Ha pénzt kapok, mert felhasználták a művemet, akkor megnyugszom? Így már rendben van az AI lopás, mert ki vagyok fizetve? Mindenesetre az biztosan nem jó gyakorlat, amit az instagram csinál, hogy az alkotók megkérdezése nélkül felhasználja a műveiket az AI-uk betanításához.

A [The Verve, a Bitter Sweet Symphony című daláért 22 évig](http://https//www.google.com/url?q=https://hvg.hu/kultura/20190524%5FThe%5FBitter%5FSweet%5FSymphony%5Fjogok%5FThe%5FVerve%5FRolling%5FStones&sa=D&source=docs&ust=1720436197172540&usg=AOvVaw39M0HpMQQPZzEpwiNiGqIj/) minden fillért Rolling Stones kapott, mert az övék volt a jogdíj, pedig a Verve egy majdnem teljesen egyedi számot hozott létre az eredeti felhasználásával. Ha én csinálok egy közepes képet és az AI csinál egy remek képet annak a felhasználásával abból én kapok pénzt, akkor azt magamban morálisan hogyan könyvelem el? Segítettem valami jobb létrehozatalában, vagy nyerészkedtem?

**Ha egy alkotó, aki rendkívül tehetségesen rajzol, de a rajzai nélkülöznek minden kreativitást, egyediséget, mondanivalót, miben különbözik az AI-tól?**

### Vég(?) következtetés

A képalkotásnál, ha mesterséges intelligenciát használunk, elmarad a katarzis. A folyamatból eltűnik az elmélyülés, és a játék. Kimarad az a fázis, amikor a visual az alkotás közepén más irányt vesz és valami egészen egyedi születik. Viszont a munkák 80%-a nem a kreatív alkotásról szól, hanem a favágásról. **A 20% az érdekes**.

Ha valaki nem kreatív grafikus csak közepes szakember, baj, ha AI-jal dolgozik? Baj, ha meg fogja találni a célközönségét? Azok az emberek, akik ilyen anyagokat szeretnének, egy kreatív embert csak kihoznának a sodrából, a munka elkészítése nyűg és fájdalom, teli ostoba kompromisszummal. Baj, ha olyan kreatív emberek kapnak eszközt az ötleteik megvalósításához, amihez eddig nem volt szoftverismeretük és/vagy tehetségük? Baj, hogy az ügynökségnél dolgozó grafikus unalmas stock fotó keresés helyett unalmas promptokat ír és ezzel időt sporól és közelebb kerül a végeredményhez?

Számtalan jó oldala is van ennek, de jelenleg még nem tart ott a dolog, hogy igazán kreatív dolgokat szüljön a gép. Mögötte mindig van egy kreatív ember aki segít neki. Lehet ezt a határt át fogja lépni az AI, de nem tudni mikor. Sokan mondják, hogy tudják, de ezt nehezen hiszem, maximum az ezeken a szoftvereken dolgozók tudhatják mikor jön az áttörés. Ha meg is történik, akkor is úgy érzem az igazán egyedi stílusú grafikusok/illusztrátorok nem lesznek veszélyben, akik kreatívak és jellegzetes kézjeggyel bírnak.

Remélem az emberek alkotta dolgokra mindig szükség van és igényeljük, hogy csodáljuk mások tehetségét, a gép pedig olyan, mint egy új telefon. Az ember örül neki és játszik vele, de pár óra után már csak szimpla használati tárgy.

**Az AI alkotta képek hibái nem szerethető stílusjegyek, mint a festményeken fellelhető vonások, karcok, vagy foltok, hanem csak idegesítő 8 ujjú anomáliák.**
### Növeld eladásaidat szükségletalapú kategorizálással
URL: https://blog.fps.hu/online-shopok-es-a-termekek-kategorizalasa/
Last updated: 2026-07-17T08:17:27.000Z
Az idei konferenciákon számtalan előadásban elhangzott, hogy a globalizált piacon úgy maradhatnak életben a magyar szereplők, különösen az e-kereskedők, ha egyre jobb ügyfélélményt nyújtanak, jobban megismerik a piacukat és célközönségüket, továbbá építik a márkájukat.

A lokális piac és az ügyfelek alapos ismerete az egyik kulcsfontosságú tényező, ahol versenyezni lehet a nagy szereplőkkel. Ehhez a célközönség mély ismeretére van szükség, amit főként kvalitatív kutatással lehet felszínre hozni.

## Kereső és kategorizálás

Az online e-commerce felületeknél a termékek kategorizálása mindig izgalmas kérdés. Számtalan kutatásunkból kiderült, hogy a felhasználók nagy hányada elsősorban a keresőt használja, hogy megtaláljon egy terméket, míg mások kategóriákon keresztül keresik a szükséges termékeket.

Egy jó online shop alapfeltétele, hogy a kereső jól látható helyen legyen és kitűnően működjön.

## Szükségletre kategorizálás

Az elmúlt években több széleskörű kutatást készítettünk, ahol a termékek kategorizálásával kapcsolatban előkerült egy érdekes trend. Egy 2022-es Rossmann mobil app kutatásunkból is kiderült, hogy a vásárlókban erősen megjelent az igény, hogy a szükségletüknek megfelelően tudjanak termékeket választani. Például az arcápolás kategóriában számos termék érhető el, de a vásárlók nem tudják, hogy az ő arcbőrtípusukra melyek a legmegfelelőbbek, illetve mely termékek kezelik hatékonyan az ő bőrproblémáikat.

Tehát rengeteg termék elérhető, de nem tudják, hogy számukra mi lehet a legjobb választás.

A Rossmann szerencsére komolyan veszi a vásárlói igényeket, ami [az arcápolási kategóriában megfigyelhető](https://shop.rossmann.hu/kategoria/arcapolas?ref=blog.fps.hu) és hamarosan más kategóriákkal folytatják a sort.

## Biztos, hogy ez egy jó irány?

Egy friss, [2024\. februári kutatás](https://tips.ariyh.com/p/show-products-by-benefits-not-features?ref=blog.fps.hu) is alátámasztja ezt a kérdést, amely mind online shopoknál, mind offline szupermarketeknél vizsgálta a termékek előnyök szerinti kategorizálását.

### A kutatás

Amikor a termékeket az általuk nyújtott előnyök alapján rendezték (pl. teák, amelyek segítenek az alvásban, emésztésben vagy energianövelésben), szemben a jellemzőik (pl. íz – kamilla tea, jázmin tea, borsmenta tea) szerinti rendezéssel, az emberek több terméket vásároltak.

Nyolc kísérlet során a kutatók azt találták, hogy amikor a termékeket az előnyök alapján kategorizálták, szemben az íz vagy összetevők szerinti kategorizálással, az emberek:

- 49%-kal több joghurtot
- 57,5%-kal több kenhető terméket (pl. lekvárok)
- 17,5%-kal több teát
- 10,9%-kal több táplálkozási szeletet választottak

A hatás akkor a legerősebb, ha szűk, konkrét előnyöket használtak (pl. fogyás, energianövelés, stresszcsökkentés), szemben a tágabb előnyökkel (pl. egészségvédelem).

### Miért működik?

- Minél több értéket látunk egy termékben, annál valószínűbb, hogy megvásároljuk.
- Amikor a termékeket az előnyök alapján kategorizálják, jobban megértjük, hogyan elégítik ki a szükségleteinket.
- Így nagyobb valószínűséggel képzeljük el magunkat a termék használata közben, ami növeli a vonzerejét.
- A nagyon specifikus kategóriák még nyilvánvalóbbá teszik a termék előnyeit és értékét.

Fontos megjegyezni, hogy a kísérletek kizárólag élelmiszertermékeket vizsgáltak, bár valószínű, hogy ez más kategóriákra is érvényes, de ezt még nem tesztelték.

Mindentől függetlenül **a szükségletalapú kategorizálásra komoly igény van vásárlói oldalon**.

## Konklúzió

Ahhoz, hogy jobban megismerd a célközönséged, feltárd a vágyaikat, a bizonytalanságaikat, a fájdalom pontjaikat, a problémáikat és a valós igényeiket, kvalitatív kutatásokra van szükség. **Ha mély ismereted van a vásárlóidról, akkor lehetsz versenyképes.**

Van egy jó digitális projekted? Kutatásra lenne szükséged? Vagy szeretnéd auditáltatni az online felületed? Esetleg segítsünk, hogy jobb konverzióval működj?

[Keress bátran, segítünk!](mailto:sales@fps.hu)
### HUN vagy karácsony
URL: https://blog.fps.hu/hun-vagy-karacsony/
Last updated: 2026-07-21T13:28:58.000Z
Állítólag sosem volt hun a karácsony. Lekutattuk és kiderült, hogy de. Az eredményeket illusztrációkba foglaltuk és tettük szabadon felhasználhatóvá. Íme.

## Miki bá

![Miki bá](https://blog.fps.hu/content/images/2023/12/miki-ba.png)

## A rátölti manó

![A rátölti manó](https://blog.fps.hu/content/images/2023/12/a-ratolti-mano.png)

## Jószágvonta székely szánka

![Jószagvonta székely szánka](https://blog.fps.hu/content/images/2023/12/joszagvonta-szekely-szanka.png)

## Krampusz koma

![krampusz-koma](https://blog.fps.hu/content/images/2023/12/krampusz-koma.png)

## Szögedi izzósor

![Szögedi izzósor](https://blog.fps.hu/content/images/2023/12/szogedi-izzosor.png)

## Matyó díszgömböc

![Matyó díszgömböc](https://blog.fps.hu/content/images/2023/12/matyo-diszgomboc.png)

## Kocsonyagömb

![Kocsonyagömb](https://blog.fps.hu/content/images/2023/12/kocsonyagomb.png)
  
  
**Töltsd le a clipart csomagot vektorosan és használd szabadon!**

[Letöltöm a clipartokat (0 letöltés)](https://www.fps.hu/presentations/hun-vagy-karacsony-clipart-csomag-fps.zip?ref=blog.fps.hu "Letöltöm a clipart csomagot")
### Csak egy egyszerű feature-re van szükségünk
URL: https://blog.fps.hu/legacy-projektek-regresszios-tesztek/
Last updated: 2026-07-17T08:17:47.000Z
*…szólt a kérés, de hamar kiderült, hogy valójában jól tovább-bontható az igény, és bár egyszerűen megfogalmazhatóak, a megvalósítás viszont korántsem egyértelmű. Főleg azért, mert egy több éves projeket kellett kiegészíteni, ami egy előző szemléletmód mentén készült.*

Fejlesztőként gyakran kell feladat komplexitást, időigényt becsülnöd. Mit számolsz bele? A fejlesztési időt. És persze dokumentációt, tesztelést, javítást. Egyeztetéseket, vakvágányokból gyors iránybaállást, refaktorálást.

*Megbecsültük, kitaláltuk hogyan futunk neki, nekifutottunk.*  
De ha refaktorálsz egy modult, hol húzod meg a határt? Mi az, amihez már semmiképpen nem nyúlsz?  
Ha jól van szeletelve az alkalmazás, akkor csak elrontani lehet: kapsz pár contract-ot, amit tisztelsz, tesztelsz, mögötte megbütykölhetsz bármit.

*Örültünk, hogy ha tesztek nem is, de egy használható API dokumentáció legalább rendelkezésre állt, amibe tudtunk kapaszkodni, amíg mozgott a kódbázis.*  
De ha azt látod, hogy a modulok határai elmosódnak, és egy egység megváltoztatása után olyan dolgok borulnak, amire nem számítottál, akkor biztos, hogy a [Boy Scout Rule](https://www.informit.com/articles/article.aspx?p=1235624&seqNum=6&ref=blog.fps.hu) végtelen túrkálással és bugfixeléssel történő félreértelmezése a legrosszabb, amit tehetsz.

Ezekben az esetekben lépj egyet hátra, és nézd meg messzebbről a helyzetet. Régi kódbázisok esetén ha nem cél újrafejleszteni az egész rendszert, akkor elengedhetetlen, hogy stabilizáld a rendszer állapotát, hogy a következő verzió legalább rosszabb ne legyen, mint az előző.  
Ezt legjobban a hiányzó tesztek pótlásával tudod megtenni, amit ideiglenesen talán kiválthatsz kézi teszteléssel („arra mindig kell legyen idő”), de egy kis tanulással az e2e tesztek java automatizálható.  
És ez olyan, mint a konditerembe járás: senki nem mondta még, hogy megbánta, hogy edzett egy jót. És az is igaz talán mindkét esetben, hogy nem lehet elég korán elkezdeni.

*A szóban forgó projekt esetében pont így jártunk, hetekkel később született meg a funkciókat és felületeket 85%-ban lefedő automata teszt, mint célszerű lett volna, és milyen jó lett volna már az elején…*  
Test frameworkök és toolkitek jönnek-mennek, de ha keresel, lesz miből választanod a te rendszeredhez is.  
Mivel nekünk a frontend keveset változott, az API stabilitását a frontendre futtatott cypress.io tesztekkel tudtuk jól és egyszerűen mérni, és végül több napnyi időt spóroltunk még úgy is, hogy későn hoztuk meg a döntést a tesztekről.

Legacy projektek esetében az egyik legjobb időbefektetés már a projekt feltérképezése közben olyan eredményeket gyűjteni, amit később regressziós teszteléshez felhasználhatsz – egyik kedvencem: a [karakterizációs tesztek](https://en.wikipedia.org/wiki/Characterization%5Ftest?ref=blog.fps.hu) \- hogy később ki tudd magad vágni azokból a helyzetekből, amikor felvetődik a kérdés:  
„ez korábban sem működött?”
### Digitalizálj jól!
URL: https://blog.fps.hu/digitalizalj-jol/
Last updated: 2026-07-17T08:17:57.000Z
Digitalizálunk. Amit csak lehet, digitalizálunk. Üdvözlendő, hiszen a folyamatok hatékonyabbá, transzparenssebbé, mérhetőbbé válnak, ráadásul a hibalehetőségek száma drasztikusan csökken. Viszont lehetne jobban is csinálni. Sajnos kifejezetten sokszor találkozom azzal, hogy valahogy a digitalizáció során kifelejtődik az ember, az emberi tényező.

Mesélek egy sztorit, ami megvilágítja, mire gondolok. Dolgoztam egy kórházi projekten, ahol a műtéti előjegyzést kellett digitalizálni. Volt kettő, a hétköznapokban használt napló, amibe kézzel, sokszor felülírva egymást, jegyezték fel az orvosok, nővérek hónapokkal előre a páciensek műtétjeit. Mit gondolsz, miért terveztünk egy új célszoftvert a naplók kiváltására? Mert létezik egy kórházi rendszer, ami ugyan ezt a funkciót is képes ugyan ellátni, csak épp használhatatlan és alkalmatlan rá. Sok másra jó, de erre nem. 

A példa jól demonstrálja a digitalizáció során elkövetett egyik fő hibát, amit több ízben is tapasztaltam már. A valóságban létező folyamatokat úgy képezik le digitális rendszerekbe, hogy asztalok, táblák mellett terveznek, gondolkodnak, ötletelnek vezetőkkel, szakértőkkel közösen. Kétségkívül kényelmes így, de a folyamatban résztvevőket és érdekelteket nem kérdezik meg. Pedig az ő munkájukat (is) könnyíti majd az új rendszer és ezeknek az embereknek kell majd a rendszerrel dolgozniuk. Ráadásul az asztalok mögött nem derül fény olyan problémákra, fájdalmas pontokra, ilyen-olyan motivációkra, amelyek nagyon is léteznek. Ha ez kimarad, akkor jön a megoldáskeresés. Nem tudja a rendszer? Akkor megoldjuk okosba, mert az ember kreatív. Legrosszabb esetben nem használják a rendszert. Így született meg anno a napló használat is. 

Bármilyen folyamato(ka)t is digitalizálsz, menj ki terepre. Térképezd fel a folyamat pontjait, az ott megjelenő emberekkel beszélj, értsd meg a motivációikat, az érdekeiket, a fájdalmas pontjaikat, a kérdéseiket, a problémáikat. A digitalizált rendszert úgy kell tervezni, hogy az figyelembe veszi az embert, az embereket is.
### Designer játékok
URL: https://blog.fps.hu/designer-jatekok/
Last updated: 2026-07-17T08:18:07.000Z
Összegyűjtöttünk designereknek szóló teszteket, egyszerűbb játékokat, tanuló és fejlesztő kvízeket. Így neked is meglesz itt mindig (bookmarkért kiált), ha épp szükséged lenne rá. Nem utolsó sorban pedig jó játszadozást, önfejlesztést!

*UPDATE 2022.12.20\. – immáron 24 design játék gyűlt össze.*

#### 1\. Color Game

![Color game](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-01.png)  
Találd meg a pontos színt!  
[https://color.method.ac/](https://color.method.ac/?ref=blog.fps.hu)

#### 2\. KOLOR

![KOLOR](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-02.png)  
Találd el a színt időre!  
[https://kolor.moro.es/](https://kolor.moro.es/?ref=blog.fps.hu)

#### 3\. Hex Invaders

![Hex Invaders](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-03.png)  
RGB játék.  
[http://www.hexinvaders.com/](http://www.hexinvaders.com/?ref=blog.fps.hu)

#### 4\. The perfect paragraph

![The perfect paragraph](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-04.png)  
Tipográfia játék (betűméret, paragrafus szélesség, sormagasság).  
[https://betterwebtype.com/triangle/](https://betterwebtype.com/triangle/?ref=blog.fps.hu)

#### 5\. typewar

![typewar](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-05.png)  
Tipográfiai játék, melyik-melyik betűtípus?  
[https://typewar.com/](https://typewar.com/?ref=blog.fps.hu)

#### 6\. The Font Game (quiz)

![The Font Game (quiz)](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-06.png)  
Felismered melyik betűtípus?  
[https://ilovetypography.com/2020/05/31/the-font-game](https://ilovetypography.com/2020/05/31/the-font-game?ref=blog.fps.hu)

#### 7\. It’s centered that

![It’s centered that](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-07.png)  
Mit gondolsz, középre van rendezve?  
[https://www.supremo.co.uk/designers-eye/](https://www.supremo.co.uk/designers-eye/?ref=blog.fps.hu)

#### 8\. Pixactly

![Pixactly](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-08.png)  
Találd ki a pontos pixel méretet!  
[https://pixact.ly/](https://pixact.ly/?ref=blog.fps.hu)

#### 9\. Can’t unsee

![Can’t unsee](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-09.png)  
Mit gondolsz melyik a szebb design, látod, hogy nem okés?  
[https://cantunsee.space/](https://cantunsee.space/?ref=blog.fps.hu)

#### 10\. The Boolean Game

![The Boolean Game](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-10.png)  
Vektoros elemekkel játék, tanulj meg vektorokkal dolgozni!  
[https://boolean.method.ac/](https://boolean.method.ac/?ref=blog.fps.hu)

#### 11\. The Bézier Game

![The Bézier Game](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-11.png)  
Játék a vektoros rajzolás megtanulásához.  
[https://bezier.method.ac/](https://bezier.method.ac/?ref=blog.fps.hu)

#### 12\. Kerntype

![Kerntype](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-12.png)  
Találd meg a megfelelő kerninget!  
[https://type.method.ac/](https://type.method.ac/?ref=blog.fps.hu)

#### 13\. Shapetype

![Shapetype](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-13.png)  
Betűk vonalának szerkesztése, avagy fejlődj a fontkészítés területén!  
[https://shape.method.ac/](https://shape.method.ac/?ref=blog.fps.hu)

#### 14\. I shot the sherif

![I shot the sherif](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-14.png)  
Találd meg a talpas betűket!  
[https://www.tothepoint.co.uk/us/fun/i-shot-the-serif/](https://www.tothepoint.co.uk/us/fun/i-shot-the-serif/?ref=blog.fps.hu)

#### 15\. Color eye test

![Color eye test](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-16.png)  
Mennyire érzékeled a szín eltéréseket?  
[http://game.ioxapp.com/eye-test/game.html](http://game.ioxapp.com/eye-test/game.html?ref=blog.fps.hu)

#### 16\. Hue test

![Hue test](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-17.png)  
Teszteld mennyire látod a színátmeneket!  
[https://www.xrite.com/hue-test](https://www.xrite.com/hue-test?ref=blog.fps.hu)

#### 17\. Pixel Guesser

![Pixel Guesser](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-18.png)  
Állítsd be a téglalapok pontos pixel méreteit!  
[https://fakeclients.com/exercises/pixelguesser](https://fakeclients.com/exercises/pixelguesser?ref=blog.fps.hu)

#### 18\. Design quiz

![Design quiz](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-19.png)  
Teszteld a UX/UI/graphic design ismereteid!  
[https://thedesignquiz.com/](https://thedesignquiz.com/?ref=blog.fps.hu)

#### 19\. Ueye

![Ueye](https://blog.fps.hu/content/images/2021/09/Designer-ja-te-kok-20.png)  
Válaszd ki, hogy milyen UI design probléma van az adott felületeken és tedd helyre!  
[https://designcourse.com/app/course/ueye](https://designcourse.com/app/course/ueye?ref=blog.fps.hu)

#### 20\. Marvel character or Font?

![Marvel character or Font?](https://blog.fps.hu/content/images/2021/10/Designer-ja-te-kok-21.png)  
Egy név alapján el tudod dönteni, hogy az egy Marvel karakter, vagy egy betűtípus?  
[https://marvel-or-font.web.app/](https://marvel-or-font.web.app/?ref=blog.fps.hu)

#### 21\. Accessibility Maze

![Accessibility Maze](https://blog.fps.hu/content/images/2021/10/Designer-ja-te-kok-22.png)  
Egy cuki mászkálós, feladványos játék, ami közben megtanít az akadálymentesség alapjaira.  
[https://de.ryerson.ca/games/accessibility/#/](https://de.ryerson.ca/games/accessibility/?ref=blog.fps.hu#/)

#### 22\. Foney Fonts

![Foney Fonts](https://blog.fps.hu/content/images/2022/12/Designer-ja-te-kok-23.png)  
Néhány ismert márka logója egy meglévő font egyedi módosításából születtek. Ebben a játékban meg kell mondanod, hogy a logó melyik változata tartalmazza az eredeti, vagy a módosított fontot.  
[https://www.supremo.co.uk/foney-fonts-christmas/](https://www.supremo.co.uk/foney-fonts-christmas/?ref=blog.fps.hu)

#### 23\. Colordle

![Colordle](https://blog.fps.hu/content/images/2022/12/Designer-ja-te-kok-24.png)  
Wordle csak színekkel. Ki kell találnod, hogy az oldal tetején megjelenő szín hexa kódja pontosan mi.  
[https://colordle.com/](https://colordle.com/?ref=blog.fps.hu)

#### 24\. HOCUS:FOCUS

![HOCUS:FOCUS](https://blog.fps.hu/content/images/2025/02/Designer-ja-te-kok-25.png)  
Billentyűzeten kell TAB-bal és SHIFT+TAB-bal lépkedned és „vakon” megtalálnod a fókuszt a jelölt csempén. Jól megmutatja, hogy milyen nehéz használni egy felületet billenytűzetről, ha a felhasználó semmilyen feedbacket nem kap arról, hogy melyik elem van fókuszban.  
[https://focus.hteumeuleu.com/](https://focus.hteumeuleu.com/?ref=blog.fps.hu)

#### 25\. MazeWave

![MazeWave](https://blog.fps.hu/content/images/2025/02/Designer-ja-te-kok-26.png)  
Teszteld a kognitív és precíziós készségeid! Demostrálja milyen az érzés az, amikor megköveteled a felhasználóktól, hogy precízen használják az egerüket, ujjukat, illetve milyen az, amikor túl zajos és nehezen értelmezhető egy felület.  
A játék során az akadálymentesség csökken, az olvashatóság romlik, a nehézségi szint növekszik. Hány pontot értél el? Kommentben várjuk!  
[https://mazewave.com/](https://mazewave.com/?ref=blog.fps.hu)

Ismersz még hasonló cuccot? Kommentbe írd be és betesszük!
### Continuous documentation
URL: https://blog.fps.hu/continuous-documentation/
Last updated: 2026-07-17T08:18:18.000Z
> Minek töltsek időt a dokumentáció megírásával, ha én úgyis értem hogyan működik? – hiszen én írtam.

A dokumentáció hiánya okozta-, és az elkészítésével kapcsolatos érzéseket sokan ismerjük. Viszont ha ez ennyire ellentmondásos, miért nincs még rá könnyű megoldás?

### Open source csomagok

Ha egy 3rd party package-re akarok támaszkodni, egyből ütöm fel a github-ot, és bújom a dokumentációt, hogy a lehető legrövidebb idő alatt megértsem miként kell használni, milyen interface-eken keresztül tudom beépíteni. Ha őszinte akarok lenni, kevésbé érdekel, hogy hogyan működik, csak működjön. Szeretem a jó minőségű csomagokat, mert egyszerűsítik a munkát, kényelmes őket használni, és sokban nyomós okokból meg is bízom: a weekly download counter milliós nagyságrenden van (ennyi fejlesztő nem tévedhet), használható a leírás, aktívan karbantartják a kódot, zöldek a tesztek, nincs piros security warning a csomagkezelőben telepítésnél, és „a másik projeken is rendben volt”.

Ez is jól mutatja, hogy másoknak úgy tudsz hatékonyan átadni kódot, ha az megfelel a „jó minőség” kritériumainak. Ez egy open source csomag esetében kényszer is, mert senki nem ér rá elmagyarázni egyesével a programozóknak, hogy hogyan kell beépíteni. A csomagok elkészítésének módszertana a háttérben közben változatos lehet, gyakran mire elkezded használni, több tucat contributor sok száz órányi kollaborációja van mögötte: kutatás, kódolás, tesztelés, tapasztalatszerzés, újrakezdés, egyeztetések, dokumentáció írás stb.

### Alkalmazásaink moduljai

Ugyanezt tapasztalom, mikor csapatban fejlesztünk egy rendszert: kellő tervezés és dokumentáció nélkül újra és újra előkerülnek ugyanazok a kérdések.  
Ha egy jó specifikáció segít közös nyelvet beszélni a projektben és használható rendszertervvel meghatározzuk a komponensek és modulok kapcsolódási pontjait úgy, hogy azokról mindenki számára egyértelműek az interface-ek, akkor már sokkal jobb helyzetben vagyunk. Viszont számtalanszor láttam olyat is, hogy a tervek ellenére elkezdtek burjánzani a mellékszálak, előre ki nem talált részekre gyakran felesleges egyedi megoldások, és nehezen érthető komplexitás került.

Egy „monolit vs microservice” podcast-ból beugrik egy ide illő gondolat:

> nem baj, ha a rendszerben van szemét, de azok legyenek izolált kis szemétkupacok

Ennél kevésbé volt szofisztikált az eredeti megfogalmazás, de az üzenet lényege az volt, hogy ha az architektúrád rendben van, akkor az alkalmazás jó állapotát könnyebb megőrizned, mert meghagyod a lehetőséget arra, hogy komponensenként hibát keress, tesztelj, javíts, refaktorálj. Viszont ezeknek az építőelemeknek össze kell kapcsolódnia, amihez át kell tudnod adni fő konpeciókat.

Az sem feltétlen baj, ha egy package-hez nincs részletes dokumentáció, ha az külső csomag, így nem kell módosítani, csak használni. Azonban ha az alkalmazásod egy komponenséről van szó, amivel nagy eséllyel még lesz dolgod, akkor a belső működést is célszerű könnyen érthetővé tenni, hogy gyorsan fel lehessen venni a fonalat, ha át kell adnod, vagy ha újra elő kell venned.

A komplex részek akkor is megérdemelnek pár sor leírást, ha jól olvasható a kód. Ezt feljegyezhetünk DocBlock comment-ekben, de mivel azok erősen kontextushoz kötöttek (adott osztályhoz, metódushoz, kódrészlethez kapcsolódnak), nem ideálisak átfogó koncepció kifejtésére. Ebben segíthet, ha van módszered az alkalmazás forrásához tartozó leírás folyamatos bővítésére. Ezt azért nem fejtem ki, mert született egy páratlan cikk a megközelítésről, amit itt olvashatsz:

[infoq.com/articles/continuous-documentation](https://www.infoq.com/articles/continuous-documentation/?ref=blog.fps.hu)

### Javaslatok

A gyakorlati megvalósítás a cikk alapján kézenfekvő, mégis megosztok pár gondolatot kiegészítésképpen:

- a kód és a dokumentáció írása közben gondolkozz néha az olvasó fejével is – aki lehetsz akár Te is pár hét múlva – és azokat a részeket jegyezd fel, ami számodra sem volt egyértelmű. Ezáltal egyszerre fejlesztői jegyzetet és dokumentációt is készítesz.
- készíts egy "docs" directory-t a komponenseidhez a verziókövetőben, és ebben építsd fel a leírást.
- használj markdown-t, képeket, mermaid diagramokat és code snippet-eket a leírásban
- a hosszabb magyarázatokat, amit máskor a kódban írnál, írd meg a "docs"-ban, és linkeld be egy @see-vel
- a fentit alkalmazhatod visszafelé is, pl code snippet-ek helyett, akár a szövegesen kifejtett story-k és a tesztek összelinkelésére stb.
- a codereview keretében nézzétek át, tartsátok naprakészen a leírásokat is!

Pro tip: Ha a technikai tervezést is a repository-ban kezded el, tulajdonképpen a teljes SDLC alatt egy folyamatosan fejlődő leírásod lesz, ami a végén a rendszertervből egy részletes technikai dokumentációvá válik úgy, hogy közben minden közreműködő gyakorolja a dokumentálást is, ami sok esetben hasonlóan rávezet a helyes megoldásokra, mint a rubber duck debugging: „marhaságot mégsem írok le”.
### CoviDesigner
URL: https://blog.fps.hu/covidesigner/
Last updated: 2026-07-17T08:18:28.000Z
„Végre egy írás, ami nem a koronával foglalkozik!” – mondhatják fellélegezve azok, akik nem ezt a bejegyzést olvassák. Nem értek egyet azzal a metódussal, hogy ezt a tényezőt kizárjuk az életünkből. Mindenkinek csömöre van, mindenki kiégett, de nem tehetünk úgy mintha nem lenne. Olyan ez, mint egy elítéltnek azt mondani, zárja ki a környezetét a börtönben és úgy gyorsabban telnek a napok. Foglalkozni kell vele, csak ugye mértékkel.

Most megosztom a tapasztalataimat, hogyan is érzem magam ebben a helyzetben. Nem gondolom, hogy ezzel sokat segítek, de ha már egy ember olvassa, aki hasonló cipőben jár, megéri. A tudat, hogy nem vagyunk egyedül, egy ilyen elszigetelt időszakban sokat segíthet. Tudom, sokan sokkal nagyobb problémáktól szenvednek (elvesztették a munkájukat, kevesebbet keresnek, más területre kényszerültek), kérem őket, hogy nézzék el a „hőbörgésemet”.

### Home Office

Megrögzött introvertáltként a home office nem jelentett különösebb problémát. Első körben iszonyatos megkönnyebbülést okozott, hogy budapestiként nem kell reggel és délután 50 percet utaznom, mert engem őszintén megvisel a tömegközlekedés. Szeretem bámulni az embereket, felmérni ki, milyen lehet, és érdekelnek a pillanatnyi sorsok. Ezek szórakoztatnak, de van egy másik oldala. Konfliktus nélkül nem telik el utazás. „Adj egy cigit!”, „Bezzeg a mai fiatalok!”, „Kérjük a jármű ÖSSZES ajtaját használják a felszálláshoz!” stb. Ahogy ezt leírtam, máris megkönnyebbültem, hogy itthon vagyok.

Aztán persze a home office-szal karöltve kezdődött az egzisztencialis szorongás. Ez rendesen kikészített (azért valljuk be nem designerre van a legnagyobb szükség pandémia idején). Egy idő után megszoktam és megprobáltam nem feszt a munkám elvesztésének lehetőségén szorongani (márha ez lehetséges). Ez kicsit olyan állapot volt, mint mikor másodjára öntöd ki a kávét, és a harmadik alkalomnál elkezded a földre önteni az egészet, mert eleged van.

Ezután következett a kis hétköznapok problémáinak feltárása. Hol ér véget a munka? Hol kezdődik a szabadidő? Erre már sok helyen leírták, hogy rendszert kell alkotni. Kijelölt helyen végzem a munkát, és bizonyos időn belül. Tartom, és nézem a munkaidő végét, mert különben nem válik szét a munka és magánélet. Mindig felöltözöm és úgy indítom a napot, mintha bejárnék dolgozni. Így, ezzel a rendszerrel kis keretet kap a munkaidő. Akik mindezt gyerekekkel tudják menedzselni, azokat őszintén tisztelem, úgy képzelem, olyan lehet, mint körhintán levest enni.

### A munkahelyváltás

Egy olyan fura helyzetbe kerültem, hogy az x-edik hullám közepén (végén, elején, a franc se tudja már) váltottam munkahelyet. Elég bizarr dolog ez. Az interjú előtt nem volt a szokásos térképen keresgélés, időzítés, azt megelőző izgalom. Az online interjú kedélyesen telt, de mégsem tudtam átlényegülni, felvenni a ritmust, felfedezni a helyet. Nem volt a szokásos fizikai körítés, ami segít egy hangulatot felmérni. Nem is tudtam eddig, mennyire fontos. Az ajánlat tetszett, a beszélgetés jó volt és könnyed, de hiányzott ez a kis hangulat faktor, ami segít a döntésben. Gondolom a másik oldalon is. Az interjú utáni pro és kontra mérlegelést, felváltotta egy olyan érzés, mint amikor az ember túl jó áron foglal szállást, és míg odaér, van benne egy bizonytalanság, hogy mi van, ha a képek nem is valósak. Ez a bizonytalanság egy idő után elmúlt és megynyugodtam.

A munkába gyorsan bele tudtam rázódni, de a csapat és a szervezeti rendszer sokkal nehezebben jött át. Nem a kommunikáció miatt, egyszerűen, ha az ember jelen van, a testbeszédből, kávézás, cigizés közben kérdezősködésből gyorsan felméri, kinek mi a feladata, szerepköre. Ezen kívül, amire eddig nem is gondoltam, milyen nehéz online felmérni, kinek milyen a humora. Az enyém karcos. Nehéz volt felfedezni, hogy ez kinek sok, kinek bántó, és úgy megnyilvánulni, hogy esetleg ne kreténezzen le senki az első nap. Igazából az ajtóstul a házba stratégiát alkalmaztam, hoztam a legrosszabb formámat és azután finomítottam, afféle inverz Nicolas Cage-ként. Persze ez nem volt tudatos, annyira zavarban voltam, hogy ezt nem tudtam kontrollálni. Javaslom másoknak, ha ilyen helyzetbe kerülnek, ne ezt a módszert alkalmazzák, mert egy kevésbé megértő közegben, rosszul is elsülhet.

### A kreativitás

Miután sikerült beszoknom, megismertem a projekteket, munkatársakat, elkezdődtek a pandémia alatti munka apróbb nehézségei összeadódni. Hobbi szociálisként, azért barátokkal össze-összefutottam legalább egyszer egy héten. Mikor magamtól akartam őket kímélni, akkor is kéthetente egyszer. Ez rengeteget ad a feltöltődéshez. Más problémák, más örömök. Más sikereket hallgatok és őszintén tudok neki örülni, vagy épp felidegesíteni magam. Ez egy olyan érzelmi inger, ami jelenleg hiányzik. Online is vannak ilyenek, de egészen más hangulatúak, ezen kívül egy általános szorongás alapból érződik mindenkin, és nincs meg az italozással egybekötött feloldozás, majd a levezető hazamenetel.

Ez is egy szertartás, aminek sok elemét el kellett hagyni. Időközben felmértem. Ez is egy inspirációs felület, amivel a munkámat könnyebben tudom végezni, és most hiányzik. Ugyanígy kiestek a fizikai inspirációk, a múzeumok, a tájak, az utazások, a koncertek. Nem is tudtam, hogy ezek mennyire tágítják az ember látókörét, és mennyire segítik a kreatív munkát. Azt vettem magamon észre, hogy sokkal könnyebben mennek a kicsit mechanikusabb, rendszert felépítő feladatok, mint egy UI kit, vagy design system. Míg a kreatív koncepcióm, az illusztrációk meg kicsit nehezebben. Ez eddig fordítva volt. Igyekszem azért most már egyre többet inspirálódni, marad az online megoldás. Talán valamelyest segít is a helyzeten.

### A stressz

Tegnap volt egy szeánszunk, ami szervezeti problémákat hivatott feltárni és megoldani. Egy idő után azt vettem észre, átfordult egy kicsit szupervízióvá és páran az ügyfelek által ejtett sebeket igyekeztük gyógyítani. Rengeteget segített. Az esemény után tudatosult, hogy mennyire szükség van kávézás/cigizés közben kipuffogni a problémákat, mert csak elterül az emberben és egyre nehezebb kimosni. Miután kiadod, már nem is tűnik problémának, vagy kiderül, hogy mégis az, és foglalkozni kell vele, de mindenképpen segít objektíven megítélni.

Alapvetően szerintem tízszer annyi stressz borul most az emberre. A vírus helyzet, az egzisztenciális szorongás, a gazdasági problémák, a szociális kapcsolatok hiánya, a szociális kapcsolatok megléte, az állandó bizonytalanság, az idős rokonok miatti aggódás, az idős rokonok veszélyérzetének kialakítása, az idős rokonokkal történt összeveszés kiheverése stb. Viszont ezt nem kompenzálja utazás, ünnepek, baráti találkozók, és egyéb kikapcsolódó tevékenységek. Saját magunkkal vagyunk összezárva, és muszáj jóban lennünk magunkkal, mert különben a feszültség elhatalmasodik rajtunk.

Volt régen egy munkatársam, akinek olyan volt a habitusa, hogy minden projekttel/feladattal kapcsolatban úgy indított, mint egy pankrátor, aki meccs előtt a ringbe szállva üvölt. Ő ilyen volt, és mi próbáltuk empátiával kezelni a jelenséget. Most úgy tűnik, az egész világ ilyenné vált. Nehéz most empatizálni másokkal. Sok helyzetre nem tudom mi a megoldás. Ezek csak élmények, szubjektív tapasztalatok, de az, hogy leírtam, segített összegezni is magamban, illetve segített egy lépéssel távolabbról szemlélni a dolgokat. Remélem akad olyan, akinek szintén segít, legalább csak közösséget vállalni.
### Mondd mekkora a büdzséd!
URL: https://blog.fps.hu/tenderbe-ird-a-budzsed/
Last updated: 2026-07-17T08:18:38.000Z
Oké, digitalizációra van szükséged. Nem működik jól a digitális terméked, vagy megváltoztak az üzleti célok. Esetleg átalakult a célközönség, az igényeik. Netán valami új terméket, szolgáltatást indítasz, digitalizálsz. Összeültök, hogy megírjátok a tenderanyagot.

Ha házon belül nincs szakértőtök, akkor a tender kiíráshoz érdemes bevonni egy külső digitális tanácsadót, céget. Segít megfogalmazni a célokat, az elvárásokat, nem utolsósorban a nagyságrendi költségvetés és a megtérülés idejének meghatározásában. Nem árt, ha a befektetésre már előre rászámolsz 15-20%-ot. Projekt közben felmerülhetnek előre nem látható plusz költségek, illetve az ügynökség kiválasztásánál is jól jöhet neked egy kis mozgástér.

Rendben. Összeállt a tenderanyag. Kiírod a pályázatot, és várod az ajánlatokat.

### Írd bele a büdzsét is!

A tapasztalatunk ügynökségi oldalról az, hogy a leendő ügyfelek nem osztják meg velünk a büdzsét. Sőt, sok esetben elképzelés sincs rá. Arra biztatlak most, hogy a megszokott módszeren változtass és **a tenderben közöld előre mennyit szántok a projektre**.

#### Miért?

Egy digitális termék tervezése, fejlesztése, bevezetése, kommunikációja komplex feladat. Ha elküldesz egy általános leírást, arra csak egy széles árintervallumot tudunk mondani. Az intervallum maximum pontja az ideális eset, amibe minden módszert, a kutatástól kezdve, a minőségbiztosításon át beleveszünk. Ha egy beeső tenderben nincs meghatározott büdzsé, akkor nem marad más számunkra, minthogy önhatalmúlag felmérjük a leendő ügyfelet és megsaccoljuk mi lehet az az összeg, amit erre a projektre szánnak. Ebből kiindulva gondolkodunk és adunk indikatív ajánlatot. Így simán előfordulhat, hogy nem az elképzeléseidhez, lehetőségedhez mért legjobb elgondolásokat, megoldásokat kapod, és kizársz olyan ügynökséget, aki egyébként jó lehetne neked.

#### Miért jó, ha beleírod?

1. **Lerövidíted a kiválasztási folyamatot**, ugyanis lemorzsolódnak azok, akik kevésnek tartják a projektösszeget, így nem raboljátok feleslegesen egymás idejét.
2. **Kaphatsz további ajánlást**. Elképzelhető, hogy egy magas díjjal dolgozó ügynökség már nem fér bele a költségvetésbe. Ilyenkor ajánlani fognak neked egy kisebb céget, ami viszont még jó minőségben, a célokat elérve, levezényelheti a projekted. Az fps-nél például rendszerint ajánlunk más cégeket.
3. **Jobban össze tudod hasonlítani az ajánlatokat és betekintést nyersz az ügynökség gondolkodásmódjába**. Ez a legfontosabb pont, ami számodra előny, hiszen a „kóklereket” így könnyedén ki tudod szűrni.
4. Sokat **segítesz** az ügynökségeknek, így magadnak is.

Még egyszer. Mindennek előfeltétele, hogy egy digitális tanácsadó, belső szakértő segítse a tender folyamatot a kiírástól, a kiválasztásig.

### A büdzsé nem elég!

Akkor kaphatsz jó ajánlatot a megadott tervezett projektösszegre, ha elmondod mik a digitális terméked üzleti céljai, ki a célközönség, kik a belső felhasználók. Hiszen végeredményben mindig ugyanaz a cél: elérni az üzleti célokat úgy, hogy hasznos legyen azoknak, akik használják, mindezt a technikai korlátok figyelembevételével. Ilyen a jó digitális termék.

Olvass még arról, hogy szerintünk [mire kell még figyelni egy tender kiírásánál](https://blog.fps.hu/tervezes-folyamat-tender-palyazat-huzzuk-le/), illetve az ügynökségi árképzésről, vagyis [mennyi az annyi](https://blog.fps.hu/mennyi-az-annyi/)?
### Gondolatok kezdő tervező önmagamnak…
URL: https://blog.fps.hu/gondolatok-kezdo-tervezo-onmagamnak/
Last updated: 2026-07-17T08:18:50.000Z
Az évek alatt, amióta tervezőként dolgozom, sokféle projektben vettem részt, számos emberrel találkoztam, jónéhány módszertant megismertem és számtalan problémával szembesültem. Időközben megfogalmazódott, tudatosult bennem néhány olyan, akár már-már evidensnek tűnő dolog is, amelyekkel jó lett volna, ha már a pályám elején tisztában vagyok.

Az alábbi listában összeszedtem a szerintem leghasznosabbakat, hátha neked is segítenek:

1. Nem létezik olyan, hogy ideális projekt, ezért fontos, hogy tudj alkalmazkodni és légy kompromisszumkész!
2. A valós problémák és igények ritkán adják magukat könnyen, azokért meg kell küzdeni,
3. és nem létezik rájuk „A Tökéletes”, vagy „Az Egyetlen” megoldás. A lehető legtöbbet kell kihozni abból, ami van és mindig a „metszetet” keresni.
4. A saját tudástól nehéz függetlenedni és a látóköröd észrevétlenül szűkül.
5. Lehetetlen minden igénynek megfelelni, csoportosítani és priorizálni kell!
6. Nem minden döntést neked kell meghoznod, sőt! Neked legtöbbször azt kell tudnod, hova fordulj.
7. A megrendelő is felhasználó (és ember is egyben).
8. A jó gondolkodásmód sokkal előrébb való, mint bármilyen eszköz vagy módszertan,
9. a megfelelő hozzáállás pedig fontosabb, mint a megszerzett tudás.
10. Egy digitális termék fejlesztésének soha nincs igazán vége, ez egy folyamatos iteráció, csak ugye a határidő vagy budget (vagy a megrendelő) nem így gondolja.
11. A projekt többi résztvevőjét is érdekli, hogy ki, mire és hogyan használja a terméket, oszd meg velük, beszéljetek róla.
12. A visszajelzés nagyon fontos és nem csak kapni, de adni is.
13. Meg kell tanulnod kizárni az egod, amennyire csak tudod!
14. Az egyszerű dolgokat a legnehezebb létrehozni.
15. A csoportosított, priorizált listák rengeteg időt megspórolnak!
16. A munka jó része nem feltétlenül a képernyő előtt történik.
17. Ha teheted, vonj be másokat, gondolkodjatok közösen!
18. Merj hibázni, abból tanulsz igazán!
19. Mindig tűzz ki saját, rövidebb határidőket és kisebb célokat napi szinten!
20. Mindig gondold át, milyen információkra van szükséged ahhoz, hogy haladni tudj és ha valami nincs meg, akkor ne húzd az időt, szerezd be őket!
21. Az élő szó mindig hatékonyabb mint az írás! Ugyanakkor a döntések mindig legyenek transzparensen rögzítve.

Neked vannak ilyen dolgaid? Ha csak egy valamit üzenhetnél a kezdő önmagadnak, mi lenne az?
### Csapat és együttműködés
URL: https://blog.fps.hu/csapat-egyuttmukodes-strategia/
Last updated: 2026-07-17T08:19:00.000Z
A [HVG-n olvastam egy érdekes cikket](https://hvg.hu/tudomany/20200924%5Felte%5Fmta%5Fmax%5Fplanck%5Fpatkanyok%5Fviselkedese%5Fegyen%5Fcsoport%5Fteljesitmeny?ref=blog.fps.hu), ami arról számol be, hogy egy kutatás során feltárták azt a stratégiát, amely lehetővé teszi patkánycsoportok számára, hogy felülmúlják az egyedek önálló teljesítményét a cél megkeresése során.

#### Csapatmunka

Jópár stratégiát kipróbáltam már, hogy minél hatékonyabban működjön egy csapat. *A fogjunk össze együtt erősebbek vagyunk, mint egymagunkban* evidensnek tűnik, de nem olyan egyszerű, mint ahogy hangzik.

> Ha egy nő 9 hónap alatt hord ki egy gyermeket, akkor kilenc nő 1 hónap alatt meg tudja tenni.

– hangzik a hibás projekt menedzser gondolkodást kifigurázó klasszikus geg.

#### Egy ember

Egy feladat elvégzése során egyetlen ember nagyon hatékony és gyors tud lenni. Ez a szereplő, amikor problémája, kérdése van, segítséget kér, de egymaga felel a feladatért.

#### Csapat

Több okból is szükséges, hogy egy feladatot csapatmunkában végezzünk el:

- rövid határidők
- több ember egyesített tudásának kihasználása
- a csapattagok közös munka és egymástól tanulás igénye
- kompetenciák hatékony kiaknázása, párhuzamos munkavégzés
- együttműködés külső szereplőkkel

A fő feladatot fel kell darabolni kisebb feladatokra, azokat pedig szét kell osztani a csapat tagjai között. Az ilyen felbontásnál a megoldás hatékonysága könnyedén rosszabb lehet, sőt sok esetben a feladat elvégzése több időt igényelhet, mint a fentebb leírt, egy ember által végezett megoldás esetén.

A hatékonyságot lerontó tényezők, ha…

- az egyes tagok nem értik a fő feladatot, annak célját
- az egyes tagok megfeledkeznek a célről és csak a részfeladatra koncentrálnak
- a részfeladatok nincsenek megfelelően időzítve
- nincs elegendő, vagy épp túl sok a közös megbeszélés

#### Mi a jó stratégia?

Visszatérve a patkányokon végzett kísérlethez, a kutatók azt találták, hogy:

> „… a csoportokban lévők cselekedetei egyszerű szabályokra bonthatók le: járj ismeretlen utakon, de kövesd a többieket.  
> Megállapították, hogy csoportként való keresés során az egyedek akkor teljesítettek a legjobban, ha megfelelő egyensúlyban volt az önálló felfedezés és mások követése.”  
>  

#### Mit jelent ez számunkra?

Legyen a csapat számára egy jól meghatározott folyamat, amit követhetnek. A folyamat ne legyen merev, fő szerepe, hogy keretet adjon. A folyamatban legyenek megfelelő csomópontok, ha úgy tetszik mérföldkövek. Ekkor kellenek közös egyeztetések, ahol minden egyes alkalommal az eredeti feladatot és célját fel kell idézni. A csomópontok között mindenki a saját útját járja, ha szükséges, akkor szabadon egyeztet másokkal. Így mindenki hozzájárul a saját, és a csapata fejlődéséhez, miközben a feladat hatékonyan halad előre.

Mielőtt „ezek patkányok, mi meg emberek vagyunk” szöveggel jössz, emlékeztetlek rá, hogy több a közös bennünk az emlős állatokkal, mint gondolod. A patkányok génállományának 90%-át magunkban hordozzuk.

Végül nézd meg (újra) az IT Crowd jelenetét a csapatmunkáról:
### logo-v34-final-final-8.ai
URL: https://blog.fps.hu/logo-v34-final-final-8-ai/
Last updated: 2026-07-17T08:19:10.000Z
A pszichológiát a tervezési folyamatoknál elsősorban a UX-design-nal kapcsolatban szokták emlegetni, pedig a grafikai tervezésnél pont úgy jelen van, csak épp „one on one” terápia történik.

Míg egy felhasználói felület kialakításánál támaszkodhatunk célcsoportokra, kutatásokra, tesztekre, addig a grafikai tervezés mögött nem áll tudományos és kézzelfogható háttér.  
Csak a tervező van és az ügyfél, illetve tompításnak közvetítő felek. Mi a tervező nézőpontjából ismerkedünk a céggel, a célcsoportjaival, a tevékenységi körét próbáljuk megtanulni. Ha ezeken túl vagyunk, következik a jó öreg inspirálódás, amikor olyan munkákból táplálkozunk, amik soha nem ügyfélnek készültek, vagy pedig olyan elképesztő szerencse hatására lettek elfogadva, hogy mindenki büszke lehet rá.

Innentől következik a neheze, ugyanis az ügyfelet senki nem szeretné megismerni, nincs benne a gyakorlatban, hogy az ő problémáit, szerelmeit felfedezzük. Ez pedig nagyon nincs így rendben, ha emberekkel, embereknek dolgozunk, az empátiának benne kell lennie a gyakorlatban. Ez a hiba pont úgy jelen van egy kampány tervezésénél, mint egy új arculat létrehozásánál, csak az utóbbiban jobban szembeötlik. Pont ezért az utóbbi alapján írom a gondolataimat.

#### A tervezés

Az első tervezési kör alatt már rögtön szembejön az első probléma: hány tervet küldjünk?  
A bevett gyakorlat 3 kiválasztott terv. Ebből mi már egyet szeretünk igazán, egyet az account, egyet a kreatív, és egyet egy random ember az irodából, aki csak rámutat egy félkész tervre mosdóba menet, hogy „ez de jól néz ki!” (a designereket érdemes a forgalmas csomópontoktól minél távolabb ültetni). Van, aki csak egy tervet küld, hogy „ez az!”. Rizikós játék, mert könnyedén vétózhatják, ugyanakkor lehet hatékony is, és a szakmai szempontok védve vannak. Van olyan, aki 3 teljesen különböző tervvel próbálja kideríteni az ügyfél jellemét. Én is csináltam, de sokszor az jött le ügyféloldalon, hogy nem tudom mit csinálok, hiszen csak lövök mindenre.

Mindenkinek más tetszik, és ha megkérdezzük nekik miért az, akkor kézzelfogható választ nem kapunk. Nem is lehet igazán adni, mi sem tudnánk, csak bullshitet.

Az elküldött tervek után nagy szerencsével az ügyfél kiválaszt egyet, amit tovább kell piszkálni, jó esetben nem a maradékok összegyúrásával. Ha nincs ilyen szerencsénk, akkor új körök jönnek.

Ilyenkor a designer szereti hangoztatni, hogy nem az ügyfélnek csináljuk a logót hanem az ő ügyfeleinek, nekik kell tetszenie. Ámde ha mélyen magunkba nézünk, akkor sajnos be kell vallanunk, mi is magunknak csináljuk a tervet. Már elképzeljük a behance projektet, dribbble likeok számát, vagy a logó hatására exponenciálisan növekvő fizetésünket, a kreatívos cikket, amit csak édesanyánk fog elolvasni.

#### Kiknek dolgozunk

Ahhoz, hogy az ügyfeleknek a megfelelő logókat adjuk, érdemes fejben kitölteni róluk néhány személyiségtesztet és nagyjából felmérni milyen személyiségtípusok. De természetesen ez csak konyhapszichológia, feltevések, és nem érdemes rögtön rásütni valakire, hogy ismerjük és tudjuk mi működik nála, vagy hogy milyen ember. Néhány példa nehezebb esetekről, akikkel már találkoztam.

Még mielőtt bárki megkövezne, olyan személyiségjegyeket emeltem ki, amik bennem is megtalálhatóak (na jó a szociopata talán nem, de ők meg úgysem sértődnek meg).

- például, ha emberünk mérnöki, precíz beállítottságú, érdemes pontosan kimért terveket küldeni már első körben, és klasszikus geometriai elemeket használni.  
Az ilyen típusú embert könnyű felismerni személyesen. Mindene élére vasalt, és kényesen rendben tart mindent maga körül, online beszélgetésnél pedig annyira középen van a képernyőn, mintha csak Wes Anderson rendezte volna.
- ha laza és fiatalos (bár ez a szó elveszti jelentését, ha kimondjuk) akkor érdemes az aktuális trendekkel tisztában lenni és nem kell feltétlenül jelentéstartalommal felruházni az adott logót.  
Az ilyen embereknek általában a beszédstílusok hétköznapi, laza, és nem céges keretek közé sorolódik, viccelődik és ne adj isten jópofáskodik is.
- ha pedig szimplán szociopata (sajnos az bizonyított, hogy felsővezetésben, sikeres üzletemberek körében szép számmal akadnak), akkor nincs más dolgunk, mint a véleménye, ötletei alapján tájékozódni, kihozni a legjobbat a dologból, és beletörődni, hogy talán majd legközelebb szabadon tervezhetünk.  
Az ő típusát a legkönnyebb felismerni, már rögtön hatalmat gyakorol, egy emailben is, sajnos akkor sem fogja elfogadni a tervet, ha épp erre vágyott.
- ritkán, de előfordul például az is, ha a megrendelő introvertált, ez esetben nehezebben törik a jég, lassan ad kézzel fogható választ, véleményt, viszont nagyon könnyű vele a közös munka.  
Online bátrabban kommunikál, nehezebb tetten érni az ízlését, tárgyilagosan alkot véleményt az első interakciók során. Könnyű felismerni a meetingeken, ugyanis nem jön el.

#### Empátia

Az igazi kulcs, ha empátiával fordulunk az ügyfél felé, és nem szakmai egóval, így sokkal könnyebb a közös munka. Nálam is vannak gombok (pl. passzív agresszió), aminek hatására könnyen elvesztem a türelmem. Érdemes ezeket a helyén kezelni, és konstruktívan a munkára koncentrálni, megoldásokat keresni. Szakmai berkekben szokás mondani, hogy hülye az ügyfél, hát sajnos minden ember az, csak mindenki máshogy, köztük mi is.
### Miért nem költenek kutatásra (eleget)?
URL: https://blog.fps.hu/miert-nem-akarnak-kutatasra-kolteni/
Last updated: 2026-07-17T08:19:22.000Z
Amikor megkérlek, hogy gondolj egy közeli hozzátartozódra, és mesélj róla, akkor azt könnyedén meg tudod tenni és hellyel-közzel igaz állításokat is mondasz. Viszont amikor arra kérlek, hogy gondolj az ügyfeleidre, a felhasználóidra, akkor… az egy lehetetlen vállalkozás. Egyszerűen képtelenség több száz, ezer, vagy akár millió embert jól ismerni. Ilyenkor két út áll előtted. Vagy kiragadsz egyetlen, általad jól ismert ügyfelet a tömegből és rá gondolsz. Vagy, és nekünk itt most ez a fontos, egy koncepción, egy modellen keresztül szemléled őket.

### Modell

Ezt a modellt a fejedben pedig a valóságból gyűjtött és megszerzett információk segítségével állítod fel, méghozzá, és ez nagyon fontos: *egyszerűsítéssel*. Ezt a folyamatot hívjuk indukciónak. Aztán később ezt a modellt, ha úgy tetszik, dobozt használod, amikor kommunikálsz az ügyfeleiddel, vagy épp terméket, szolgáltatást fejlesztesz számukra. Ez pedig a dedukció.

![A modellalkotás és modell alkalmazás, azaz az indukció és a dedukció folyamata](https://blog.fps.hu/content/images/2020/08/modellalkotas-modell-alkalmazas-folyamata.gif)

Nyilvánvaló, hogy minél több információt gyűjtesz, annál szofisztikáltabb lesz a modell.

A baj ott kezdődik, ha nagyon kevés információból épül fel a modell, vagy mindent figyelmen kívül hagyva, egyetlen ember modellje és véleménye alapján születnek döntések. Ezt a személy hívja a szakirodalom [HIPPOnak](https://exp-platform.com/hippo/?ref=blog.fps.hu), azaz a leginkább megfizetett személy véleményének. Sajnos, nagyon sok ilyen szervezet van.

![A design döntések mérlege, hippo](https://blog.fps.hu/content/images/2020/08/a-design-dontesek-merlege-hippo.jpg)

Visszakanyarodva az egyszerűsítésre, a modellalkotás folyamatára. Itt jön képbe az ember, mint probléma. Mindig velünk van a baj. Tehát mi emberek, hajlamosak vagyunk torzítani az információkat. Méghozzá nem kicsit, hanem nagyon. Ráadásul tesszük ezt úgy, hogy még csak észre sem vesszük, nem tudatosul bennünk.

### Befolyásoló jelenségek

Most kiemelek a tapasztalataim szerint két fontos jelenséget, torzítást, vagy ahogy más szakterületeken hívják: elfogultságot, amelyek jelentősen befolyásolnak minket.

#### Tudás illúziója

Elmesélek egy rövid kutatást, aminek során Frank Keil és diákjai megkérdezték a kísérletben résztvevőket, mennyire értékelik 1–7-es skálán azt, hogy mennyire értik a hétköznapi tárgyak, mint a cipzár, a toalett, és a golyóstoll működését. Átlagban 4–5-re értékelték az ismeretüket. Ezután Frankék megkérték az alanyokat, hogy részletesen magyarázzák el a tárgyak működési mechanizmusát. Nos, a legtöbbjüknek halvány fogalma sem volt róla.

Ezt hívjuk [tudásillúziónak](https://blog.kolboid.eu/tudasilluzio/?ref=blog.fps.hu), vagyis **hajlamosak vagyunk túlértékelni a tudásunkat**.

Lefordítva az ügyfelekre:

> Azt gondoljuk, hogy jobban ismerjük a felhasználókat, mint amennyire az valójában igaz.

#### Tudás átka

1990-ben a Stanford Egyetemen, Elizabeth Newton két csoportra osztott embereket: „kopogókra“ és „hallgatókra“. Minden egyes „kopogó“ feladata az volt, hogy egy mindenki által ismert dal (pl. a Boldog szülinapot) ritmusát kopogja le egy asztalon, miközben egy „hallgató“ megpróbálja kitalálni, melyik dal lehet az.

Elizabeth megkérdezte a feladat előtt a „kopogókat“, mit gondolnak milyen arányban fogják a „hallgatók“ megfejteni a dalokat. A „kopogók“ ezt 50%-ra jósolták. Az eredmény pedig 2,5% lett. Jelentős a különbség.

Ezt a jelenséget nevezte el Elizabeth a [megszerzett tudás átkának](https://blog.kolboid.eu/miert-nem-tudsz-a-felhasznalok-fejevel/?ref=blog.fps.hu), azaz **nem tudjuk függetleníteni magunkat a meglévő tudásunktól**.

Lefordítva ügyfeleinkre:

> Sokkal több ismeretet feltételezünk a felhasználókról, vásárlókról, mint, ami valójában rendelkezésükre áll.

Nem tudom te, hogy vagy vele, de elég sokszor hallom: eleget, sokat tudunk az ügyfeleinkről, akár magunkat is beleértve.

Tapasztalataim és véleményem szerint **a tudás illúziója, és a tudás átka a legfőbb okai, amiért a cégek, ügyfelek kevésbé hajlandóak kutatásra költeni.**

#### Tudományos módszertanok

Jelenleg majd 200 ilyen torzításról, elfogultságról tud a tudomány. Botorság azt gondolnod, hogy [racionális lény az ember](https://blog.kolboid.eu/racionalis-e-vagy/?ref=blog.fps.hu). Épp a torzításaink miatt, fejlődtek ki a tudományos módszertanok, hogy minél objektívebbek, racionálisabbak legyenek a kísérletek, kutatások. Gyakorlatilag az a cél, hogy kiiktassuk az embert, és az ő gyengeségeit az egyenletből.

![Darth Vader Einstein ellen, azaz tudomány vs fikció](https://blog.fps.hu/content/images/2020/08/tudomany-vs-fikcio.gif)

**Nem kérdés, hogy kutatni kell.** Kutatnod kell, hogy minél jobban megismerd a felhasználóid, kifinomultabb legyen a modelled. Költs rá!
### Isten hozott az ígéret földjén
URL: https://blog.fps.hu/isten-hozott-erett-digitalis-kor/
Last updated: 2026-07-17T08:19:32.000Z
És ahogy az Úr megígérte, bevezette népét Kánaán földjére. Megtörtént hát végre. Vicces, de egy vírus által. E-kereskedelmi oldalakat üzemeltető ismerőseim egyöntetűen arról számolnak be, hogy az ügyfélszolgálatokon megjelent egy új, masszív tömeg, akiknek az alapokat kell elmagyarázni: hogyan működik a kosár, hogyan tudnak online bankkártyával fizetni. A nép utolsó csoportjai épp most kelnek át a Jordánon. A digitális kor ebben a percekben lép érett szakaszába.

Ennek a digitális világnak viszont van egy fontos tulajdonsága, és ez következetesen felszámolja az évszázadok óta belénk égett gondolkodásmódot, miszerint **fogadd el, amit mondanak neked, fogadj el mindent úgy, ahogy van**. Tetten érhető számos területen, gondolj csak az oktatásra, vagyis a kényszer „digitális” oktatásra. Sok tanár rá akarja erőltetni a tanulókra az általa jónak gondolt megoldást. A diákok meg nem értik. Sőt lázadnak ellene, mert nyilvánvaló hülyeség. Nekik, mint digitális bennszülötteknek.

Ebben az univerzumban alapvetés, hogy **azokhoz kell a megoldásaid formálni, akik azt igénybe veszik**. Foglalkoznod kell velük. Nem erőltetheted rájuk az akaratod, a rendszered. Ha mégis így teszel, mást választanak. Márpedig ebben a világban óriási a kínálat, és szolgáltatást váltani igazán nem tart semmiből. Az elcsépelt mondattal élve: *minden csak egy kattintásra van*. És ez szép fokozatosan alakítja az emberek gondolkodásmódját.

Nem mellékesen pedig hamarosan elkövetkezik a digitális terméktervezők aranykora is, hiszen ők azok, akik segítenek megismerni a célközönséget, és olyan digitiális termékeket tervezni, ami az embereknek, és az üzletnek is jó.

Na persze a Kanaán sem fenékig tejfel…

*A [fejléckép Dan Cretu](https://www.instagram.com/p/B-2DI-pBnyo/?ref=blog.fps.hu) munkája.*
### Építs hagyományt és műveljük meg kertjeinket!
URL: https://blog.fps.hu/epits-hagyomanyt/
Last updated: 2026-07-17T08:19:41.000Z
Ne aggódj, most is a design systemről fogok írni, csak kicsit másképp.

Hogy én mennyire csapkodtam kötelezőként Voltaire Candide-ját. Tán még arra is vetemedtem, hogy hangosan hülyézzem a címszereplőt infantilizmusa, és naivitása miatt.

> *Tényleg elveszted Eldorádó kincseit?! Te barom!*

Persze a lila köd után megértettem, mit is jelentett a *„műveljük meg kertjeinket”* és később tán helyére is került a leibnizi hurráoptimizmus ellentéteként. Kicsit most is úgy érzem, hogy hasonló korban járunk, de ezt majd korunk Voltaire-e megírja.

### Beszéljünk inkább a hagyományokról.

Hagyomány: *„Régebbi korokból, néha írott feljegyzésekben fennmaradt v. íratlanul, többnyire nemzedékről nemzedékre szálló és vmely közösségben továbbra is érvényesülő szokás, erkölcs, ízlés, felfogás.”* – a Magyar Nyelv Értelmező Szótára alapján.

Ha pedig a wikipedia szómagyarázatát nézzük, akkor: *„…nemzedékről nemzedékre változatlan formában tesznek és készítenek…”* – is olvasható. Tán e kettő az, ami jellemzően él az emberekben a hagyományokkal kapcsolatban.

Nem vagyok az a „hagyományőrző” típus, viszont a hagyományok rugalmasságát lenyűgözőnek tartom. Arra a rugalmasságra gondolok, hogy mindig képesek alkalmazkodni és idomulni a kor változásaihoz. Tudom, ez épp az ellenkezőjét mondja a fenti meghatározásnak, ám hadd világítsak rá.

Vegyünk egy példát. A házasság. A házasság egy globális hagyomány, ami egy sajátos kapcsolati formaként jelenik meg a történelem kezdetétől. Létezik monogámia, bigámia, poligámia, vegyes– és rokonházasság, meg még ki tudja mennyiféle verziója?!

Vannak helyek, ahol még mindig kasztok, vagy címek alapján házasodnak az emberek, és vannak, ahol már a nemek azonossága se számít.

Ha csak a magyar (államalapítás utáni) történelmet nézzük, itt is volt már pár kanyar házasság-ügyben. Az egyik ilyen legnagyobb változás II. Józsefhez köthető, aki megpróbálta bevezetni a ma is ismert házasság fogalmát. Ő volt, aki a polgári házassággal nemcsak az egyházról az államra ruházta az intézményt, hanem a vegyesházasságok problémáját is megpróbálta orvosolni. [Skandalum!](https://hu.wikipedia.org/wiki/Botr%C3%A1ny?ref=blog.fps.hu) Mondták akkortájt a vallási oldalak résztvevői, felekezettől függetlenül. Micsoda ökumenizmus?! Így bele is telt 100 évbe, mire ezt sikerült rendezni, mi is történjen egy katolikus apa, református anya leendő gyermekével.

Ha az egyház szemszögéből nézzük, II. József súlyosan sértette az egyházak hatáskörét, ám a történelem később mégis őt igazolta. Ha nem indítja el a polgárság körében már égető igényként jelentkező reformokat, akkor tán már nem is lenne házasság. Azaz lehet, hogy lenne valami hasonló, de azt nem házasságnak hívnánk.

Ha egy hagyomány túl merev, akkor az eltörik, ami azt jelenti, hogy megszűnik. Az emberek számára inkább csak teherré és nyűggé válik, így elhagyják, elfelejtik, majd túllépnek rajta.

### Nincs ez máshogy a design systemekkel sem.

Léteznek rendszerek, amik még szájhagyomány útján élnek, ám ez magában hordozza azt is, hogy torzul a rendszer és formálódik – olykor a nem kívánt formában. Mondhatnánk: organikus. Mondhatnánk, de inkább a hagyományőrzők memóriáján és saját érdekeik mentén formálódik. És vannak, ahol már megjelent az írásosság. Itt viszont a kialakított szabályok és útvonalak azok, amik olykor túlontúl merevvé tehetik a rendszert. Nem könnyű megtalálni az arany középutat, és őrzőként védeni a művet, egyben reformerként meghallani az idők szavát.

Kicsit Candide-ok vagyunk mostanság mindnyájan. Még csak most kezdődött viszontagságokkal teli utazásunk, ám lehet, hogy nagy segítségünkre válik, ha most elfogadjuk *„e világ a legjobb minden elképzelhető világ közt”*. A végén úgyis lesz mit művelni kertjeinken.

#### Köszönöm, hogy elolvastad. 👋

**A fejléckép:** Paul Gaugain – [Tahitian Landscape](https://www.metmuseum.org/art/collection/search/436451?ref=blog.fps.hu)
### A UX kutatás haszna
URL: https://blog.fps.hu/ux-felhasznaloi-kutatas-haszna-esettanulmany/
Last updated: 2026-07-17T08:19:51.000Z
*„20 embert megkérdeztek? Á, az nem ér semmit…”*, *„Minek beszéltek felhasználókkal? Ismerjük őket, felesleges pénzkidobás.”*, *„Amúgy meg van piackutatásunk is, pontosan tudjuk mi kell nekik.”* és hasonló kijelentések hangzanak el számtalanszor. Az egyik legnagyobb hazai székhelyű pénzintézet projektjén keresztül mutatom meg, hogy a fenti mondatok nagyon is tévesek.

TL;DR  
*A projekt egy \~4 hónapot felölelő újratervezés (redesign) volt, melynek során természetesen UX kutatást is végeztünk. Lehetőség volt a korábbi és az újratervezett termék egyidejű mérésére, összehasonlítására. A konverziót 10%-kal megnöveltük kizárólag fehér sapkás módszerekkel.*

A bevezetőben olvasható kétkedések hátterében, elsősorban [a megszerzett tudás átka](https://blog.kolboid.eu/miert-nem-tudsz-a-felhasznalok-fejevel/?ref=blog.fps.hu) húzódik meg:

> Nem tudjuk függetleníteni magunkat a tudásunktól.

Igaz ez minden emberre, így az ügyfelekre is. Sokkal több ismeretet feltételeznek a felhasználóikról, vásárlóikról, mint, ami valójában rendelkezésükre áll. Az aggályt másodsorban erősíti, hogy az ügyfelek nem értik a piackutatás és a UX kutatás közötti alapvető különbséget.

### Hogyan indult

Fiktív Kálmán megkeresett, hogy van egy személyi kölcsön kalkulátoruk, aminek a konverzióján szeretne növelni. A konverzió itt a kölcsön után érdeklődők adatainak gyűjtését (lead generálást) jelenti. Leültünk, beszélgettünk, nézegettük a felületet, közösen gondolkodtunk. Aztán tettem egy kijelentést – amit egyébként nem szoktam! –, miszerint képesek lennénk 3%-kal megnövelni a konverziót. Kálmán osztott, szorzott, mondott egy büdzsét, ami elegendőnek tűnt, kezet fogtunk, és elindult a munka.

### A projekt

Azt valljuk, hogy kutatás nélkül nem szabad tervezni, pláne nem kivitelezni. Így természetes, hogy ezzel a szakasszal indult a folyamat.

![a projekt, a tervezés szakaszai, lépései](https://blog.fps.hu/content/images/2020/03/tervezes-szakaszai-lepesei.gif)

#### Üzleti oldal

A kutatást mindig azzal kezdjük, hogy megismerjük az üzleti oldalt, az üzleti célokat, az üzleti modellt. Nem utolsó sorban közösen meghatározzuk a siker kritériumokat.

##### Folyamat, szervezet

Elsőként feltérképeztük a személyi kölcsön termék teljes folyamatát, kezdve azzal, hogy a felhasználó benyújta igényét a kölcsönre, egészen addig, hogy az összeget folyósítják számára. A folyamat egyes lépéseinél a pénzintézet különböző szervezeti egységei érdekeltek, ezeken a pontokon beszélgettünk (stakeholder interjúk) a megfelelő munkatársakkal.

##### Követelmények

Emellett összegyűjtöttük a követelményeket, többek közt a jogi osztálytól a kötelezően feltüntetendő elemeket, az arculati elvárásokat.

##### Versenytárs elemzés, best practice kutatás

Természetesen versenytárs elemzést is végeztünk, 10 hazai hasonló online eszközt vizsgáltunk meg és jegyeztük fel erősségeiket, gyengeségeiket. Best practice kutatás keretében pedig átnéztünk jónéhány külföldi releváns oldalt és összeszedtük a jobbnál-jobb megoldásokat.

##### Célcsoport

A marketing osztály elmesélte, hogy ki a banki termék célcsoportja, milyen vásárlói személyiségeket (buyer persona) különböztetnek meg, ezekhez kaptunk rengeteg piackutatási anyagot. Ennél pontnál szokott lejátszódni a következő diskurzus:

– Na, elegendő ismeretetek van a felhasználókról, lehet rajzolni, fejleszteni és mehet is élesbe!  
– Ácsi! Még nem ismerjük eléggé a felhasználókat!  
– De hát, ott vannak a piackutatási anyagok, az nem elég?  
– Nem, mert…

#### Felhasználói oldal

A [piackutatás nem válaszolja meg](https://medium.com/@reassembleux/market-research-vs-user-research-are-they-the-same-3ec59dec637f?ref=blog.fps.hu) a „Mi hasznos a felhasználónak?” rendkívül fontos kérdést és nem, a [fókuszcsoportos kutatás sem elegendő](https://medium.com/mule-design/focus-groups-are-worthless-7d30891e58f1?ref=blog.fps.hu) kigészítésnek. Sőt, nem elég tudnunk „mit csinálnak” a felhasználók, hanem azt is meg kell értenünk, „miért csinálják”.

Meg kell ismerni a felhasználók [mentális modelljét](https://blog.kolboid.eu/ne-menj-szembe-a-mentalis-modellel/?ref=blog.fps.hu), azaz nekik mi az elképzelésük a kölcsönigénylés folyamatáról, számukra milyen lépésekből áll. Szerencsénkre ez esetben a mentális modell megegyezett a banki valósággal. Ami még elképesztően fontos: ki kell deríteni, hogy mik a felhasználók fájdalmas pontjai, milyen félelmeik vannak, milyen kérdések merülnek fel bennük! Ha ezekre a kérdésekre megvannak a válaszok, akkor tudjuk megszüntetni a felhasználók bizonytalanságát.

Szerencsére a pénzintézetnél nyitottak voltak és értették, hogy szükség van még kutatásra.

##### Személyes mélyinterjú

Ennél a projektnél beleütköztünk abba a rideg korlátba, hogy közvetlen nem tudtunk beszélgetni az igénylőkkel (felhasználókkal), ugyanis abban a pillanatban, ha egy ember kapcsolatba lép a bankkal, akkor önmagában ez a kapcsolódás banktitoknak minősül, vagyis ezt mi, mint harmadik fél, nem tudhatjuk.

A folyamatot átnézve láttuk, hogy több olyan pont is van, ahol a banki ügyfél kapcsolatba lép a pénzintézet munkatársaival, ezért nem volt más dolgunk, minthogy az alábbi szereplőkkel készítsünk mélyinterjút:

- call centeresek – akiket felhívnak személyi kölcsönnel kapcsolatos kérdéseikkel – *hihetetlen sok és hasznos információ van a birtokukban*
- mobil bankárok – akik személyesen találkoznak a személyi kölcsönt felvevőkkel, és kötik meg a szerződést

##### Telefonos interjú

Ezeken felül pedig együttműködve a pénzintézet kutatási csoportjával kreáltunk forgatókönyvet, ami alapján a call centeresek készítettek előzetes beleegyezés után telefonos interjúkat, amiket végül leirat formájában kaptunk meg anonim.

Kiemelek három kérdést, amik a felhasználói kutatás során kerültek felszínre:

1. Mikor kapom meg a kölcsönösszeget?
2. Van hitelfedezeti biztosítás?
3. Elő– és végtörlesztésre van lehetőség?

Miért ezt a hármat a sok közül? Nos, azért, mert **sem a korábbi oldal, sőt egyetlen versenytárs sem adott választ ezekre a kérdésekre**.

##### Kutatási összefoglaló

Oké, megértettük az üzleti célokat, megértettük a felhasználói igényeket, most már **definiálni tudtuk a valóban megoldandó problémákat**. Az első fázisban összegyűjtött információkat egy kutatási összefoglalóban adtuk át az ügyfélnek, ami rendszerint segít összerendezni nekik is, a fejükben már sokszor meglévő információkat, kiegészítve az újonnan felfedezettekkel. Az anyag végén megfogalmaztunk tényleges tervezési irányelveket, és feltettük a releváns „Hogyan tudnánk…” kérdéseket.

#### Koncepció

Ötleteltünk közösen (brainstorming), majd kiválogatva a jó és életképes ideákat, megterveztük és kidolgoztuk a folyamatot.

#### Drótok, prototípus

Számtalan a felhasználói kutatásból kiesett ismeretet használtunk fel az információs architektúra (IA), majd a drótvázak (wireframe) készítésénél. Az információk, funkciók fontossági sorrendet, prioritást kaptak üzleti cél és felhasználói igény szempontjából, ez segített a felületen az információk elhelyezésében, a megfelelő hangsúlyokban.

![a személyi kölcsön kalkulátor drótvázai v3](https://blog.fps.hu/content/images/2020/03/kalkulator-drotvaz-wireframe-v3.gif)

A drótvázat, később az egyszerű funkcionalitással rendelkező prototípust felhasználók kezébe adtunk, és azok alapján finomítottunk.

#### Design, fejlesztés

A pénzintézet arculati kézikönyvének megfelelő grafikai design készült, majd egy külső fejlesztő csapattal együttműködve elkészült a termék. Értelemszerűen szintén teszteltünk felhasználókkal, ami alapján 2 körben csiszoltunk a működésen.

#### Mérés

Végre kikerült élesbe, de egyelőre minimális forgalmat terelve rá. Hotjart tettünk az oldalba és a rögzített videók alapján ismét optimalizáltunk. Most már nagyobb forgalom lett irányítva az eszközre, ami első ízben mérés alá is került. Előzetes eredményként 5%-os konverzió növekedést tapasztaltunk a korábbihoz viszonyítva, de ezt a mérést még nem tekinthettük egzaktnak. Az újabb hotjar videók, és egyéb tesztelések alapján elvégezett tökéletesítések után, végre eljött a nagy pillanat.

### Eredmény

A teljes forgalom minden forrásból 50–50%-ban ment a két változatra, és a szignifikáns eredmény:

10% konverzió növekedést hozott a korábbi változathoz képest.

Mindezt úgy, hogy

- **NEM alkalmaztunk pszichológiai trükköket**, nem használtuk ki az emberek kognitív torzításait a lead generálás érdekében,
- **a felhasználók elégedettségét növeltük** kényelmi funkciókkal és a bizonytalanságuk csökkentésével, ami egyben erősíti kapcsolatukat a pénzintézettel, annak márkájával,
- a korábbi oldalon sok, eleve kölcsönre nem jogosult ügyfél jutott át, ezeket a kapukat lezártuk, sőt, ahol lehetett más terméket javaslunk nekik, ergo elirányítjuk más oldalra.

A projekt elején jeleztük az ügyfélnek, hogy a lead generálás önmagában nem elegendő mérőszám (KPI). Ki kell egészíteni azt a tényleges folyósítások számával, vagyis az online eszköznek minőségi leadet kell szállítania. Ennek mérése még folyamatban van, aminek eredményére még várnunk kell. Igaz, meg vagyunk győződve róla, hogy ez az érték is bizonyosan emelkedik. Egyébként a termék megváltozik, de azután, már az általunk tervezett online eszköz kerül élesbe a felhasználók elé.

Azt pedig sejted, hogy ez **a növekmény elég gyorsan visszahozza a projektre elköltött forintokat**.

A 2020-as Evolution konferencián előadás formájában is elhangzott, melynek diái:

*Köszönet az ügyfélnek a konstruktív hozzáállásért, és a közös munkáért, ami fontos feltétele a sikernek, és persze külön köszönet az fps design csapatnak a mindig zseniális munkájukért.*
### Meddig kell még designer?
URL: https://blog.fps.hu/meddig-kell-meg-designer/
Last updated: 2026-07-17T08:20:02.000Z
#### Vajon a design systemek felváltják majd a designereket?

*Tettem fel a kérdést a január 28-ai [miskolci ITrend meetupon.](https://www.meetup.com/ITrend/events/266658204/?ref=blog.fps.hu) Ez a poszt az ott elhangzott előadásom bővített változata.*

Nagy vonalakban arra szeretnék rávilágítani, hogy mi lesz a következő években a designer szakmával. Vajon a design system feleslegessé teszi majd a szakmánkat? Egy varázsütésre elég lesz csak megrázni a dobozt és kidobja a digitális terméket? Egyszer. Biztosan. Ám addig is…

Hogy miért a kissé provokatív cím? **Beszéltél az elmúlt 5 évben designerrel?** Kicsit olyan volt, mintha most találta volna fel a forró vizet? Valószínű. „Fiatal” szakma, átültetett módszerekkel és olyan gondolkodásmóddal, amiket még nem alkalmaztak ezekből a nézőpontokból. Ha így tekintünk rá, akkor ez egy természetes folyamat. Éppen ezért sokszor futunk bele, amikor úgy gondoljuk, hogy olyan tudás birtokosai vagyunk, amiről másnak is tudnia kell, és ezt mindenáron szeretnénk megosztani. *Hogy ennek mi a mozgatórugója? Az inkább egy másik cikk lenne.*

Most még egy folyamat elején vagyunk, amikor arra kezdünk rájönni, mit is csináljon a designer. Persze nem az, akit 10 évvel ezelőtt designernek hívtunk, hanem napjaink designere.

Hogy választ tudjak adni a címben felvetett kérdésekre, először tisztázzunk két fogalmat. Ki a designer, és mi a design system?

#### A designer

![what-people-thinks-i-do](https://blog.fps.hu/content/images/2020/03/what-people-thinks-i-do.png)  
Ismered a „what people thinks i do” mémeket? A családom–, a barátaim–, a főnököm szerint mit is csinálok? Manapság ha egy termék nem jól, vagy nem úgy működik, ahogy azt a felhasználó szeretné, akkor már megjelennek azok a hangok is, akik azt mondják: *Ki tervezte ezt?*

Ez az evolúciója egy szakmának. Szerencsére. Tudnak rólunk, felkerült a térképre a designer szakma.

Ám, ha valóban arra vagy kíváncsi, hogy mivel foglalkozik egy designer, akkor a végletekig leegyszerűsítve pontosan azt, mint mindenki más:

> Döntéseket hoz.

Design döntéseket. Olyan, a tervezést érintő problémákra keresi a választ, amik egyre inkább összetettek és egyre rétegesebben működnek. Éppen erre reflektál, mennyi különféle titulussal rendelkező designer lett napjainkra.

![designer-evolution](https://blog.fps.hu/content/images/2020/03/designer-evolution.png)

Számtalan szempont, megannyi döntés. És mivel minden szentnek maga felé hajlik a keze, célszerű inkább a döntéseket csokorba foglalni.

Nem véletlenül lépett színre pár évvel ezelőtt a **design system** kifejezés.

#### Mi a design system?

A leginkább elfogadott nézet szerint:

> Design system is not a project. It's a product, serving products.

– idéztem Nathan Curtistől, aki Dan Brownnal együtt alapították az [EightShapes-et.](https://eightshapes.com/?ref=blog.fps.hu)

Én egy kicsit ennél mostanra tovább merészkedtem. Ebben remek kapaszkodó volt **Hayley Hughes,** az IBM, majd Airbnb, most pedig a Shopify egyik vezető designere.  
[Egy tavalyi előadásában](https://youtu.be/mq984Mc9UVA?ref=blog.fps.hu) találkoztam az alábbi piramis diagrammal.

![design-system-hierarchy-1](https://blog.fps.hu/content/images/2020/03/design-system-hierarchy-1.jpg)

Ez alapján három–, egymásra épülő alrendszerre lehet bontani a design systemet:

- komponensek rendszere
- történetek (útvonalak) rendszere
- értékek rendszere

*Hughes piramisa az [Ethical Design Manifestojára](https://2017.ind.ie/ethical-design/?ref=blog.fps.hu) épül, ám ő újrarandezte az ott megjelent szinteket, amivel én nem értek egyet.*

Gyorsan fussunk végig a szinteken, hogy mit is tartalmaznak, és miért is van hatással a legmagasabb döntési szintekre is egy design system.

##### Komponensek rendszere

Manapság, amikor rákeresünk arra, hogy design system, sok esetben látunk egy szép nagy elemkészletet, amik tartalmaznak színeket, betűket, formákat, eltartásokat. Jobb esetben ezek valóban koherensek, és fel is lehet építeni ezekből egy termék felhasználók számára használható felületét. Igen ám, de attól, hogy ezek bármilyen rendszert alkossanak, nem elég csak a következetesség. Ahhoz, hogy ezt valóban alrendszernek tudjuk tekínteni, 4 kritériumnak kell megfelelni:

- következetes
- mérhető
- újrafelhasználható
- dokumentált

Mindezek segítik a későbbiekben a módosítást, és mindazt, amitől tovább tudjuk használni ezeket a komponenseket, mint rendszer.

Az előbbiekből látszik, hogy itt már a designernek ki kell lépnie abból a körből, amikor a hozzá hasonló nyelvet beszélő emberekkel kell megértetnie magát. Itt már megjelennek a fejlesztők, mérnökök, analitikusok, akiknek szintén létezik egy nyelvezetük a saját rendszerükre. Sőt, mivel ők lesznek végső soron, akik formába öntik, vagy visszamérik ezeket az elemeket, célszerű ezt a nyelvet, ezeket a fogalmakat már az elején beépíteni.

Hisz miben is létezik egy rendszer? A környezetben. A környezete lévén kap értelmet, és egyben a környezete által tudja meghatározni a rendszer saját magát.

Így történhet, hogy lassan a UI designereknek nem is az lesz a feladatuk, hogy komponenseket „rajzoljanak”, tervezzenek, hanem, hogy kontextusba tudják a meglévőket helyezni, és szabályt tudjanak alkotni a működésükről.

##### A történetek rendszere

Attól, hogy lettek komponensek, amik rendszerben működnek, még azokat nem pakolgathatjuk csak úgy egymásra, vagy egymás mellé.

![disney-disney](https://blog.fps.hu/content/images/2020/03/disney-disney.png)

Azaz megtehetjük, csak akkor ne csodálkozzunk, hogy egy Disney kastélyt építünk, amikor mi egy Star Wars lépegetőt (AT-ST) akartunk.

Persze mondhatnánk, hogy Disney–Disney. Ám, pont itt rejlik a lényeg. A történetben. Sokszor érezhetjük, hogy ugyanazt a történetet mesélik el nekünk újra és újra, csak a szereplők és a helyszínek mások. Egyiknél hercegnő, boszorkány, kastély, másiknál hercegnő, Darth Vader, birodalmi csillagromboló.

![design-process](https://blog.fps.hu/content/images/2020/03/design-process.jpg)

Mi határozza meg a történetet? A kulcs itt a felfelé és lefelé kommunikáció. Vagyis hogyan és miként gyűjtik be a designerek az adatokat, azokat hogyan rendszerezik és adják tovább. Igazából ezen a szinten rajzolják meg a térképet. És itt most nem csak a user journeys map-re gondolok, hanem azokra a módszertanokra, eszközökre, amik segítik az absztraktból a konkrét felé vinni a terméket.

Ez sok esetben egy szerteágazó és folyamatos döntések láncolata, aminek a végén egy rosszul adoptált vagy interpletált adatból akár Csipkerózsika is lehet a Birodalom visszavágból.

##### Az értékek rendszere

Ezen a szinten születnek azok a döntések, mely egy termék, szolgáltatás lényegét, irányát meghatározzák. Ahol az absztrakció születik. A fenti képen látható, hogy tervezés szempontjából egy termék születésénél két meghatározó tényező áll fenn:

- az üzleti célok
- és a felhasználói igények

Ha elfogadjuk, hogy a design system idáig nyúlik, akkor látható, hogy a korábbi két lépcső a későbbiekben mennyire visszahat majd erre a szintre is. A termék folyamatos csiszolgatása során lényegesen nehezebben haladhatunk, ha a korábbi szintek ad hoc jelennek meg, mintsem egy rendszer részeként.

Mindezeken felül napjainkban az üzelti döntések és célok meghatározásánál is egyre erőteljesebben megjelent a designgondolkodás. Ezek mind módszertanok, mind felhasználói oldalról való megközelítés formájában (lsd. service design, design thinking) épülnek be egyre gyakrabban a vezetői mechanizmusokba. Azonban a design vetületét tekintve, alapok nélkül, ezek a döntések sok esetben csak pusztába kiáltott szavak maradnak.

#### És akkor lesznek designerek vagy sem?

Mielőtt felvázolom a véleményem, előtte tegyünk még egy kis kitérőt.

![the-end-of-naval-gazing](https://blog.fps.hu/content/images/2020/03/the-end-of-naval-gazing.png)

Egy ideális szervezetet a fenti egységekre lehet osztani. Legalábbis Paul Adams tervező szerint, akinek [volt egy jó előadása](https://vimeo.com/275265188?ref=blog.fps.hu), ahol saját példáján és felismerésén keresztül bemutatta, hogy a „UX”, a tervezés nem a központja egy szervezetnek – bármennyire is szeretnénk ezt gondolni –, hanem egy része.

A design, mindig is része volt egy szervezetnek, ám volt, ahol kevésbé domborodott ki. Attól még, hogy nem volt dedikált design csapat, a design döntéseket meghozták.

![company-structure-design](https://blog.fps.hu/content/images/2020/03/company-structure-design.png)

Ezek alapján, ha a korábban bemutatott piramist a szelethez illesztjük, akkor látható, hogy a design system végre egy használható, visszamérhető és megismerhető alap lesz a közös kommunikációra, ami segít majd a vezetőknek a helyes döntések meghozatalában.

Ám naivitás lenne azt gondolni, hogy ezen a szinten a design lesz az, ami meg kell, hogy határozza az összes döntési mechanizmust. Itt már figyelembe kell venni az szervezet összes egységének a rendszerét, legyen szó management–, sales– vagy financiális rendszerről.

![company-structure-all](https://blog.fps.hu/content/images/2020/03/company-structure-all.png)

Az igazság az, hogy valamilyen szinten az összes szervezeti egységnek megvan a saját rendszere. Ha pedig ezeket a szeleteket egy palástként visszahajtjuk, akkor a vezetői döntéseket megalapozott információk mentén tudják meghozni.

Emlékeztek még a sok titulusra?

![designer-evolution-future](https://blog.fps.hu/content/images/2020/03/designer-evolution-future.png)

Egyre inkább az lesz a jellemző, hogy a design gondolkodás elterjed. Felbukkan, akár akreditált szereplőként más-más szervezeti egységben, vagy csak maga az egységen belül honosodnak meg a tervezéssel kapcsolatos módszerek, gondolkodásmódok.

Így, a végére azt hiszem kijelenthetem, hogy a designerek megmaradnak, sőt lehet, hogy többen is lesznek, a gondolkodásmódjuk, eszközeik pedig szép lassan megismerhetővé és beépíthetővé válnak.

Hogy aztán pedig mi lesz, amikor felépítettük a rendszerünket? Majd megrázzuk a dobozt.

#### Köszönöm, hogy elolvastad. 👋

Kapcsolódó prezentáció

A prezentáció diái

**[Meddig kell még designer? | Vajon a design systemek felváltják majd a designereket?](//www.slideshare.net/tomkato944/meddig-kell-mg-designer "Meddig kell még designer? | Vajon a design systemek felváltják majd a designereket?")**  from **[Tom Kato](//www.slideshare.net/tomkato944)** 

  
Források amik segítettek és irányba állítottak az előadással kapcsolatban.

- [Hayley Hughes – The Future of Design Systems](https://youtu.be/mq984Mc9UVA?ref=blog.fps.hu)
- [Paul Adams – The End of The Navel Gazing](https://vimeo.com/275265188?ref=blog.fps.hu)
- [Ethical Design Manifesto](https://2017.ind.ie/ethical-design/?ref=blog.fps.hu)
### Mitől senior egy szakember?
URL: https://blog.fps.hu/mitol-senior-szenior-egy-szakember/
Last updated: 2026-07-17T08:20:11.000Z
A témában erősen megoszlanak a vélemények. Nekem is megvannak a saját meglátásaim, amit most megosztok veled. Mindenféle kategóriába szuszakoljuk a szakembereket, melynek alapvetően az a célja, hogy egyfelől a jövedelemhez adjon támpontot, másfelől az egyén a saját tudásszintjét meg tudja határozni, és persze mindezeken felül a szervezetnek, vezetőknek is ad(hat) segítséget a csapatok összeállításában, szervezésében.

Ideális lenne, ha a fentiek mind egyidejűleg megvalósulnának. Biztosan van is olyan cég, ahol precízen definiált, hogy adott terület, adott szakembere milyen szinteket érhet el, és azokhoz pontosan mit kell tennie.

### Szintek

A fokozatok elnevezése sem egységes, de talán a leggyakrabban használt megnevezések: a gyakornok, a junior, a medior és a senior.

Az egyes szintek eléréséhez szokták kötni az alábbiakat:

- mindenféle tudáshalmaz az adott szakterületen belül
- szakmában eltöltött idő – bár ez egy fura dolog, ugyanis nem feltétlen lesz valakiből senior, csak mert 100 éve dolgozik egy területen
- megszerzett tapasztalat – összefügg az idővel, mert át kell élni sokféle problémát, különböző helyzetet, hogy utána azokat magabiztosan tudja kezelni
- soft skillek – és fejlesztésük – kevés olyan munkakör van, ahol nem dolgozunk csapatban, vagy más emberekkel
- mentorálás – azaz a gyakornok, junior kollégák fejlődését támogatja, segíti
- képzések, előadások tartása – igazából bónusz, de van, ahol ezt hozzákötik a senior fokozathoz
- végül pedig a **hozzáállás**

### Hozzáállás

Ez az iromány valójában ezért született, mert azt gondolom, hogy **a senior szakember legfontosabb ismérve a hozzáállása**, kiegészítve a fentiekkel.

#### Mit értek ezen?

1. Tisztában van azzal, hogy minden munka 70%-a lapátolásból áll és a fennmaradó 30% az, amiért csinálja, amiben örömét leli.
2. Mindig a miérteket keresi egy projekt kapcsán.
3. Nem öncélú, azaz a projekt célját tartja szem előtt, és nem azt, ő mit akar, mit szeretne megtanulni, elérni.
4. Megértette, hogy a világ tökéletlen. Nincs ideális, tankönyvszerű projekt. Mindig lesznek benne idióták, mindig lesznek olyan elvárások, korlátok, melyek miatt nem lesz és lehet tökéletes a projekt. DE! **Teljes erejével és tudásával törekszik arra, hogy a lehető legjobbat hozza ki a lehetőségek halmazából**.
5. Nem hibáztatja a projekt ilyen-olyan résztvevőit, nem mutogat másokra, vállalja, ha valamit rosszul csinált, és inkább keresi azokat a pontokat, hogyan lehet legközelebb kiküszöbölni a melléfogásokat.
6. Tud nemet mondani és vállalja a konfrontációt, amikor szükséges.
7. Nem dolgozza túl magát, mert már kiégett legalább egyszer pályafutása során, vagy nem, de tudja, hogy szükség van testedzésre, szórakozásra, pihenésre is…

**Te mit gondolsz?**
### Törjük a jeget
URL: https://blog.fps.hu/stinkyfish-budoshal/
Last updated: 2026-07-17T08:20:20.000Z
Aki facilitált már workshopot, tisztában van az icebreakerek fontosságával. Ezek a játékos gyakorlatok segítenek feloldódni a résztvevőknek, rávezethetjük őket a következő feladatokra, de akár a közös nevezőre jutást is elősegíthetik. Bár nem klasszikus jégtörő, mégis az egyik kedvenc erre alkalmazott eszközünk a „stinky fish”, vagyis a büdös hal.

> A büdös halakkal az a gond, hogy ha a szőnyeg alatt maradnak, akkor még büdösebbek lesznek. Tegyük hát ki őket az asztalra!

Ez a metafora a munkánkra fordítva azt jelenti, hogy minden résztvevőben lehetnek aggályok, feszültségek, kérdőjelek az adott témával, feladattal kapcsolatban, amik teljesen természetes érzések, amikről szabad beszélni. Fontos, hogy ez mindenkiben tudatosuljon. A büdös hal gyakorlattal ezeket a feszültségeket mindenki kiadhatja magából, a többiek pedig meghallgatják: ez segíti az empátiát, érzékenyülünk egymás felé.

Megoszlanak a vélemények arról, hogy szerencsés-e egy ilyen, a negatívumokra koncentráló gyakorlatot egy projekt kickoffon végezni. A tapasztalataink azt mutatják, hogy abszolút, sőt! Ha megoszthatjuk a félelmeinket a többiekkel, akkor ez feloldást ad, meg lehet egymást nyugtatni, lehet reflektálni a felvetett aggodalmakra. Senki nincs elnyomva, mindenki meghallgatásra talál, sőt mi, tervezők is megoszthatjuk a saját félelmeinket az ügyfeleinkkel, ezért ezekben a gyakorlatokban mindig részt vesz a designer és menedzsere, sőt a facilitátor is. Olyan problémák merülhetnek fel ilyenkor, amikkel szembe tudunk nézni (vagy le tudunk győzni), és akár a workshop későbbi menetét is befolyásolhatják. A projekt szempontjából azért is hasznos lehet, mert így tudni fogjuk, hogy az egyes stakeholderek mire „ugranak”, mire kell majd kiemelten figyelni a projekt során.

### Hogyan alkalmazzuk?

1. Minden résztvevő kap egy A4-es papírt vagy egy nagyobb post-itet, filctollat. Pro tipp: a papírra rajzold rá egy hal körvonalát, ennek a belsejébe lehet majd írni.
2. A facilitátor elmeséli a résztvevőknek, hogy mi ez, mire jó, mi fog történni a gyakorlat alatt és válaszol a felmerülő kérdésekre.
3. Elindul az időzítő (3–5 perc ideálisan az erre szánt idő), a résztvevők papírra vetik az aggodalmaikat.
4. Ha lejárt az idő, egyesével mindenki felolvassa, kifejti a leírtakat. A többiek reflektálhatnak rá a facilitátor moderálásával.

**Te próbáltad már? Mik a tapasztalataid?**

[Itt találod az eredeti Stinky Fish gyakorlatot angolul](https://toolbox.hyperisland.com/stinky-fish-13d9ce8d-e64f-4085-8a06-8d212c627788?ref=blog.fps.hu)
### Megjöttek a pluginok. Figma.
URL: https://blog.fps.hu/figma-pluginok/
Last updated: 2026-07-17T08:20:30.000Z
Csak gyorsan, mert nincs sok időnk. Manapság?! Tegnap is a másfél órásra tervezett [livestreamet](https://www.youtube.com/watch?v=6r5n1SFkEtQ&ref=blog.fps.hu) letolták 40 perc alatt. Hát akkor gyorsan. Csak képek és a teljesség igénye nélkül, első benyomásra, hirtelen verdiktet mondva. Ráadásul nem is az összesről, hanem ami szembejött.

Az biztos, hogy a világot nem fogják megváltani, de ha már 1–2 olyan kiegészítőt találtál, ami gyorsít a folyamataidon, akkor már megérte.

#### Google sheets sync

[David Williames](https://www.figma.com/c/user/319620268789179331?ref=blog.fps.hu)

Jó lenne, ha működne majd komponenseken belül is. Jelenleg, ha már több komponensből épül fel (amik szintén tartalmaznak komponenseket, akár token szinten) egy blokk, akkor elhasal a script. Ezen felül a szövegstílusokat is szétbombázza, így ezt jelenleg rapid drótvázakhoz tudom ajánlani, ahol valós tartalmat lehet gyorsan felvinni és módosítani. Lesz ez még jobb és alig várom!

#### Super Tidy

[Ismael Gonzalez](https://www.figma.com/c/user/657303671827049881?ref=blog.fps.hu)

Ha már használtad a Figma saját Tidy Up-ját, vagy a Ctrl/Cmd+R Rename opcióját, akkor ezt teljesen felesleges telepítened. Ha még nem használtad, próbáld ki őket.

#### Mapsicle

[Chris Arvin](https://www.figma.com/c/user/363876808230201962?ref=blog.fps.hu)

Egy igazán remek és hatékony plugin… Lenne, ha mapboxos screeneket szeretnék használni a terveken. Akkor inkább a [snazzymaps.com](https://snazzymaps.com/?ref=blog.fps.hu).

#### Map Maker

[Kazushi Kawamura](https://www.figma.com/c/user/654582605227520693?ref=blog.fps.hu)

Ha már a Snazzy Mapet hiányoltam, akkor itt is van. Nem kell hosszúsági, szélességi koordinátákat másolgatnod, hanem egyszerűen cím alapján jeleníti meg a térképet. A Google Maps alapján 4 féle nézet közül választhatsz. Ezenfelül, ha a Snazzy-n kiválasztasz egy stílust, majd bemásolod a kódját, akkor még a stílust is beágyazza. Azt hiszem ezt megtartom. Ez a kiegészítő valóban hasznos segítség.

#### Content Buddy

[Ismael Gonzalez](https://www.figma.com/c/user/657303671827049881?ref=blog.fps.hu)

Ha nem Loremipsumozol, akkor ez egy hálás és nagyszerű kiegészítő. Tudsz keresni a Page-en lévő szöveges tartalomban, és egyszerűen kicserélheted. Sajnos a Replace mező csak 1 sor magas, így hosszabb szövegeknél nem szerencsés, illetve a többféle stílussal rendelkező szövegdobozokat nem tudja kezelni. Attól még megtartom, mert nagyon hasznos.

#### Content Reel

[Microsoft](https://www.figma.com/c/org/588096576863690753?ref=blog.fps.hu)

Ahogy látod ez hivatalos Microsoft kiegészítő. Ebből adódóan ez a saját belső folyamataik optimalizáláshoz készült igényeknek felel meg. Jelen pillanatban egy random avatar generáló, nyakon öntve a saját Microsoft’s Segoe MDL2 ikonfontjukkal (az avatarkép még nem működik). Viszont biztosan vissza fogok rá nézni, mert vannak ígéretes fejlesztéseik.

#### Focus Orderer

[Tiffany Chen](https://www.figma.com/c/user/615953866113549964?ref=blog.fps.hu)

Ahogy a nevében is van, sorba lehet rendezni vele a Frame-eket, amik kapnak egy sorszámot és jelölőt a bal felső sarokba. Arra figyelj, ha használod, hogy Frame-eknél működik, különben minden group, elem meg lesz jelölve. Ha más nem, arra biztosan jó, hogy rászoktasson a Frame-ek használatára. Nálam nem marad meg.

#### Figma Walker

[Kazushi Kawamura](https://www.figma.com/c/user/654582605227520693?ref=blog.fps.hu)

Ígéretesnek tűnt, de végül csak egy frame kereső lett. Ha szépen építkezel és elnevezel, akkor általában tudod, mit, hol találsz. Ha meg nem az a típus vagy, akkor úgyse kapnak nevet a Frame-ek, tehát a #Group 3 se fog sokat mondani. Ezenfelül, ha sok frame-mel dolgozol, akkor azért elgondolkodik 10–20 másodpercet. Törölve.

#### Autoflow

[Coinbase](https://www.figma.com/c/org/657352101224507447?ref=blog.fps.hu)

Arra jó, hogy összekötögessen objektumokat. Egyszerre kettőt. Kijelöl→jobb klikk→plugins→megkeres→klikk→nálam kuka. Túl sok befektetett energia a semmiért. Ha rendes flow-t szeretnél, arra vannak céleszközök. Ha pedig magadnak, ügyfélnek, és szépet, akkor inkább használd [ezt az ingyenes library-t](https://migue.design/fluid/?ref=blog.fps.hu).

#### Paddy

[Liam Martens](https://www.figma.com/c/user/383754125047657632?ref=blog.fps.hu)

Ha találkoztál már a „Resize to Fit” funkció idegesítő oldalával, amikor a frame-en túllógó elemhez igazít, akkor szeretni fogod ezt az egyszerű kiegészítőt. Nem fog csodákat tenni, de úgy érzem fogok vele próbálkozni a közeljövőben.

#### Blend

[Gleb](https://www.figma.com/c/user/419479867853161728?ref=blog.fps.hu)

Jó móka. Blend. Rakj egy vonalra egyféle elemet, majd azt sokszorosítsd. Inkább Illustratorból copy-paste.

#### Image Palette

[Matt DesLauriers](https://www.figma.com/c/user/694658998464996400?ref=blog.fps.hu)

Képről készít egy színpalettát. Láttunk már ilyet, de egy moodboard készítésénél hasznos, hogy nem kell hozzá külső oldal.

#### Time Machine

[Square](https://www.figma.com/c/org/606588765423218695?ref=blog.fps.hu)

**No ez egy igazi KELL plugin**. Ha használod a verziókövetést Figmában, akkor is szembejön mindig az a probléma, hogy egyes elemek, frame-ek már elavultak, de még nem érett meg egy újabb verzió mentésére, esetleg tudod, hogy vissza kell még nyúlnod hozzájuk. No, erre ez pont tökéletes!  
Kijelölöd az archiválni kívánt elemeket, és elindítod a plugint. Pikk-pakk lefut, és készít egy külön page-et, amin a frame neve az adott dátum, a kijelölt elemek pedig klónozódnak, viszont a nevükbe bekerül az időpont. Értsd úgy, hogy a komponenseid is megmaradnak, csak lesz belőlük egy percre pontosan dokumentált másolat. Eddig ez a legnagyobb kedvenc. Ha te is be tudod illeszteni a munkafolyamatodba, vagy volt már olyan projekt, ahol jó lett volna ez a mélységű dokumentáltság, akkor imádni fogod.

#### Interplay

[Michael Fitzgerald](https://www.figma.com/c/user/643718088156533493?ref=blog.fps.hu)

Nem tud többet, mint egy behívott Library, viszont a jelenlegi két ~~design system~~ UI könyvtár remek kiindulás lehet a későbbi munkádhoz, akár mintát keresel, akár működést szeretnél megnézni. Majd egyszer lehet, hogy bővítik a listát, így majd egyszer lehet, hogy vissza is nézek rá.

#### Themer

[Tom Lowry](https://www.figma.com/c/user/613425424308719151?ref=blog.fps.hu)

Ehhez nekem fejlesztő kell, de itt a remek alkalom, hogy egy [fps-nap](https://www.facebook.com/search/top/?q=%23fpsnap&epa=SEARCH%5FBOX) keretein belül ismét építsük a hidat a designer–fejlesztői árok felett.

#### Table Generator

[Zwattic](https://www.figma.com/c/user/722762581119367815?ref=blog.fps.hu)

Ahogy a Google sync pluginnál, itt is inkább a rapid drótvázakhoz tudom ajánlani, ahol valós tartalmat lehet gyorsan felvinni. Ha hasznos táblázatokra vágysz, [akkor itt egy remek cikk](https://uxdesign.cc/tables-ui-design-in-figma-data-grid-by-a-single-component-5d2c76c16f8?ref=blog.fps.hu), hogyan kezdj neki.

#### Iconify

[Vjacheslav Trushkin](https://www.figma.com/c/user/537575274818528909?ref=blog.fps.hu)

Ezt hiányoltam az egyik legjobban a Figma Plus-ból, és nem csak azért, mert 50 ikon szett több mint 40 000 ikonját képes használni, hanem mert könnyen tudsz benne keresni. Remek kiegészítő, ami valóban megkönnyíti a munkád.

#### Figma Nounproject

[Liam Martens](https://www.figma.com/c/user/383754125047657632?ref=blog.fps.hu)

Ha használod, szereted, kedveled a Nounprojectet, akkor az Iconify alternatívája lehet.

#### Similayer

[David Williames](https://www.figma.com/c/user/319620268789179331?ref=blog.fps.hu)

**Egy újabb kötelező darab.** Első blikkre nem láttam olyan beállítási lehetőseget, ami alapján ne lehetne keresést indítani (line height, letter space, blend mode stb.). Végre tovább lehet finomítani a keresést, és ezzel is még egységesebbé tenni a terveket, vagy csak kitisztítani a feleslegesen ottfelejtett, elrejtett layereket. Gyakran fogjuk használni a fejlesztőkkel egy design átadás során.

#### Rename It

[Rodrigo Soares](https://www.figma.com/c/user/389130427006811230?ref=blog.fps.hu)

Ahogy a Similayer a keresésnél, úgy a Rename It az átnevezések terén finomít a már így is remek beállításokon. Még nem tudom eldönteni, hogy mennyire lesz hasznos a munkám során, de az biztos, hogy fent marad egy ideig.

Ahogy látod a lista nem teljes, és korántsem alapos. Mondd el mit hagytam ki, vagy ha nem voltam elég alapos, javíts ki nyugodtan! Köszi, hogy elolvastad.

\---**Frissítés**\---  
Kénytelen voltam egy frissítést kiadni, mert ez a plugin nem hiányozhat a listáról.

#### Nisa Text Splitter

[Orkhan Jafarov](https://www.figma.com/c/user/512927903569702628?ref=blog.fps.hu)

Az Adobe részéről az egyik leghasznosabb újítás volt anno, amikor szövegdobozból szövegmezőt tudtál alakítani és fordítva. Most A Figmában is csak pár klikk és végre a kolléga által különböző szövegmezőkbe rakott szöveget egybeolvasztja egy szövegdobozba és még ABC szerint rendezni is tudod, vagy két oszlopba törni. Imádom.
### Emberközpontú interjúk
URL: https://blog.fps.hu/emberkozpontu-interju/
Last updated: 2026-07-17T08:20:40.000Z
Emberek vagyunk, akik embereknek terveznek. Egymást segítve, együtt dolgozunk a céljaink elérése érdekében. Mindezt beárnyékolja, ha egy interjú nagy részében a szakmai hozzáértést próbálják felderíteni. Ekkor mindig felmerül a kérdés bennem, hogy vajon tényleg kíváncsiak a jelöltre vagy csak egy erőforrásra van szükség?

### Kétség

Az állásra jelentkezés nem mindennapos. Egy fontosabb döntés része, mely nagyban befolyásolhatja az életedet. Sajnos egy ilyen jelentkezés elején vagy akár közben sincs elég transzparencia, azaz nem lehet tudni hogyan is fog zajlani, mi fog történni vagy mennyi ideig fog tartani. Ez bizonytalanságban tartja az embert.

Ennek feloldására fontos, ha minél hamarabb visszajelzel legalább arról, hogy megkaptad a jelentkezést. Sok helyen űrlapon keresztül lehet jelentkezni, ami habár egyszerűbb, de személytelenebb. Ilyenkor fontos legalább egy automata üzenet. Ebben se lustálkodj és például szólítsd a jelentkezőt a nevén.

Ne felejtsd el, hogy erről is megítélik a cégedet, így az egész folyamat alatt érdemes megfelelő figyelmet fordítani erre.

### Őszinteség

A szakmai tudás feltárásának egyik eszköze a kvíz jellegű teszt. Ez lehet akár szóban vagy írásban, a lényeg, hogy egy helyes válasz van. Sajnos pont a szakmai tudást nem lehet feltárni megbízhatóan ezzel a módszerrel, hanem csak azt lehet megállapítani, hogy a jelölt felkészült az interjúra vagy sem.

Egy egyszerű internetes kereséssel több oldalon keresztül olvashatjuk egy adott szakmára vonatkozó kérdéseket és arra a helyes válaszokat. Nem kell nagy szakmai tudás, csak be kell tanulni ezeket a válaszokat. A kérdés viszont az, hogy olyan embereket szertnél felvenni, akik ki tudják játszani, vagy csak jól tudják tettetni, hogy értenek a szakmához, vagy akik „készületlenül”, azaz a jelenlegi legjobb tudásukat nyújtják?

![interjúztató és jelentkező tudása, illetve a feltett kérdések egy témakörön belül Venn diagrammon ábrázolva, ahol alig van metszet](https://blog.fps.hu/content/images/2019/07/interjuztato-jelentkezo-tudasa-feltett-kerdesek-venn.png)

Nehéz lehet olyan kérdéssort összeállítani, ami mindenre kitér. A jelentkező tudása lefedhet egy teljesen más részt a szakterületből, miközben azt a látszatot kelti, hogy nem ért hozzá. El kell dönteni, hogy változatos tudású emberekkel szeretnénk feltölteni a csapatunkat vagy a magunk klónjaival inkább.

### Lelkesedés

Új ismeretek gyűjtése vagy pótlása könnyebb feladat, mint a személyiségedet megváltoztatni. Ennek ellenére egy interjú során órákat töltünk el azzal, hogy a szaktudást felmérjük és nem azzal hogy egymást megismerjük. Sőt a megfelelő szintű tudást gyakran többre értékeljük mint a hozzáállást. Egy szorgalmas és aktív szakember sok értéket tud teremteni a cég számára hosszútávon.

Ha a jelölt rendelkezik mindazokkal az ismeretekkel, amik a munka elvégzéséhez szükségesek, akkor unalmas lehet számára a munka. Ellenkező esetben viszont kihívás lesz számára és azért fog bejárni a munkahelyére hogy az új ismereteket megszerezze.

Amennyiben rendelkezel valamilyen céges stratégiával, annak a figyelembe vétele is háttérbe kerülhet, ha egy jelenlegi helyzetet old fel az új ember felvétele. Példa erre a Lean, ahol a rövid távú célokat érdemes feláldozni a hosszúakért, így el kell gondolkozni azon milyen értéket tud később teremteni az adott személy számodra.

### Tisztelet

Senki sem szereti, ha visszautasítják, viszont elkerülhetetlen. A negatív érzések összefüggésbe fognak kerüni a céggel és az emberekkel, akikkel a jelölt találkozott. Ekkor később nem fog újra jelentkezni a csalódás miatt, amivel kevesebb lehetséges munkatárs közül lehet majd válogatni.

Ez elkerülhető vagy nagyban csökkenthető, ha az elutasításkor valódi visszajelzést, útmutatót és indokot adsz. Ha a másik felet úgy kezeled mint, ahogy egy kollégádat kezelnéd, kivívhatod, hogy jobb fényben lásson a jelölt visszautasítás után.  
A pontosabb visszajelzés nem csak a jelölt számára hasznos. Az állásinterjún résztvevőket is arra buzdítja, hogy jobban gondolják át kit választanak, így nem csak a megérzéseikre fognak hagyatkozni és több figyelmet szentelnek minden egyes jelentkezőnek.

### Köszönet

Mint ahogy minden folyamaton, úgy az interjún is lehet javítani. Kezdhetjük ezt akár a célok tisztázásával vagy akár a visszajelzésekkel. Legyünk empatikusak a jelentkezők irányába és ez megtérül a cég megítélésében és felvett emberek teljesítményében is.

Nektek van tapasztalatotok arról, hogyan lehetne emberközpontúbb egy interjú?
### Így ne szívasd meg magad Vue.js-sel
URL: https://blog.fps.hu/vue-js-ne-szivasd-magad/
Last updated: 2026-07-17T08:20:49.000Z
Vannak hibák, amelyeket szinte minden fejlesztő elkövet, amikor először dolgozik Vue.js alapú projekten. A többségüket nem túl nagy mutatvány feltárni, gyakran elég csak felpattintani a konzolt a böngészőben, azonban létezik egy tipikus hiba, amely meglehetősen gonosz természeténél fogva jelentős károkat tud okozni az ember mentális épségében, ugyanis olyan triviálisnak tűnő műveletek kapcsán jelentkezik, mint például, amikor egy tömb egyik elemét meg szeretnénk változtatni a szokásos módon, ahogyan azt kezdő JavaScript fejlesztőként közvetlenül a "Hello World!" string konzolba történő kilogolását követően megtanultunk: *this.items\[0\] = value*.

Ránézésre minden rendben van ezzel a kódsorral és a konzol is üres, de valamiért mégsem történik semmi. Pedig ugye a reaktivitás lényege pont az lenne, hogy az alkalmazásod által megjelenített adatok bármilyen változás hatására frissülnek a képernyőn is anélkül, hogy neked ehhez bármit tenned kellene. A debuggerben ráadásul látod, hogy a változtatás megtörtént, de akkor miért nem jelenik meg?

**Azért, mert bizonyos változásokról a Vue nem tud értesülni, ezért nem tudja, hogy újra kéne renderelni.**

Ahhoz, hogy az ilyen hibákat el tudd kerülni, érdemes közelebbről megvizsgálni, hogy hogyan valósítja meg a reaktív működést a Vue.

### Hogyan működik a Vue.js?

Példányosításkor a reaktív adatok (*data*, *props* stb.) [getter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get?ref=blog.fps.hu)\-[setter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set?ref=blog.fps.hu) párokká alakulnak, [valahogy így](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global%5FObjects/Object/defineProperty?ref=blog.fps.hu#Custom%5FSetters%5Fand%5FGetters). A getterek és setterek lefutnak az adatok elérésekor, ezáltal lehetővé válik, hogy a Vue értesüljön az adatok változásáról. Ilyenkor triggerel egy rendert a virtuális DOM-ban a megváltozott adatok alapján, majd mindezt megjeleníti az alkalmazás konténerében.

Azonban – mivel ezek a getter/setter párok példányosításkor jönnek létre – a később hozzáadott további tulajdonságok változásairól a keretrendszer nem szerez tudomást.

#### Tömbök

A tömbökkel kapcsolatos problémák kicsit más okokra vezethetőek vissza, ugyanis ezek reaktivitását úgy oldották meg a fejlesztők, hogy becsomagolták az *Array* tagfüggvényeit (*push*, *pop*, *splice*, stb.). Amikor ezeken keresztül történik módosítás, minden megfelelően működik, azonban a *\[\]* operátor felüldefiniálására nincs lehetőség JavaScriptben, ebből kifolyólag a közvetlen módosításokról sajnos nem tudunk értesülni.

### Mi a megoldás?

Sokan éreznek ilyen szituációkban késztetést a [$forceUpdate()](https://vuejs.org/v2/api/?ref=blog.fps.hu#vm-forceUpdate) bevetésére, azonban ez a módszer – bár sok esetben működik – nem tekinthető megoldásnak. Ilyenkor ugyanis a Vue nem tudja, hogy miért volt szükség frissítésre, így azt sem tudja, hogy pontosan, mely komponenseket kell nulláról újrarenderelni. Ebből adódóan a komponens gyermekeit és azok gyermekeit (és azok gyermekeit stb.) is neked kell kézzel frissítgetned.

Ráadásul a *$forceUpdate* csak az újrarenderelést végzi el, ami nem feltétlenül elég, mivel nem kizárólag a megjelenítéskor okoz problémát, ha egy változásról nem értesül a keretrendszerünk. Előfordulhat, hogy például emiatt nem frissül a localStorage-ben tárolt state-ünk, vagy mondjuk nem küldjük vissza a szerverre a módosított profiladatokat. Ezeket a feladatokat is kézbe kell venned, az alkalmazásnak pedig innentől már nincs sok köze reaktivitáshoz.

#### Vue.set()

Az igazi megoldás a [Vue.set()](https://vuejs.org/v2/api/?ref=blog.fps.hu#Vue-set) helper. Amikor nem obszerválható módosításra van szükség, ezen a függvényen keresztül van lehetőségünk azt elvégezni és egyúttal tudatni a keretrendszerrel, hogy történt valami, ami érdekes lehet a számára. Amennyiben objektumot kap értékként, létrehozza benne a szükséges getter/setter párokat, így az reaktívan fog viselkedni.

### Példák

Összedobtam ezt a kis szösszenetet a tömbök manipulásával kapcsolatos problémák szemléltetésére:

See the Pen [Vue.js arrays](https://codepen.io/sjozsef/pen/rgKdbz/?ref=blog.fps.hu) by Samu József ([@sjozsef](https://codepen.io/sjozsef?ref=blog.fps.hu)) on [CodePen](https://codepen.io/?ref=blog.fps.hu). 

  
Ez a sor azért nem működik, mert a tömbök elemeinek közvetlen módosítása nem obszerválható:

```js
this.items[0] = 'Title is not changed'

```

A következő megoldás azért jó, mert a *$this.set()* helper segítségével végeztem el a módosítást. Ez egyenértékű a *Vue.set()*\-tel:

```js
this.$set(this.items, 0, 'Title is changed')

```

Szintén jó megközelítés egy tömb method használata, mert az ezeken keresztül történt módosításokról tudomást szerez a Vue:

```js
this.items.splice(0, 1, 'Title is changed')

```

A következő megoldás nem elegáns, de ebben az esetben működik, mert bár ugyanúgy nem értesül a változásról a keretrendszer, ahogy az első példában sem, kézzel lefuttatom a rendert. **Ezt a megoldást azért implementáltam, hogy neked már ne kelljen. Ne próbáld ki otthon!**

```js
this.items[0]='May title is changed, but never do this.'
this.$forceUpdate()

```

Most nézzük meg, mi történik, ha a tömbben objektumok vannak? Ehhez is írtam példát:

See the Pen [Vue.js Arrays with Objects](https://codepen.io/sjozsef/pen/QRxYgB/?ref=blog.fps.hu) by Samu József ([@sjozsef](https://codepen.io/sjozsef?ref=blog.fps.hu)) on [CodePen](https://codepen.io/?ref=blog.fps.hu). 

  
Az első metódusom – talán meglepő módon – működik, mert bár első ránézésre úgy tűnhet, hogy közvetlenül módosítottam a tömbön, a valóságban az elemei változatlanok maradtak. Az objektumok JavaScriptben referenciaként adódnak át és tárolódnak le a tömbben, tehát abban lényegében csak memóriacímek vannak, amelyek az objektumok által lefoglalt memóriaterületekre mutatnak. Az objektum változtatásával a memóriacíme nem változik meg, maga az objektum pedig rendelkezik a Vue által léterhozott getterekkel és setterekkel:

```js
this.todos[0].title='Changed title'

```

A következő sor azért nem működik, mert új objektumot hozok létre, és arra cserélem ki a tömb egyik elemét. Az új objektum új memóriacímet kap, ezért a tömbben változás történik, de erről a Vue nem értesül:

```js
this.todos[0] = {
  title: 'Replaced title (not working)',
  description: 'Lorem ipsum'
}

```

Ráadásul itt egy olyan objektum jön létre, amelyek kulcsai nem kapják meg a getter/setter párjukat, ezért nem elég, hogy a változás nem jelenik meg, ezt követően már az egyébként helyes módosításom sem fog megfelelően működni. Ez egy eléggé aljas hiba, nem lennék a helyében annak a fejlesztőnek, akinek ki kell bogoznia.

Ha új objektumra akarom cserélni a tömböm egyik elemét, akkor – már biztos kitaláltad – a *Vue.set()* lesz a barátom:

```js
this.$set(
  this.todos,
  0,
  {
    title: 'Replaced title',
    description: 'Lorem ipsum'
  }
)

```

Ilyenkor a Vue létrehozza a getter/setter párokat az újonnan beszúrt objektumhoz, tehát az előző példával szemben itt a továbbiakban is minden a várt módon fog működni.

A következő példák azt a problémakört igyekszenek szemléltetni, amikor objektumokhoz próbálunk meg hozzáadni új kulcsokat.

See the Pen [Vue.js - adding object properties](https://codepen.io/sjozsef/pen/pmZpBp/?ref=blog.fps.hu) by Samu József ([@sjozsef](https://codepen.io/sjozsef?ref=blog.fps.hu)) on [CodePen](https://codepen.io/?ref=blog.fps.hu). 

  
Az első metódus azért nem működik, mert a már létező objektumban közvetlenül hozok létre új kulcsot. Ehhez a kulcshoz nem tartozik getter/setter:

```js
this.heading.excerpt = 'Lorem ipsum'

```

A következő megvalósítás rendben van, mert a *Vue.set()* az új kulcs hozzáadásakor a getter/setter párt is létrehozza. Azonban ha az előző sor már lefutott, az azt jelenti, hogy már létrejött az új kulcs getter/setter nélkül (annek ellenére, hogy nem látszik). A *Vue.set()* ilyenkor ezek meglétét nem vizsgálja, ezért az objektum sem most, sem a jövőben nem fog tudni reaktívan viselkedni.

```js
Vue.set(
  this.heading,
  'excerpt',
  'Some lead text'
)

```

Azt is megtehetem büntetlenül, hogy az objektumot kicserélem egy újonnan létrehozott objektumra. Ez azért működik, mert itt a szülő objektum setterén keresztül érem el az objektumot, a Vue erről értesül, így létre tudja hozni a getter/setter párokat a hozzáadott objektumom kulcsaira.

```js
this.heading = {
  title: 'Replaced title',
  excerpt: 'Replaced excerpt'
}

```

Ha ezt követően futtatod le az első példát, látható, hogy így már az is működik, mivel ebben az esetben nem új kulcsot hoz létre, hanem egy meglévőt módosít.

### Konklúzió

A Vue.js nem véletlenül tartozik a top reaktív frameworkök közé, a változások követésével kapcsolatos megoldásai (is) zseniálisak. Ennek köszönhetjük, hogy a használata kényelmes, szinte észrevétlenül teszi a dolgát. Nem terhel minket feleslegesen, szebb és fókuszáltabb kódot tudunk írni. Azonban minden éremnek két oldala van. Mint mindig, érdemes tisztában lenni a háttérben történő folyamatokkal, mert vannak helyzetek, amikor az egyszerűség és a kényelem ellenünk fordul.

Azon fejlesztők közé tartozom, akik nagyon rosszul érzik magukat, amikor nem értik teljesen, hogy mi történik a színfalak mögött. Ez egy bizonytalan, kiszolgáltatott, kellemetlen helyzet. Minden frameworköt alaposan ismerni kell ahhoz, hogy ne lőjük vele lábon magunkat. Ebből a perspektívából a Vue.js nagy előnye a nála komplexebb keretrendszerekkel szemben, hogy az egyszerűségének köszönhetően a magabiztos használatához szükséges tudást jóval könnyebb felhalmozni.

Szóval remélem, hogy nem ijesztettelek el a használatától. Tényleg csak erre a két edge case-re kell odafigyelni, és akkor imádni fogod. **Soha ne módosítsd közvetlenül a tömbök elemeit és ne adj hozzá közvetlenül új kulcsokat az objektumokhoz.**

Köszönöm, hogy elolvastad.
### Álljuk körbe!
URL: https://blog.fps.hu/alljuk-korbe/
Last updated: 2026-07-17T08:20:59.000Z
Látsz egy hibát, elírást? Aztán máris készül a képernyőkép, a fotó és nyomban tolod is ki a közösségi médiára? Húúú, ez mennyire gagyi, milyen béna, mekkora balfékek, látjátok? Bebeee micsoda hülyék, wahhahhahaaa…

Nagy vagy! Észrevetted és máris szétkürtölted mindenfelé, jönnek a lájkok, együtt nevetnek veled. De várj csak! Erről az egyik South Park jelenet ugrott be. Amikor valamelyik gyerkőc butaságot mond és Mr. Garrison tanár úr azt mondja a többieknek:

> „Gyertek, álljuk körbe, mutassunk rá és nevessünk rajta!”

Tele van ilyen példákkal a twitter, a Facebook. Különösen a Facebook csoportok. Mégis miről szól ez? A legtöbb alkalommal önfényezésről, illetve mások hibáinak kollektív kinevetéséről. Gyanítom sokszor bele sem gondolnak ebbe a posztolók.

De! Mi lenne, ha jeleznéd annak, aki elkövette, aki felel érte, akire tartozik, aki esetleg ki tudja javítani, aki tud tenni azért, hogy változtasson rajta? És nem ország-világ előtt, hanem csendben a háttérben, direkten. Igen, picit nagyobb fáradsággal jár és nincs érte többszörös „jutalom”.

Szerencsére jómagam találkozom ilyen emberekkel. Rám írnak különböző csatornákon, hogy itt-ott elírtam, egy fogalmat nem megfelelően használtam, vagy épp nem működik valami. Megköszönöm, mert javíthatom a hibáim és sokszor tanul(hat)ok belőle. Ugyanezt szoktam tenni másokkal is és bátorítalak erre, hogy te is mindig így járj el.

Persze lehet, hogy egy aktuális példán keresztül akarod felhívni mások figyelmét egy klasszikus problémára. Oké, ez jó, de ilyenkor is érdemes elrejteni, hogy kihez tartozik az adott megoldás, már amennyiben lehetőséged van rá. Ééés nyilván a szerinted jó megoldást is fogalmazd meg és azt támaszd alá érvekkel. Ezzel legalább előmozdíthatod a világ folyását. Vagy épp nem, de legalább megpróbáltad.

Végül mielőtt (kéretlen) tanácsokat osztogatsz tedd fel magadnak a következő kérdéseket:

- Van megfelelő rálátásom a témára?
- Jól [ismerem a körülményeket](https://blog.kolboid.eu/megismeres-kutatas-frenologia-itelet/?ref=blog.fps.hu), az illetőt?
- A véleményem olyan tapasztalatból származik, ami erre is érvényes lehet?

Ha bármelyik kérdésre nem a válasz, akkor inkább engedd el a tanácsod, jó helyen van az. Lehet, nekem is azt kellett volna tennem? :)

[English version of this is post](https://medium.com/@kolboid/lets-not-laugh-at-them-f2bf0a252aeb?ref=blog.fps.hu)
### Felhasználói interjúk – bizonyosság a tervezésben
URL: https://blog.fps.hu/mikor-szukseges-melyinterju-a-ux-tervezeshez/
Last updated: 2026-07-17T08:21:10.000Z
Sok digitális projektben merül fel a kérdés, hogy „Mikor szükséges bevonni a végfelhasználókat a tervezési folyamatba?”. Erre egyszerű a válasz: abban a szent minutumban, amikor döntések születnek UX folyamatokról.

Személy szerint a mélyinterjút a követelményelezmés vagy tervezés abban a szakaszában látom hasznosnak:

- amikor már van kialakult felhasználó prekoncepció, vagy olyan protó perszóna, amelyet szükséges validálni, torzításait kiszűrni
- a design felfedezési szakaszában, amikor a potenciális felhasználókat és a website-tal kapcsolatos interakciókat kell feltérképezni, kontextust kialakítani
- vagy egy digitális termék koncepcióját kell előtesztelni, nagy beruházás zöldlámpája előtt.

Fontos kiemelni, hogy **a mélyinterjú nem egy verbális kérdőívezés, nem lehet egy zárt szobában előzetesen összeírt kérdéssor szigorú követésével rejtett igényeket feltárni.** A legtöbb felhasználó maga sincsen aktívan tudatában a valós igényeinek, ezért hasznos rávezető kérdésekkel, értő figyelemmel hallgatni, és az ő gondolatmenetére adaptálódni. Mégsem szabad ezt a rugalmasságot félreérteni, egy **minőségi interjú alapos felkészülést és megfontolást igényel az interjúztató részéről.** Az interjú köznapi szóhasználatban „kikérdezésként” értelmezhető, mégis ebben az esetben a beszélgetés szociális érintkezési szabályaiban inkább hasonlít egy kávézáshoz vagy kollegiális csevejhez a reggeli kávé felett. Mindezért fontos annak ismerete, hogy *hogyan kérdezzünk*, *miként hallgassuk* vagy *olvassunk a testbeszédből* a valós insightok feltérképezéséhez.

### Mit jelent ez nálunk a gyakorlatban?

A közelmúltban egy 6 hónapos egyetemi portálmegújításhoz kapcsolódó követelményelemzés részeként készítettünk UX perszónákat, melyhez előzetesen voltak hipotézisek a website megújítási igényeikről, problémáiról és felhasználói motivációikról. *(Ebben a projektben erre a három témakörre bontottuk a kutatást, de ez sem egy általános törvény)* A mélyinterjút ebben az esetben egy kvantitatív kutatás előzte meg, ahol már kimagaslottak olyan új, vizsgálandó területek, melyek kiásást és validálást igényeltek. Interjúk megtartásához szükség van szociális skillekre, de tanulható. Mégis én azt javasolnám először elsajátítani, hogyan kell megállapítani a mélyinterjúk szükségességét.

Ebben a követelményelemzésben, mivel a kvantitatív kutatás kérdéseinek 60%-a feleltválasztós volt, szakmailag javasoltuk az interjúkkal történő validációt, mert úgy láttuk, nem elég az új problémakört listára venni, ugyanilyen fontosnak tartottuk, hogy a kiváltó okokat is feltérképezzük. Az igényt még alátámasztotta, hogy a kérdőívben új felhasználói problématerületek is felmerültek, melyek lényegesen megváltoztatták a funkcionális fejlesztési igények fontossági sorrendjét.

> “One can’t design for people if one doesn’t understand what they go through on a daily basis.” #HumbleBits

### Hogyan lehet eldönteni, hogy mennyi interjú szükséges?

Azt kell hogy mondjam, tapasztalati alapon. A szakirodalom szerint, ha reprezentatív kutatásra van igény, akkor a célcsoport összetételét kell leképezni százalékos alapon. Kisebb projekteknél azonban 8–15 interjút szoktunk javasolni. Ezek lehetnek egyszemélyes vagy páros, hármas interjúk is, attól függően a téma jellege mit kíván meg:

- személyesebb őszinte válaszokat,
- vagy interakciót és párbeszédet.

### Hogyan kell rá költségvetést számolni?

A kutatás elindításakor a megrendelőnek is fontos, hogy a fejlesztő csapattól kutatási tervet kérjen be. Ez egy olyan alapdokumentum lesz, ami alapján értékelni tudja a megrendelő is a költségvetést, illetve mérlegelni az interjúk számát és formáját. A kutatási terv elfogadása után lehet pontos költséget kalkulálni. **Amennyiben a user experience fontos része a briefnek, akkor a kutatásra a projekt budget 20–40%-a sem sok. Hosszú távon a későbbi design újratervezés és iterációs fejlesztések nagyságrendekkel megsprólhatók.** Arról az anyagi veszteségről nem is beszélve, ha nem lesz sikeres az adott website vagy digitális termék.

> „Ha az ügyfélköröd veled öregszik, akkor előbb-utóbb elavulttá vagy irrelevánssá válsz. Folyamatosan fel kell fedezned, hogy ki az új ügyfeled, és hogy mit tegyél, hogy örökre fiatal maradj.” #Jeff Bezos, az Amazon alapítója

**A felhasználói interjúk nagyon informatív és mélyen vizsgált eredményeket tudnak biztosítani, de csak akkor, ha jó célokat fogalmazunk meg és a kivitelezés is helyes.** Más, akár kvalitatív módszerekkel kombinálva adja a legbiztosabb eredményeket. A mélyinterjú csak az egyik, talán legelterjedtebb formája a felhasználói igények feltérképezésének, ezen kívül számos más metodika létezik.

### Milyen rizikói lehetnek, ha VANNAK a mélyinterjúknak?

- megnöveli az induló költségvetést
- a tervezési fázis elhúzódhat
- a kiértékelés nem mindig az elvárt prekoncepciót támasztja alá
- rossz interjú alanyok, vagy rossz kérdező hibás következtetésekhez vezetnek
- a felhasználók visszaemlékezése nem 100%-os sok kognitív torzítás van a válaszokban
- jó a kutatás, de nem tudsz hiteles UX perszónákat készíteni
- előfeltételezések nélkül, nyitottan kell hozzáállni, ez tulajdonosként nehéz, és torzítást okozhat
- kidobott pénz lesz a kutatás, ha utána nem az eredményekre támaszkodik a tervezés

### Milyen rizikói lehetnek, ha NEM csinálsz felhasználói interjút?

- nem fogod megtudni, hogy valójában mit gondolnak a felhasználók
- szükségtelen funkciókra költhetsz feleslegesen sokat, vagy nem kerül bele a termékbe minden szükséges funkció
- nagy felelősség hárul a megrendelőre, hiszen akkor neki kell vállalnia a felelősséget a felhasználók igényeinek való megfelelésért (nem a UX tervezőnek, ő – részben vakon – csak javaslatot adhat interjúk nélkül)
- hibás adatok alapján kerül megrendelésre a drótváz, illetve a webdesign is
- téves feltételezések alapján kerül jóváhagyásra a tervező csapat UX koncepciója
- nehezen használható lesz a digitális termék
- **sokat kell költeni az elkészült website átalakítására, újratervezésére és a funkciók utólagos módosítására, immár a felhasználók valós igényei és visszajelzései alapján**

### Hogyan mérhető az értéke a mélyinterjús kutatásnak?

**Őszintén? Elégedett felhasználókkal.** Véleményem szerint a legnagyobb érték egy megrendelő részéről a bizonyosság. Bizonyosság a költségvetésbe beleférő funkciók fontosságáról, bizonyosság a drótváz, user journey stb. tervezés esetén a felhasználói viselkedésmintákról, és főként bizonyosság a termék későbbi fogadásáról.
### Szakbarbár is
URL: https://blog.fps.hu/szakbarbar-t-forma-altalanos-tudas-ismeret/
Last updated: 2026-07-17T08:21:20.000Z
Szakosodás, szakosodjunk, sokasodjunk. Óhatatlan és persze szükségszerű folyamat a specializálódás, minek a végletes pontján szakbarbárok serege áll, akik semmit nem képesek létrehozni egymagukban, de ami még rosszabb, már nem is hajlandóak mást csinálni.

A mi ökoszisztémánkból emelek ki egy példát, amelyet talán a következő szabadfordítású tweet foglal össze a legjobban:

> Amikor megkérdezik tőlem: „Ki végezte a felhasználói kutatást? Ki tervezte az információs architektúrát? Ki rajzolta a drótvázakat? Ki csinálta a grafikát? Ki volt, aki…?”, és akkor mindegyik kérdésre azt válaszolom: „Én”.
> 
> Ezt nevezzük tervezésnek mi, öreg rókák.  
> – [Brijan](https://twitter.com/brijanp/status/1072559593753055233?s=21&ref=blog.fps.hu)

Vágom, hogy a specializálódott emberek mesterei az adott területnek és ez egy nagyon jó dolog. De az tényleg rendben van, hogy egy drótvázat tervezőnek várnia kell a UX copywriterre, mert egy istenverte gombnak nem tudja „megírni” a feliratát? Hát biztosan nem. Azt gondolom, hogy senki se nevezze magát semmilyen tervezőnek, aki nem képes egymaga végigvinni egy teljes tervezési folyamatot. Pláne ne nevezze magát tervezőnek az, aki sosem tesztelte másokkal, amit csinált. Egyszerűen szükség van erre, méghozzá legfőképpen a hatékonyság miatt. Ha tudom és értem, hogy a másik mit csinál, hogyan kapcsolódunk egymáshoz és mi a közös cél, ami a folyamatban manifesztálódik, nos, akkor tudunk igazán együttműködni. Ez nem egy futószalag.

A területeden általános, széles tudásra van szükséged. Ha ez megvan, akkor mélyülj el egy részterületen és abban légy szaki! Bizonyára működik ez fordítva is. Ha ezt a tudáshalmazt ábrázolod, akkor egy T alakú formát kapsz, ezért is nevezik T-formának, esetünkben T-shaped designernek.

Régebben készítettünk egy eszközt tervezők számára, ahol meg tudják maguknak jelölni, mely területen milyen szintűnek ítélik tudásukat. [Ez a UX amőba, használd!](https://uxamoeba.fps.hu/?ref=blog.fps.hu) A vizualizáció segít abban, hogy lásd hol és milyen irányba kell fejlődnöd.

Ami a „nem nyúlok máshoz” mentalitást illeti, értem, hogy van más specializálódott arc, aki jobban meg tudja csinálni. Viszont egyrészt azt gondolom ilyenkor mindig a célt kell figyelembe venni és aszerint eldönteni, hogy elegendő az ismereted ahhoz, hogy a cél teljesüljön, másrészt pedig azt a bizonyos egot dobd a sufniba, hiszen selyempapír nélkül is ki lehet törölni.

[A fejléc kép eredetije.](https://twitter.com/designershumor/status/1087618133853159424?ref=blog.fps.hu)
### Kaizen
URL: https://blog.fps.hu/kaizen/
Last updated: 2026-07-17T08:21:31.000Z
A folyamatos fejlődést jelentő japán szó egy olyan gondolkodásmódot is takar, ami más megvilágításba helyezi a felmerülő problémákat. Ennek segítségével pedig egy jobb jövőért dolgozol, így érdemes tehát áttekinteni mit is takar.

### Eredet

A Toyota autógyártása nem volt jó helyzetben az 1940-es és 50-es években. Miközben Amerikában egy gyár 7000 autót is tudott gyártani naponta, ők csak 200-at évente. Az akkori vezető, Tojoda Eidzsi, átvette az amerikai modellt, de látta benne a hibákat is, amin lehet javítani.

A következő 2 évtized alatt kialakult az úgynevezett Toyota Production System, ami a 90-es években a lean vállatirányítási rendszerként is ismert lett, majd ezek az elvek és a rendszerThe Toyota Way 2001 név alatt lett összegezve.

Ennek a rendszernek az egyik fő pillére a folyamatos fejlődés.

### Szemléletmód

Az egész lényege nagyon egyszerű. Kisebb lépésekkel, egy-egy módosítással javítasz a folyamataidon.

Hiába az autógyártásban fejlődött ki, az élet szinte minden részén lehet alkalmazni. Például készítesz egy kávét, majd cukrot raksz bele, amit kiveszel a szekrényből. Mi lenne, ha a cukrot a pulton tartanád, hogy ne kelljen kivenni a szekrényből? Persze ez nyilvánvalónak is tűnhet, viszont egy gyártósoron pár centivel közelebb helyezve egy alapanyagot nagyon sokat nyerhetsz. Egy-egy odanyúlással spórolt tizedmásodperc a munkanap végén százezres nyereség formájában jelenhet meg.

A kisebb lépések a legjobbak. Ezeket könnyű bevezetni, nem kell átrendezni az egész szervezeted hozzá. Az emberek nehezen alkalmazkodnak az újhoz, így a nagyobb változások sokkal kockázatosabbak és nehezebb bevezetni őket. Nagyon sokat olvashatsz sikereses emberekről vagy láthatod őket, ezért lehet egyből a hegycsúcsra akarsz kerülni, viszont azt meg szokás mászni először. Ez a módszer is két évtized alatt, több ember munkájából fejlődött ki.

Felmerülő probléma esetén rossz érzés van az emberekben vagy akár a másikat is hibáztathatják. Más esetben félnek bevezetni változásokat és új módszereket a következmények miatt.  
Ha a folyamataid javítása a célod, akkor a problémákból lehetőség lesz. Egy olyan lehetőség, amit meg kell ragadni, hogy jobbá tedd a céged működését. A hibák olyan tapasztalatot vagy tudást jelentenek, amikkel előrébb lehet lépni vagy megtalálni a legjobb megoldást a céged számára.

Tökéletes állapotot nyilván nem lehet elérni, így folyamatosan kell alkalmazni ezt a gondolkodásmódot.

### Hogyan

A TPS (Toyota Production System) a folyamatokban dolgozó emberekre támaszkodik. Ő az, aki megtapasztalja és végigcsinálja azt, így neki lehet a legjobb rálátása, ezért nem szabad figyelmen kívül hagyni.

Eszközként lehet egyénileg alkalmazni, ahol egyszerűen és önállóan bevezethető fejlesztésekről beszélünk. Továbbá lehet csoportosan is alkalmazni, ahol egy kijelölt csapat, akár több napra összeül, hogy egy adott problémára vagy területre megoldást találjon.

Egy probléma feltárásánál [5 miért alkalmazásával](https://blog.fps.hu/ot-miert-5-whys-modszer/) szoktak gyökérokot kutatni. Ilyenkor miért? kérdésekkel feltéve el lehet jutni a probléma igazi okáig és nem csak egy tünetet fogsz kezelni a megoldással.

Egy másik hasznos módszer a genchi genbutsu. Ez annyit tesz, hogy „menj és nézd meg!”. Amikor megbeszéljük másokkal, akkor ne azt mondhassuk, hogy „azt hallottam”, hanem „azt láttam”, azaz meg kell tapasztalni a problémát.

### Végszó

A Toyota vagy a Lean módszert már nagyon sok terület vette át sikeresen. Érdemes ismerni az eredeti filozófiát és alapokat, hogy megérthesd vagy jobban testreszabhasd ezeket. Még ha nem is a munkahelyen alkalmazod, akkor is jobb környezetet tudsz teremteni magadnak.
### Csináldokrácia
URL: https://blog.fps.hu/do-ocracy-megoldas-fokusz/
Last updated: 2026-07-17T08:21:41.000Z
Általában az emberek panaszkodnak. Ez se jó, az se jó. Ezt így nem lehet csinálni. Mekkora baromság ez így. Biztos vagyok benne, hogy pontosan tudod miről beszélek. Sírni, dumálni könnyű. Kérdés, hogy ilyenkor mit lehet tenni?

Tudjuk, hogy semmi sem lehet tökéletes. Viszont törekedni kell rá. És itt bújik meg egy lényeges dolog. A hozzáállás. Az, hogy a megoldás irányába mozdulunk. Ha valaki szajkózza a problémákat, egyszerűen csak kérdezz vissza: mi a javaslatod arra, hogy jobb legyen? Ilyenkor megtorpannak az emberek, elgondolkoznak és jön a válasz: *ööö, nem tudom*.

Kicsit hasonlít ez arra, amikor felismerünk egy problémát, összehívunk egy megbeszélést, ahol jól körbejárjuk azt (ez nyilván fontos) és talán eljutunk oda, hogy valamiféle közös megoldási javaslattal is előálljunk. Az esetek többségében szerveződik egy újabb megbeszélés, majd rosszabb változatokban még egy, és még egy. Közben pedig telik az idő, a gond továbbra is roncsol, nehezen születik meg a feloldás. Ez a folyamat sokban emlékeztet a demokrácia intézményeinek működésére.

Éppen ezért (is) jött létre a do-ocracy, amely gondolatiságot magam is próbálok hasznosítani hétköznapjaimban. A fenti példára vonatkoztatva a lényeg annyi, hogy előbb egyedül (vagy kis körben) kidolgozok a problémára egy megoldást, és azt viszem a többiek elé. Az már egy erős javaslat, amiről lehet beszélni, amit meg lehet köpködni. Persze előfordul, hogy végül nem az lesz a befutó, viszont a puszta léte, eleve ráállítja a megbeszélés résztvevőinek agyát arra, hogy a megoldásra fókuszáljanak és ne a problémát rágják meg sokadszorra. Ez a módszer elképesztően fel tudja gyorsítani a folyamatokat, használd te is!

#### Do-ocracy

Persze a [do-ocracy](https://www.noisebridge.net/wiki/Do-ocracy?ref=blog.fps.hu) nem teljesen erről szól, ugyanis az valójában egy decentralizált szervezeti struktúra, ahol azok döntenek, akik tesznek valamit. Akik csak dumálnak és nem csinálnak semmit, kimaradnak az irányításból, döntésekből.
### Atomic gyorsteszt
URL: https://blog.fps.hu/atomic-gyorsteszt-prototipus/
Last updated: 2026-07-17T08:21:52.000Z
A finom mikrointerakciók nagyban hozzájárulnak a „wow faktor” eléréséhez, egy applikáció megértéséhez, visszacsatolást adnak, lélegzőbbé, emberközelibbé téve a kapcsolatot ember és gép között. Persze ne felejtsük el, hogy mindenekelőtt a logikusan átgondolt felhasználói felület az alapja egy jól kezelhető alkalmazásnak.

Mac-en jobbnál jobb eszközök állnak rendelkezésre, kezdve a Framer X-től a Principle-ön át a Flintóig, csak hogy párat említsek. Ellenben Windows-on sajnos más a helyzet, nem igen vannak, illetve csak butított funkcionalitású progik, például a Figmának a saját eszközei nem az igaziak, egy egyszerű screen flow-ra tökéletesek, de ha már összetettebb animációkat szeretnék interakcióra megjeleníteni, nos, ott elvérzik. A napokban akadtam rá [az Atomic nevű böngészőben futó prototipizáló programra](https://atomic.io/?ref=blog.fps.hu), ami talán mentsvárként szolgálhat nekünk, Windows usereknek. Igyekeztem célirányosan az animációs, interakciós lehetőségeit vizsgálni, tesztelni.

#### Design, nem csak animáció

Bizony, alap shape-ket, szövegeket, bizonyos kiterjesztésű raszteres képeket, sőt még SVG file-okat is kezel az Atomic. Ezeknek manipulálhatod a tulajdonságait, például drop shadow, fill, csupa basic tulajdonság, amik Figmából vagy Sketch-ből ismerősek lehetnek. Tulajdonképpen tervezhetsz is benne minimal appokat, landingeket, bár én speciel jobban szeretem ezeket összerakni Figmában, majd kiexportálom elemenként és behívom őket Atomicba. Belefutottam olyan bugokba, hogy ha pl. egy maszkolt elemet akarsz kimenteni SVG-be, szétesik. Ezeket érdemes inkább PNG-ként exportálni, vagy ha egyszerűbb dologról van szó, újraépíteni Atomicban.

![design](https://blog.fps.hu/content/images/2019/01/design.png)

#### Transition fajták

Az Atomicban 3 főbb transition fajtát különböztetünk meg. Az úgynevezett click through azaz, amikor egyszerű hotspotokkal kötögeted össze az egyes képernyőket, semmi sallang, felhasználói útvonal tervezésre ideális lehet. A második egy kicsit finomabb megoldás, amikor a page transition típusú áttünést választod, több fajta mozgást állíthatsz be, ilyen pl: Slide Right, Slide Up, Push Left, hogy néhányat említsek. Ami külön plusz pont az Atomicnak, hogy van Easing opció is, kicsit dinamikusabbá téve a mozgásokat.  
A harmadik és talán legérdekesebb animációs típus a Custom Transition. Lényegében ezek szolgálnak a mikrointerakciók kidolgozására. Remekül alkalmazhatod egy toggle switch mozgás animálására. De akár, ha egyidőben szeretnél megmozgatni több elemet, akkor is ez a technika lesz a nyerő.

![tranzicio-tipusok](https://blog.fps.hu/content/images/2019/01/tranzicio-tipusok.png)

#### Idővonal

Ez az a feature, amire felkaptam a fejem, sem Figmában, sem Invisionben, és azt hiszem Axure-ben sincs idővonal, ha csak a Windows-os eszközöknél maradunk. Sokat vártam ettől a funkciótól, de sajnos nem azt kaptam, amire számítottam. Elég döcögös a használata, az Ease-In effektnek koránt sincs olyan kinézete, mint After Effectsben. Igen, elismerem, az After Effects az animációkészítés Ferrarija, felesleges is összehasonlítani őket. Felmerül a kérdés, valóban indokolt olyan sok effortot belerakni egy prototípusba? Sokszor célravezetőbb, ha csak mutatunk egy hasonló áttünést az ügyfélnek egy másik appból, és fejlesztés során készül a tényleges animáció.

![idovonal](https://blog.fps.hu/content/images/2019/01/idovonal.jpg)

#### Page Actions

Hasznos funkció, egyik gyakorlati felhasználása például preloader animációnál alkalmazható. Beállíthatunk egy számlálót, hogy meddig tartozkodjon a prototípus egy adott képernyőn, majd milyen tranzícióval menjen tovább egy általunk meghatározható nézetre. Vegyünk egy login folyamatot. Beírjuk a belépési adatainkat, rákattintunk a „Belépés” CTA-ra, utána továbbküldjük a prototípust a következő képernyőre ahol 2000 ms-ig várakozik, közben egy ismétlődő anim gif pörög, szemléltetve a kamu töltést. 2000 ms után tovább megy a következő képernyőre (mondjuk egy dashboard-ra) akár valamilyen page transition-nel, vagy egy saját custom transition-nel. Ezt a pici kis animációt Atomicban készítettem.

#### Összegzés, személyes benyomások

Bő két napot töltöttem az Atomic társaságában, kifejezetten az animációs, illetve prototype lehetőségeit kutatva. Nyilván idővel az ember megtanul együttélni a hiányosságaival, gyorsabban kezeli a programot, rájön apró fortélyokra. Megszereti. Talán túl sokat vártam tőle, annyira az Invision Studio és a Framer lebegett a szemem előtt, hogy majd talán most megtalálom a Windows alternatíváját. Nem, nem találtam meg, de találtam helyette egy egész jó progit, amiben van potenciál, viszont még csiszolni kell. Annál is inkább, mert jön a Phase, illetve talán egyszer befut az Invision Studio Windows változata is.
### Esettanulmány: Hogyan digitalizáltuk a Rossmann webshop rendelés ellenőrzés folyamatát
URL: https://blog.fps.hu/esettanulmany-hogyan-digitalizaltuk-a-rossmann_webshop-rendeles-ellenorzes-folyamatat/
Last updated: 2026-07-17T08:22:04.000Z
Ahogy egy webáruházban is törekedni kell a leghatékonyabb folyamatok kialakítására, úgy a logisztikában is fontos a gyors és pontos munkavégzés.  
A weben létezik erre számos analitikai megoldás, de mi a helyzet egy raktárban?  
Na ilyen tervezési kihívásokról olvashatsz a Rossmann egyik projektjén keresztül.

### Előzmények

A Rossmannal sok közös projektünk volt az elmúlt évek során. Készítettünk webshop appot [iOS](https://itunes.apple.com/hu/app/rossmann/id1121545908?l=hu&mt=8&ref=blog.fps.hu)\-re és [Android](https://play.google.com/store/apps/details?id=bitnet.hu.rossmann&ref=blog.fps.hu)ra, terveztünk landoló oldalt a [Rossmann+](https://shop.rossmann.hu/rossmannplussz?ref=blog.fps.hu) bevezetéséhez és folyamatosan együttműködünk a [webáruház](https://shop.rossmann.hu/?ref=blog.fps.hu) felületének megújításával kapcsolatban is.

Legutóbb más problémával kerestek meg minket: egyszerűsítsünk az egyik raktári folyamatukat, egy app fejlesztésével.

### A probléma

Alapvetően egyszerű a folyamat. A Rossmann minden egyes csomagot manuálisan is ellenőriz kézbesítés előtt, hogy a vásárló biztosan azt kapja, amit rendelt.  
Ha megfelelő a rendelés, akkor mehet postára, de ha bármi eltérést találnak, akkor megy vissza a raktárba „javításra”.

Vásárlói oldalon ez nagy biztonságot és kiemelkedő elégedettséget eredményez, logisztikai oldalon ugyanakkor meglehetősen időigényes folyamat. A probléma pedig ott kezdődik, hogy az ellenőrzés teljesen analóg, nyomtatott listák alapján történik. A dolgot pedig az is fűszerezi, hogy a nagyobb terhelési időszakokban (karácsony, JOY-napok) idénymunkások is segítik az állandó raktári alkalmazottak munkáját.

![doboz_ellenorzes](https://blog.fps.hu/content/images/2019/01/box-2.jpg)

Ez pedig a következő 3 szempont szerint okoz gondot:

**1\. Nagy hibafaktor**

- Megeshet, hogy az ellenőrző személy egyszerűen félreolvassa egy termék nevét
- Könnyen össze lehet keverni két terméket (citrusos tusfürdő / citromos tusfürdő)
- Össze lehet keverni két rendelés azonosítóját is
- Aki csak ideiglesen dolgozik a raktárban, kevesebb tapasztalattal rendelkezik, még nagyobb eséllyel hibázik

**2\. Sok időt igényel**

- Kinyomtatod a listát -> megkeresed hozzá a dobozt -> alaposan megnézed a termékeket, hogy ne legyen keveredés -> eldöntöd, hogy rendben van-e vagy sem
- Az új alkalmazottaknak meg kell tanítani a folyamatot, az elején felügyelni kell a munkát

**3\. Nincsenek mérések**

- Nincs semmilyen adat a hibás csomagok arányáról és az egyes műszakok teljesítményéről

### Célok

A problémák alaposabb megismerése után a következő célokat határoztuk meg:

- Az appnak „vezetnie” kell: bármilyen felhasználónak előzetes oktatás nélkül el kell tudnia végezni az ellenőrzési folyamatot
- A lehető legegyszerűbb és leggyorsabb folyamatra kell törekedni
- Minimalizálni kell az emberi hibafaktort, az ellenőrzéseket az appnak kell elvégeznie
- Minden egyes ellenőrzés adatait rögzíteni kell és felhasználható formában meg is kell jeleníteni
- Jah igen… Az egésznek azon az eszközön kell futnia, amit a Rossmann a raktári munkához biztosít

### Tervezés

Az egész projekt legfontosabb és legérdekesebb része a tervezés volt. Nem is annyira a felületek megrajzolása, sokkal inkább a céleszköz és a munkafolyamat megismerése és a megfelelő folyamat felépítése.

Ahhoz, hogy valóban hasznos alkalmazást készítsünk, teljesen meg kellett ismerni a céleszköz lehetőségeit és a folyamatot is olyan szinten ismernünk kellett, hogy akár mi magunk is beállhassunk rendelést ellenőrizni.

Előbbihez egy kifejezetten raktári munkára kialakított [Zebra](https://www.zebra.com/us/en/products/mobile-computers/handheld/tc52-tc57-series-touch-computer.html?ref=blog.fps.hu) telefonra esett a Rossmann választása, amely Android operációs rendszert futtat és a vonalkód olvasó lézeren túl, meglehetősen [masszív](https://www.instagram.com/p/BhrCWQJAirE/?ref=blog.fps.hu) kialakítással is rendelkezik.

![zebra_mobile](https://blog.fps.hu/content/images/2019/01/zebpra.jpg)

Utóbbihoz pedig részletesen bemutatták nekünk a raktári folyamatot.

#### És ez elég volt?

Cseppet sem.

Addig rendben vagyunk, hogy mit csinálnak a raktárban és mire kellene appot írni, de mi lenne a jó folyamat?

Ennek megfejtéséhez már bábozni kellett. Ehhez kaptunk egy szép nagy csomagot, tele minden fajta termékkel, illetve a telefont is használhattuk.  
Körbeültük az egészet és elkeztünk terméket ellenőrizni…

Hasznos volt? Nagyon!  
Számos felismerés történt, leírom a legérdekesebb hármat:

#### Kerülni kell a tappolást

Értintőképernyős, Androidos telefonra fejlesztünk, mehet is bele minden fajta király gomb…

Hát nem. Az eszközön található egy fizikai gomb, amivel a vonalkódot kell beolvasni. A valóságban pedig nagyon macerás volt a dolog, mert folyamatosan változtatni kellett, hogyan tartjuk a telefont, attól függően, hogy vonalkódot olvasunk be, vagy valami interakciót hajtunk végre az app-ban.

Ezután egyértelművé vált az irány: minden interakciót egy gombhoz kell kötni.

#### Nem számít mi van a csomagban

Oké, termékeket kell azonosítani. Jöhet egy lista a doboz tartalmáról (képpel, névvel, esetleg cikkszámmal), majd minden egyes beolvasáskor pipáljuk a helyes tételeket. (Gondolta mindenki, akinek köze volt a projekthez).

Nos, ez sem pont így van. Mert kiderült, hogy a folyamat megfelelő elvégzéséhez egyáltalán nem kell tudnom mi van a dobozban. Csak be kell olvasni mindent, a többit majd megoldja az app.

Így tervezéskor eggyel kevesebb képenyő vált szükségessé, a fejlesztésre eggyel kevesebb funkció került, a felhasználó pedig megszabadult egy komplex és felesleges résztől. Mindenki örül.

#### Egyforma terméket gyorsabban is lehet ellenőrizni

Ha valamiből több darabot rendeltek, gyakorlatban egyszerűbb beírni, hogy mennyi van a dobozban, mint egyesével beolvasni.

Ennek kezelésére, egyszerűen átvettük az áruházakban már ezer éve létező megoldást: Több egyforma termék esetén, a pultos beolvassa az elsőt, majd bepötyögi hány darab van belőle.

Az appban szükségessé vált egy automatizmus, ami felismeri, hogy több darabot rendeltek-e az adott terékből. Ha pedig ilyet olvasnak be, meg kell jelennie egy ablaknak, amiben meg lehet adni a pontos mennyiséget.  
(Egyetlen érintős megoldás az egész folyamatban).

### Folyamat

A fenti tudás birtokában már nekiláthattunk a folyamat tervezésnek.

![mobile_screens](https://blog.fps.hu/content/images/2019/01/mobile_screens.jpg)

#### Autentikáció

Minden alkalmazottnak egyedi vonalkódot tartalmazó kártyája van. A munka elkezdéséhez elengedő beolvasni a kódot és az app belépteti a felhasználót, majd jelzi a következő lépést:

#### Csomag beolvasása

A felhasználó egyszerűen beolvassa a rendelés dobozán lévő vonalkódot. Az app a háttérben beazonosítja a webáruházban lévő rendelést és letölti annak termékeit és hozzátartozó cikkszámokat is. Majd jelzi a következő lépést:

#### Termékek beolvasása

A kijelzőn megjelenik az adott rendelésben lévő termékek száma.

A felhasználó beolvassa a termékeket és nagyobb darabszám esetén felugró ablakban beírhatja a pontos mennyiséget. Az ablakhoz gyors gombok is tartoznak, amik a leggyakoribb kiszerelések számát tartalmazzák, így még gyorsabb a folyamat.

Minden egyes beolvasáskor csökken a kijelzőn lévő termékszám, 0-nál pedig jelzi a következő lépést:

#### Csomag zárása

Az ellenőrzést végző személy a doboz vonalkódjának újbóli leolvasásával jelzi, hogy befejezte a beolvasást. Ekkor az alkalmazás összahasonlítja a rendszerben lévő adatokat a valós adatokkal. Amennyiben minden megfelelő, zöld jelzést ad és el lehet küldeni a csomagot, de ha bármi eltérést talál, akkor vörös jelzést mutat és vissza kell küldeni „javításra”. Mind a két eredmény után újra kezdődik a folyamat. Az adatok pedig továbbításra kerülnek későbbi felhasználásra.

### Fejlesztés

Miután megvolt a megfelelő folyamat, már minden könnyen ment.

Tervező kollégáim gyorsan elkészítették a látványteveket. Egyszerűek és könnyen érthetőek, semmi felesleges elem.

Azok alapján pedig lefejlesztettük az Android appot is, amihez végig a Zebra készüléket használtuk.

A felhasználók kezeléséhez és az adatok feldolgozásához pedig külön admin felület készült a Rossmann számára.

### Éles használat

A rendszer tesztelése eleinte néhány fővel történt, amely során főként bugok javítására és kisebb felület optimalizálásra került sor.

A nagy megmérettettés pedig az őszi GLAMOURE-napok alatt zajlott, amikor a megnövekedett rendelések ellenére időben sikerült ellenőrizni a dobozokat és mindenki rendben megkapta a csomagját.

És miért vagyunk erre büszkék? Ehhez hadd osszam meg azt a visszajelzést, ami talán a legjobban leírja az app előtti állapotot:

> A logisztikai applikációval alapvetően megmentették a Glamoure napunkat, ezt szeretnénk megköszönni.

Maga az alkalmazás és az admin felülete pedig a mai napig használatban van, amit kisebb-nagyobb kiegészítésekkel a mai napig optimalizálunk a hatékonyabb munkavégzés érdekében.

### Összegzés

A Rossmann Logisztikai appja nagyon jól megmutatja, mennyire hasznos tud lenni egy egyszerűbb alkalmazás is, amennyiben megfelelően megismerjük a folyamatokat és a felhasználók problémáit.

Érdemes ezt fejben tartani, mielőtt beleugrunk egy költségesebb fejlesztésbe.

Ha pedig érdekel, milyen az app, nézd meg a [behance](https://www.behance.net/gallery/73747471/Rossmann-Logistic-app?ref=blog.fps.hu) oldalunkon.
### Frissítések mobil fronton
URL: https://blog.fps.hu/frissitesek-mobil-fronton/
Last updated: 2026-07-17T08:22:13.000Z
Az elmúlt időben sok szolgáltatás frissítette követelményeit vagy saját kódbázisát, ami miatt saját alkalmazásodhoz is lehet hozzá kell nyúlnod. Összeszedtem ezeket egy listába, hogy könyebben áttekinthetőbbek legyenek.

### Cél az Android 8.0

Android 8.0-át, azaz API 26-ot kell megcéloznia az új verzióknak 2018\. augusztus 1-től és a frissítéseknek 2018\. november 1-től. A megcélzás azt jelenti hogy az appod tesztelve lett azon a verzión és képes az OS azon verziójának képesséeit használni.

Létrehoztak egy [hasznos leírást](https://developer.android.com/distribute/best-practices/develop/target-sdk?ref=blog.fps.hu), amiben azok a főbb funkciók vannak listázva, amik bekerültek az OS-be.

Egy régi app frissítése ilyenkor sajnos együtt járhat Android Gradle Plugin, Gradle verzió és support library frissítéssel is. További függőségek frissítésére is szükség lehet akár, ami főleg régebbi Android 6-ot megcélzó alkalmazás frissítésekor problémás. Ilyenkor az is sok időbe telhet, hogy leforduljon a projekt, nem hogy a kódban változtatásokat hajtsunk végre.

Ezt a frissítést akár évente is kell majd végeznünk mivel minden éven eggyel feljebb kúszik majd a megkövetelt cél verzió.

### Google Drive Android SDK lekapcsolása

A Google Drive Android SDK 2019\. október 21-től nem lesz elérhető és 2019\. december 6-tól az Android API-ról indított hívások nem fognok működni. Ez azt jelenti át kell állni a REST API-ra.

A [leírásból](https://developers.google.com/drive/android/deprecation?ref=blog.fps.hu) kiderül, hogy a REST API-hoz van Java wrapper, ami a legtöbb projecthez elegendő, de vannak azért fájdalmas pontok mint a szinkronizációt neked kell megoldani és az app data könyvtárat ki fogják dobni.

### LinkedIn API követelmények

[Kötelező lesz](https://engineering.linkedin.com/blog/2018/12/developer-program-updates?ref=blog.fps.hu) 2.0-ás API verziót és OAuth 2.0-ás azonosítást használni 2019\. március 1-től. Ennek az a következménye hogy a mobil SDK-juk használhatatlan lesz és [REST API](https://docs.microsoft.com/en-us/linkedin/consumer/?ref=blog.fps.hu)\-ra át kell állni.

### GCM → FCM váltás

Google Cloud Messaging azaz a push üzeneteket küldő szolgáltatást 2019\. április 11-ig át kell rakni Firebase CLoud Messaging-re. Ezt mind a szerver oldalon mind a kliensen meg kell tenni.

A kód átírása egyértelmű és van normális [dokumentáció](https://developers.google.com/cloud-messaging/android/android-migrate-fcm?ref=blog.fps.hu) is hozzá. Ha Firebase szolgáltatást hozol a projectedbe, akkor automatikusan kapsz analitikát vele együtt, amit ki kell kapcsolni ha nem kell.

### Google Analytics → Firebase Analytics migráció

A mobil Google Analytics SDK-t le fogják kapcsolni, aminek határideje 2019 október 31\. Ekkor fog leállni az adatgyűjtés, ezért Firebase Analytics-ra javasolják az átállást.

Dokumentáció sajnos nincs, hogy könyebben a megfelelő hívásokra cseréljük le a meglévőket. Sok esetben ki lehet találni, mi felel meg minek, de érdemes lehet egy online marketinges segítségét kérni a megfelelő analitika kidolgozásához.

### Fabric → Firebase migráció

Úgy néz ki mostanában mindent Firebase-re kell mozgatni. A Fabricot a Google felvásárolta és most integrálják a Firebase szolgáltatásukba, aminek a határideje 2019 közepe lesz. A menetrendről és az aktuális átállás állapotáról készítettek egy [weboldalt](https://get.fabric.io/roadmap?ref=blog.fps.hu).

Jelenleg is át lehet állni kevés kód írásával, de nem minden funkciót mozgattak még át és a jó ismert felület is megváltozik.

### Store irányelvek frissülése

A Play Store irányelveit, amit az Android alkalmazásoknak be kell tartaniuk, is rendszeresen frissítik.

A legutolsó októberi frissítésben visszahangot kiváltó módosítás, hogy Androidon SMS olvasáshoz, íráshoz és a híváslistához való hozzáférés korlátozva lett és csak az alapértelmezett SMS vagy telefon alkalmazásnak lehet ilyen engedélye. Ha más esetben szükséged van ilyen engedélyre egy ki kell töltened egy űrlapot, amit majd elbírál a Google. Egyszerűbb esetekben, mint a hívás indítása, megfelelő Android API-t kell használni. Ennek a szabálynak a betartatása 2019\. januárban kezdődik majd.

Mind az Apple mind a Google alkalmazásboltjában jobban figyelnek az adatvédelmi irányelvek elérhetőségére. iOS alkalmazás 2018\. október 3-tól csak ilyen irányelv meghatározásával lehet frissíteni vagy kiadni. Androidnál pedig ellenőrzik, hogyha advertising ID-t használ az alkalmazásod, akkor kötelező megadni irányelvet az adatlapon és alkalmazásban.

### Facebook frissítések

Egy Facebook API verzió élettartalma 2 év, majd amikor megszűnik a következő eggyel nagyobb éles API verzióra irányítják a hívásokat.

Ha az [api verziók érvényességét](https://developers.facebook.com/docs/graph-api/changelog/breaking-changes?ref=blog.fps.hu) megnézzük kürülbelül 3 havonta vége van egy verziónak, de szerencsére egy alapvető integrációt nem kell folyamatosan frissíteni.

Migráció esetén van [segédeszköz](https://developers.facebook.com/docs/graph-api/advanced/api-upgrade-tool?ref=blog.fps.hu), ami megmondja mely API hívásaid érintettek.

### Összegzés

Tisztán látszik, hogy az alkalmazásodat is folyamatosan karban kell tartanod. Ha ezt nem teszed meg, akkor nem maga a kód megy tönkre, hanem a környezet és használt szolgáltatások változnak meg annyira, hogy az már elévültnek fog számítani.
### Dolgozz otthon is hatékonyan
URL: https://blog.fps.hu/dolgozz-otthon-is-hatekonyan/
Last updated: 2026-07-17T08:22:23.000Z
Nem újdonság, hogy a digitális világban dolgozók otthonról is végezhetik feladataikat. Egyre többen maradunk otthon rész vagy akár teljes munkaidőben, ugyanakkor a nagy szabadság könnyen a hatékonyság rovására mehet. Emiatt már számos írás született a témában, ami megpróbálja összeszedni azokat a trükköket, amelyek segíségvel fókuszban maradhat az ember.

Sok ismerősömnél tapasztaltam, hogy a bőséges szakirodalom ellenére az otthon töltött napokon kevésbé sikerül teljesíteni. Így én is összeszedtem azt a 8 tanácsot, ami nálunk a legjobban bevált.

Nézzük is meg:

### 1\. Dolgozz felhőben!

A cél, hogy minden munkához szükséges állományod elérhető legyen távolról.

![Dolgozz felhőben!](https://blog.fps.hu/content/images/2018/12/dolgozz-felhoben.png)  
**Tapasztalat:**  
Ha nem egy egyfős szupercsapat vagy, felhő nélkül gyakorlatilag lehetetlen otthonról dolgoznod. Elképesztően macerás és időrabló nagyobb anyagokat szükség esetén elkérni vagy valakinek továbbítani.  
Fontos, hogy ne csak te lásd, ami neked kell, azok is férjenek hozzá a dolgaidhoz, akiknek szüksége van rájuk a munkájukhoz.

### 2\. Öltözz ki!

Ez egyszerű. Öltözz fel, mintha bemennél dolgozni (az öltöny nem kötelező).

![Öltözz fel!](https://blog.fps.hu/content/images/2018/12/oltozz-fel.png)  
**Tapasztalat:**  
Kicsit vicces, de a legalapvetőbb teendőd. Az agy különböző „üzemmódokban” képes működni, amelyek között kis gyakorlással nagyon könnyen lehet kapcsolgatni. Amikor felveszed a ruhád, azt mondod az agyadnak, hogy elkezded a munkát, így az jobban fog figyelni a feladataidra és kevésbé kalandozik el a figyelmed.  
Pályám elején gyakran dolgoztam az ágyamban ülve, meglehetősen alulöltözve. Ezzel pedig pontosan azt mondtam magamnak, hogy vasárnap délőtt van, mehet a lustálkodás. Persze így sem lustálkodtam, de a fantáziádra bízom, mennyit haladtak előre aznap a dolgaim.

### 3\. Találd meg a helyed!

Szükséged van egy dedikált helyre, ahol dolgozol.

![Találd meg a helyed!](https://blog.fps.hu/content/images/2018/12/talald-meg-a-helyet.png)  
**Tapasztalat**  
A kanapén fájni fog a derakad, az ágyban meg mindig lustálkodni fogsz. A legjobb egy rendezett íróasztal, ahol közel van minden, ami a munkádhoz kell.  
Ez egyébként pont olyan kapcsoló, mintha felöltözés. Továbbá segít leválasztani magad az otthoni környezetről (erről még írok lentebb).

### 4\. Ne felejtsd a napi tervet!

Tervezd meg, hogy aznap mit csinálsz ma és milyen sorrendben.

![Napi terv](https://blog.fps.hu/content/images/2018/12/napi-terv.png)  
**Tapasztalat:**  
Korábban már írtunk a [tervezés fontosságáról](https://blog.fps.hu/idomenedzsment-a-gyakorlatban-8-tipp-es-egy-kis-modszertan/). Az otthoni munkavégzés során ennek kiemelt jelentőssége van, mert a napi terv mutatja azt az utat, amiről nem kellene letérned.  
A lista megmondja mit, mi után kell csinálnod és kb. mi számít a munka végének. Enélkül az ember figyelme hajlamos elkalandozni és más érdekesebb tevékenységet keresni.

### 5\. Mutasd meg magad!

Az otthoni nap is ugyanolyan munkanap mint a többi. Ne hagyd, hogy erről megfeledkezzenek a munkatársak.

![Mutasd meg magad!](https://blog.fps.hu/content/images/2018/12/mutasd-meg-magad.png)  
**Tapasztalat:**  
Ha nem vagy az irodában, a többiek nem látnak. Ha nem látnak, akkor hajlamosak úgy kezelni, hogy szabadnapod van. Emiatt nem, vagy kevésbé számolnak veled egy-egy feladat kapcsán.  
Ahhoz, hogy ne maradj ki a csapatmunkából, tartsd a kapcsolatot a többiekkel. Telefonálj, chatelj, skypeolj stb…  
A lényeg, hogy a fizikai távolság ellenére ne távolodjatok el.

### 6\. Védd a munkaidőd!

Ne felejtsd el, dolgozol és ezt tudasd a környezeteddel is.

![Fókusz-fókusz!](https://blog.fps.hu/content/images/2018/12/fokusz-fokusz.png)  
**Tapasztalat:**  
Szüleimben a mai napig nem tudatosult, hogy amikor a számítógép előtt ülök, akkor dolgozok. Ezzel pedig nem vagyok egyedül.  
Ha abban a közegben végzed a munkád, ahol egyébként is élsz és elérnek a rokonok vagy barátok, nagyon oda kell figyelned, hogy megértsék, munkában vagy. Ők úgy látják, hogy otthon vagy, ezért úgy is kezelnek. Ezért a kommunikáción túl, jó segítség egy fix hely használata (3), mert az ottléted egyértelmű jel, hogy hagyjanak békén.  
Fontos, hogy te se tervezz személyes dolgokat munkaidőre. Ez olyan mintha haverokat vagy gyereket vinnél munkába: Félévente poén, hetente már nem működik.

### 7\. Nem vagy egyedül!

Néha mozdulj ki és tartsd a kapcsolatot a többiekkel.

![Tartsd a kapcsolatot!](https://blog.fps.hu/content/images/2018/12/tartsd-a-kapcsolatot.png)  
**Tapasztalat:**  
Az otthoni munka nagyon ingerszegény tud lenni, ülsz a négy fal között és nem találkozol senkivel.  
Mozdulj ki pár percre két feladatok között vagy beszélj egy kicsit egy-egy munkatársaddal munkán kívüli dolgokról. Ez a rövid idő, nem fogja felborítani a napod, de sokat segít, hogy ne fásulj bele az otthoni környezetbe.

### 8\. Maradj a kereteken belül

Legyen meg pontosan, hogy mikor kezded a munkát és az is, hogy mikor fejezd be.

![Kereteken belül](https://blog.fps.hu/content/images/2018/12/kereteken-belul.png)  
**Tapasztalat:**  
A digitalizációval egyre jobban keveredik a munka és a magánélet. Ha otthonról dolgozol, akkor pedig nagyon kicsi lesz a távolság (konkrétan pár lépés a hűtő).  
Ahhoz, hogy a magánéleted ne keveredjen bele a munkádba és fordítva, meg kell húzni a határt. Erre jó megoldás, ha fixálod meddig dolgozol, majd megtervezed mit tudsz megcsinálni addig (4), keresel egy helyet, ami csak a munkáról szól (3) és úgy dolgozol, mintha az irodában lennél (2).

### Összegzés

Az otthoni munkavégzés egy nagyon jó lehetőség. Segít egy kicsit kiszakadni a munkahelyi közegből. Továbbá, segít megoldani olyan dolgokat, amikhez egyébként szabadságot kellene kivennünk, legyen az enyhébb betegség vagy egy szerelő várása.

Mindazonáltal, a felügyelet hiánya és a szabadság nagy önfegyelmet igényel. Ezért fontos, hogy meglegyenek a szokásaink, amelyek az úton tartanak. Ha az ember egy kicsit odafigyel a fenti pontokra a homeoffice valóban hatékony munkát jelenthet az otthon kényelmével megtámogatva.
### Hozzá kell nyúlnod a céged arculatához. Hogy csinálod? – Vol.1
URL: https://blog.fps.hu/hozza-kell-nyulnod-a-ceged-arculatahoz-hogy-csinalod-vol-1/
Last updated: 2026-07-17T08:22:32.000Z
Túl vagyunk egy sikeres rebrandingen, a folyamatot időközben brand stretchingnek neveztük, volt lelkizős része is, a végeredményt a szakma eléggé szerette, [több mint 3000-en voltak rá kíváncsiak](https://www.behance.net/gallery/70916301/Its-kind-of-a-rebranding-story?ref=blog.fps.hu), mi is szeretjük, ezért most elmesélem, hogy készült.

Megint hosszú lesz, ráadásul ez csak az első rész, szóval muszáj szólnom, hogy aki azért kattintott, mert érdekli, hogyan kell márkázni, lesz arról is szó, de azért az is van, hogy ne ez alapján állj neki egymagadban, és ne ezzel idegesítsd azt sem, akit felkértél a feladatra. Fordulj olyan szakemberhez, akiben megbízol, hagyd dolgozni, úgy gyorsabban kész leszel, és nem hullik ki az összes hajad közben. Plusz,

### Mindig lesz kire mutogatnod, ha valami nem tetszik.

Nade, haladjunk is, aki azért jött, mert érdekli, hogy milyen körülmények között születik egy arculat újra, mik a hogyanok, mik a miértek, nekik most többet fog mondani ez a cikk. Kb. 7 percben.

### Elöljáróban.

\- Alkalmaztunk klasszikus márkázási metodikát?  
\- Igen.  
\- Feltétlen erre volt szükség?  
\- Nem.

Vagyhát, attól függ. Mindig minden attól függ. Az van, hogy persze, ott a hivatalos rész, és akkor ezt nevezzük rebrandingnek, de az is van, hogy nem a feladatnál (rebranding) kezdődik soha semmi.

Általában inkább az van, hogy van, amit feladatként nevezel meg (pl. rebranding), és van egy adott helyzet mögötte, amit vagy tudomásul veszel, vagy nem. És mondjuk, ha ég a ház, szerintem jobb, ha belátod.

[![Homer Simpson egy égő szobát bámul nyugodtan](https://blog.fps.hu/content/images/2018/12/burn.gif)](https://media.giphy.com/media/xuZ7YYzYw5rz2/giphy.gif?ref=blog.fps.hu)

### Függetlenül attól, hogy az adott helyzeteket tudomásul veszed vagy sem, hatással lesznek a feladatra.

És ez a helyzet lehet aztán tényleg bármi. Esik a leadjeid száma, megjelent valaki nálad jobb vagy olcsóbb a piacon, de helyzet az is, hogy elég gáz dolgokat műveltek az embereid nyilvánosan, és most tisztára kéne mosni a céget minden lehetséges eszközzel (Uber, VW). A lényeg, hogy tudd, hogy mi a helyzet, mert ennek függvényében (is) fog sikerülni, vagy nem sikerülni a feladatod.

Tök mindegy, hogy épp UX vagy szolgáltatástervezésben vagy, üzleti validálsz, terméket fejlesztesz, kampányt vagy márkát tervezel.

### Minden folyamatot megelőz egy folyamat, amit végig kell(ene) csinálnod.

Minden megbízásnál, mindegyik projekten az ilyen (háttér)helyzetek miatt (is) történnek vagy nem történnek meg a várt eredmények. Mégis, ügynökségként – de szabadúszóként is – általában mégis már csak a végével foglalkozol, azzal, hogy akkor mi a feladat.

Eddig enged be az ügyfeled, ennyit fizet ki, meg nem a te dolgod, meg miért nem szedte össze rendesen, és miért nem mondta el rendesen, mit akart, és mert mindig van egy mert. Pedig, ha mindig hátrébb tudnánk sétálni, el addig a helyzetig, ahonnan már legalább látszik, hogy mit és miért kell megoldani, onnan azért kisebb lenne a bukás esélye. Tehát,

### Helyzet > Feladat

Menjünk is tovább. A mi helyzetünk a feladat mögött az volt, hogy nagyjából másfél éve [fuzionált és házasságot kötött két cég](https://blog.fps.hu/hazassag-fps-webugynokseg-virgo-creative-magyar-digitalis-piac-fps-ugynokseg/), ez pedig szép lassan felszínre hozott egy csomó dolgot, köztük megoldandó feladatokat kívül-belül.

#### Külső feladatok

Kommunikáció. Sales. HR. A bővüléssel járó tudás- és erőforrás gyarapodásról, az új divíziókról nem tudott sem a piac, sem az ügyfelek, a munkák miatt nem volt idő a kommunikáción dolgozni, mégis egyre nehezebbé vált a sales munkája, és egy idő után nehezebb volt megtalálni a megfelelő embereket is.

#### Belső feladatok

Különböző cégkultúrák, ebből fakadó különböző folyamatok, különböző érzések, különböző hagyományok, kétszer annyi intéznivaló és csomó szervezeti változás jött. Rengeteg új ember, aki érezte, hogy valami nem oké, de nem tudta mi a baj, és sok régi ember, aki meg tudta mi lehet a baj, de kezdte azt érezni, hogy egyedül van hagyva ebben.

Persze, erre egyrészt fel voltunk készülve, [a növekedés mindig szívás](https://blog.fps.hu/magyar-digitalis-ugynokseg-piac/) és találtunk is érdekes megoldásokat aktuális problémák helyi kezelésre (mi voltunk azok, akik tavaly [megszondázták a magyar reklámosoka](https://blog.fps.hu/reklamugynokseg-allashirdetes-kerdoiv-tapasztalatok/)t, csak azért, hogy megtaláljuk az új munkatársunk) de ettől függetlenül kellett a nagy egész kitalálása, mert kezdett egyre nehezebbé válni minden.

### A közösség mellé közös vízió és a közös nyelv is kellett

Olyan vízió, amiben mindannyian tudunk hinni, olyan nyelven írva, amin mindenki beszél, és olyan egyszerűen tartva, hogy bármelyikünk el tudja mesélni a liftben egy idegennek (már, ha kérdezi) és anyának is otthon (úgyis mindig kérdezi).

#### Szóval hozzá kellett nyúlni a márkához

Na most, ha valamit meg lehet tanulni saját márkán és arculaton dolgozáskor, akkor az az, hogy óvatosan kell csinálni.

#### Érzékeny téma. És tök nagy a tétje.

Persze, nagy a tétje a partnereid márkájának is, de ha nagyon őszinték vagyunk, annak előbb-utóbb úgyis vége van. Ha nagyon nincs meg a közös hang, arrébb lehet sétálni, ha pedig a végére túl sok volt a kompromisszum, még mindig meg tudod rántani a vállad, hogy majd akkor csak azt teszed be a portfóliódba, ameddig még tetszett.

Nade! Hát ha a tied a márka, akkor ezt nem lehet. Sőt, ha nem elég jó, amit csinálsz, akkor a saját munkatársaid fogják szégyellni az egészet. Pont azok, akiktől megy a cég. És akiket nem mellesleg még szeretsz is. Legalábbis én szeretem őket. Szóval a tét nagy, és meg kell enned, amit főztél. Ez után jön az, hogy nekiállsz dolgozni.

![rebranding iteration](https://blog.fps.hu/content/images/2018/12/rebranding-iteration.png)

#### Abból indultunk ki, hogy a márka az a dolog, ami azt a sztorit meséli rólad, ami a közted és a világ közötti kapcsolatot fogja építeni.

Ha jól ki van találva, akkor valamennyire ez lehet (ennek kéne lennie) az irányzékod a későbbi üzleti, személyes és szakmai döntéseidhez is. Ennek többféleképpen neki lehet állni, mi most ezzel az 5 dologgal kezdtük.

![rebranding key moments: positioning, customer benefit, personality, aspiration, emotion](https://blog.fps.hu/content/images/2018/12/rebranding-key-moments.png)

1. **Positioning.** Tudnod kell, mit akarsz, mire gondoljon, amikor rád gondol valaki
2. **Customer Benefit.** El kell tudnod mondani, mit nyer veled az, aki téged választ
3. **Personality.** Kell egy személyiség, amilyen „leszel” és aztán olyannak kell lenned
4. **Aspiration.** Kell egy nagy NAGY cél, ami felé folyton tartasz
5. **Emotion**. Tudnod kell, mit akarsz, mit érezzen az, aki kapcsolatba kerül veled

Azért ezt az ötöt választottuk, mert a mi arculati munkánkhoz a márkának ebben a mátrixban való átgondolása most elég volt. Ebből az első hármat ki lehet szedni a positioning modellből, a második kettőt pedig a márkapiramisból. Persze, ezek azért jórészt szavak, meg rajzok, rákeresel, csomó változatát megtalálod, nem linkelek, mert nem is ez a lényeg.

A lényeg, hogy mindent fel kell töltened tartalommal, és aztán neki kell állnod a tényleges arculati kérdéseknek vizualitás és szövegezés szintjén is.

Nem úszod meg, hogy a végére meglegyen az elevator pitched, kellenek majd a cégmondat, vision- és mission statement körök, a szlogened, a versenytársaid tényleges elemzése, egy saját, jól működő világ kitalálása, és hát a szöszölés, miközben minden nagyon fontos.

![rebranding making](https://blog.fps.hu/content/images/2018/12/rebranding-making.png)

Ennek a részleteibe megyek bele a következő bejegyzésben, megmutatom a táblázataim is a káromkodós részek nélkül, meg hasonlók.

Stay tuned.  
És köszi. Tök jó, hogy olvastok.  
De azért olvassatok inkább Eszterházyt.
### Halott kód, eleven problémák
URL: https://blog.fps.hu/halott-kod-eleven-problemak/
Last updated: 2026-07-17T08:22:40.000Z
A [Wikipedia szerint](https://en.wikipedia.org/wiki/Dead%5Fcode?ref=blog.fps.hu) a halott kód a forráskód olyan része, ami lefut, viszont az eredménye soha nem lesz felhasználva a program további futása során. A halott kód futtatása felesleges memóriát és processzoridőt igényel. Ezzel maximálisan egyetérve, úgy érzem még kibővíthető a kör a kikommentezett kódrészekre továbbá a soha nem hivatkozott metódusokra. Az előzőek processzort és memóriát ugyan nem vonnak el a többi folyamattól, azonban jócskán megzavarhatják a fejlesztők munkáját. Vegyünk pár tipikus esetet:

### 1\. A feleslegesen lefutott műveletek

A szoftverfejlesztés hőskorában néhány kilobyte memóriában el kellett férnie a programnak, mivel egyszerűen nem volt több hely. Ha manapság kevés az erőforrás (web esetén legalábbis), jellemzően a rendszergazdánál kötünk ki, hogy emelje meg a memórialimitet vagy a maximális futási időkorlátot. Személy szerint azért szeretek Arduinoval játszadozni, hiszen ott még figyelni kell a memóriahasználatra és nem létezik a végtelen erőforrás illúziója.

Minden feleslegesen letudott kódsor, vagy indokolatlanul deklarált változó felesleges erőforrásokat von el futás közben, és bizony még mapanság is könnyen futhatunk olyan projektbe, ahol minden byte számít.

A rossz hír az, hogy az ilyen kódrészeket automatizáltan elég macerás kiszűrni, viszont az átgondolt tervezés, fejlesztés és a refaktorálás könnyen megoldja a problémát.

### 2\. Soha meg nem hívott metódusok

Az megvan, amikor létezik egy osztályban *getImages()* és *getImages2()* függvény is? És, miután kikáromkodtad magad, további erőfeszítéseket okoz, hogy megtaláld, most végülis melyik is az éppen használatban lévő. Legacy kódban jellemző az ilyen  
megoldás és noha kárt nem okoz, jelentősen elbizonytalaníthatja a fejlesztőt vagy éppen félreértésekhez vezethet a jelenléte.

Ide sorolhatóak azok a kódrészek is, amik egy mindig bekövetkező visszatérés vagy megszakítás után következnek, és gyakorlatilag soha nem ér el a folyamat oda, hogy lefussanak, továbbá az indokolatlanul, soha használatba nem vett változókról is érdemes megemlékezni.

Szerencsére, az ilyen problémák beazonosítása már sokkal jobban automatizálható, és létezik is hozzá kész eszköz, pl. a [PHP Dead Code Detector (PHPDCD)](https://github.com/sebastianbergmann/phpdcd?ref=blog.fps.hu)

![dead and unreachable code](https://blog.fps.hu/content/images/2018/12/dead-unreachable-code.png)

### 3\. Kikommentezett kódok

A legrosszabb dolog. Egyszerűen elkerülhető lenne, de mégis *„kitudja, mikor kellhet még”* alapon ott vannak a kikommentezett var\_dump-ok, fél függvények, vagy rosszabb esetben teljes osztályok az újraírt kóddal közös forrásfájlban.

Természetesen létezik az az eset, amikor valamit ott hagyunk megfelelő magyarázattal, vagy neadj’isten debugolsz és véletlenül ott marad egy sor. Viszont az indokolatlanul otthagyott kódok sokasága esetén a szándékosság csak súlyosbító tényező, hiszen a verziókezelőben elérhető lesz törlés után is. A tapasztalat is az, hogy minimális az esélye, hogy újrafelhasználásra kerülnek az ilyen kódrészek.

### Tartsd tisztán!

A halott kódok alapvetően megbonyolítják a mindennapi munkát, félreértésekhez vezethetnek és bizonytalanságot okoznak. Amikor csak lehet kerüld, és ne hagyj magad után felesleges kódot, ha használsz bármilyen verziókezelőt, nem tűnik el véglegesen semmi. Személy szerint azt gondolom, hogy a professzionalizmus egyik jele, hogy milyen szép kódot hagyunk magunk után, aminek egyik ismérve, hogy nincs tele haszontalan dolgokkal. Így hát csak bíztatni tudlak, hogy tarts rendet, takarítsd ki ha hasonlóval találkozol, legyen szó akár a saját, akár más kódjáról.
### Időmenedzsment a gyakorlatban,  8 tipp és egy kis módszertan
URL: https://blog.fps.hu/idomenedzsment-a-gyakorlatban-8-tipp-es-egy-kis-modszertan/
Last updated: 2026-07-17T08:22:52.000Z
Biztosan voltál már olyan helyzetben, hogy egyszerűen annyi mindennel kellett foglalkoznod, hogy azt sem tudtad mibe kezdj bele. Persze, nem lehet mindent egyszerre, így volt, ami nem lett meg időben és biztosan olyan is akadt, amire egyáltalán nem jutott időd.

Ezt pedig sem a magánélet sem a munka nem tolerálja. Szóval lépjünk egy kicsit hátrébb és nézzük meg az alapoktól, hogyan lehet egy kis tervezéssel elkerülni vagy megoldani a hasonló helyzeteket.

### Az idő pénz, de tényleg

„Bocs nem volt rá időm…” Ezerszer hallottuk és használtuk ezt a mondatod, de mit is jelent pontosan az, hogy nem volt időd valamire?

A te napod 24 órából áll, az enyém is és nem ismerek olyan embert, akinél ez másképpen működne.

Áhh, hogy neked több feladatod volt? Na ez már közelebb áll a valósághoz. Ha megnézzük, végülis minden embernek ugyanannyi ideje van, de nem ugyanannyi a teendőjük. Valami viszont még mindig nem az igazi. Azért mert több teendőd van, még el kellene tudnod végezni mindet, maximum többet dolgozol.

Jaa, hogy több feladatod van, mint ami belefér 24 órába. Ez így már teljesen érthető, de várj… Most hagyjuk, hogy miért volt több dolgod és válaszold meg, miért nem csináltad meg, amire kértelek?  
„Mert nem volt rá… khm… Mást csináltam helyette.”

Na erről van szó. Mindenkinek ugyanannyi ideje van, de mindenki másképpen használja fel.

![Az idő pénz](https://blog.fps.hu/content/images/2018/10/Az-id--p-nz.jpg)

Akár azt is mondhatjuk másképpen költjük el ugyanazt a 24 órát, mert ha végiggondolod az idő tényleg olyan mint a pénz. Minden hónapban kapunk valamennyi fizetést, amiből ki kell fizetnünk dolgokat.  
Ha jól matekozunk, akkor mindent ki tudunk fizetni és még marad is egy kicsi sörre, de ha nem figyelünk oda, könnyen túlköltekezhetünk és nem marad pénzünk minden szükséges dologra, nemhogy még sörre is.  
Ugyanez van az idővel is, ha nem tervezünk vele, nem hogy elmarad a pihenés, de a fontos dolgok is könnyen háttérbe szorulnak.

A gondolatot meglovagolva itt van egy kicsit elcsépelt, de teljesen helytálló motivációs Fatboy Slim:

### Priorizálás

Ahhoz, hogy tervezni tudjunk az időnkkel, fontos látni, hogy az egyes teendőknek eltérő prioritásuk van. Ez megint csak olyan mint egy havi fizetés. Először a kötelező dolgokat fizetjük (számlák, bérlet stb…), majd a fontosakat (étel, ruházat stb…), aztán kevésbé fontosakat és végül a nem létszükségleteket.

A probléma ott kezdődik, hogy ez a prioritás változik az adott teendők sűrgősségének függvényében. A könnyebb fogyasztás érdekében hadd magyarázzam el egy buta példával:

Nincs öltönyöd. Tudod, hogy egyszer szükséged lesz egyre és ezer éve rajta van a listádon, de nem igazán foglalkozol a vásárlással, mert nem sürgős. Aztán egy ismerősöd az utolsó pillanatban meghív az esküvőjére és hát most már kellene az az öltöny, szóval végre elindulsz vásárolni.  
Veszel is egy menőbb darabot, hisz van bőven pénz a tárcádban. Elmész az esküvőre, ráadásul viszel egy drága ajándékot is, mert van rá pénzed.  
Az esküvőnek vége, jön a következő hét, lassan lejárnak a számlák is, pár napod maradt befizetni mindent. Számolod a pénzed, de nincs elég, elment az öltönyre, az ajándékra, meg az italokra, amelyekre meghívtad azt a szőke lányt…  
Sürgősen fizetni kellene, de nincs miből. Kikapcsolják az áramot.

![Rossz tervezés, üres tárca](https://blog.fps.hu/content/images/2018/10/Rossz-tervez-s---res-t-rca.jpg)

De hol ment félre a dolog? Mind az öltöny vásárlás, mind a számla fizetés előre látható volt és egyértelmű, hogy a számlákat fontosabb befizetni.  
Csakhogy a sürgősebb dolgokat fontosabbnak érezzük és hamarabb megcsináljuk azokat. Ezért a valójában szükséges dolgok a háttérbe szorulnak. Ha pedig nem számolunk mindennel, ez könnyen bajba sodorhat minket.

Ahhoz pedig, hogy ésszerűen tudjunk priorizálni érdemes valamilyen módszertant használni.

### Időmátrix

Stephen R. Covey szerint priorizáláskor meg kell vizsgálni egy feladat sürgősségét és fontosságát. Ezek permutációjából pedig az jön ki, hogy egy teendő a következő 4 állapotban lehet:

1. Sürgős és fontos
2. Fontos, de nem sürgős
3. Sürgős, de nem fontos
4. Nem sürgős és nem fontos

![Covey időmátrix](https://blog.fps.hu/content/images/2018/10/Covey-id-m-trix.jpg)

A fenti táblázat 4 részét sorrendben a következőképpen kell kezelni:

#### 1\. Sürgős és fontos

Ez kvázi a tűzoltásnak felel meg. Az itt lévő dolgokat azonnal kezelni kell, mert nagy bajt okozhatnak.

Törekedni kell arra, hogy minél kevesebb pont kerüljön ide, aminek a lényege, hogy a fontos dolgok nem válhatnak sürgőssé és fordítva.

A fenti példában a fontos számla befizetését előre látjuk, így ha időben kezeljük nem lesz sürgős. A kevésbé fontos öltöny vásárlásának szüksége pedig szintén ismert, így ha nem halogatjuk a végtelenségig, nem válik sürgőssé.

#### 2\. Fontos, de nem sürgős

Optimális esetben minden olyan feladat ide kerül, ami valójában szükséges. Ide megy a számla befizetése.

A cél, hogy ebbe a negyedbe kerüljön a feladataid nagy része, hogy időben tervezni lehessen velük. A lényeg, hogy ezek tegyék ki egy napod vagy heted 80%-át.

#### 3\. Sürgős, de nem fontos

Ezek azok a dolgok, amiket nem nagyon lehet elhasztani.

Például egy találkozó vagy telefon valakivel, esetleg megbeszélések.

#### 4\. Nem fontos és nem sürgős

Ezekkel nem lesz gond, ha elmaradnak vagy elcsúsznak, de hosszabb távon hasznosak lehetnek.

Például ide lehet rakni a szakmai blogok vagy könyvek olvasását, telefon vagy számítógép frissítését, növények átültetését stb…

A cél, hogy ezeket sem felejtsük el és előbb-utóbb, mindent megcsináljunk.

### Heti és napi tervezés

Már tudjuk, hogyan kell priorizálni, de hogyan lesz elvégezve minden feladat?

Először is fogadd el, hogy **nem tudsz mindent megcsinálni**. Egyszerűen nem lehet berakni 32 órát 24 órába, ennyire egyszerű. Van amit másnap vagy következő héten kell megcsinálni.

A priorizálásnak pont az lényege, hogy azokkal foglalkozz először, amik legnagyobb hatással vannak az életedre vagy a munkádra, mert így leszel a leghatékonyabb úgy, hogy a halaszthatatlan dolgokat sem kell eltolnod. Így tudsz nyugodtan hazamenni munkából és nyugodtan aludni éjszaka, így tudod megtartani a másnak adott szavad.

![Checklist](https://blog.fps.hu/content/images/2018/10/Checklist.jpg)

Ha ez megvan, menj végig a következő lépéseken:

#### 1\. Teendő lista

A priorziálás legelső lépése, hogy listába szedsz minden feladatot (de tényleg mindent), amit valamikor majd meg kell csinálnod.

#### 2\. Becslés

Becsüld meg az összes teendő munkaidejét. Ezzel egyértelmű lesz, hogy mennyi időre van szükséged.

Hasznos, ha számolsz az általános dolgokkal is, mint az átlagos telefonálás, levelezés, megbeszélés stb… idő, mert ezek is elvesznek abból, amit fel tudsz használni.

#### 3\. Heti terv

Meg kell határozni, hogy mit kell vagy lehet az adott héten megcsinálni. Ezek összes ideje soha nem lehet több, mint a rendelkezésre álló idő, mert fizikálisan nem vagy képes többet csinálni.

Könnyen előfordulhat, hogy például 5 napra 7 napnyi munka jut. Ezzel nem lehet mit csinálni és össze kell szedni, hogy mi az ahol a legkevésbé okoz gondot a csúszás és át kell rakni a következő hétre.

#### 4\. Napi terv

Minden reggel szánj 15 percet a feladatok összeírására. Írd fel, hogy aznap mit kell megcsinálnod ahhoz, hogy az adott hétre tervezett dolgok teljesüljenek.

Amint megvannak a feladatok, rendezd azokat sorba a fenti mátrix negyedei alapján (1,2,3,4). Ha szükséges, az egyes negyedeken belül használhatsz egyszerű fontosság szerinti rendezést.

Itt is fontos, hogy az adott napnyi feladataid összideje nem lehet több annál, mint ami a rendelkezésedre áll.

#### 5\. Csináld végig

Ezen nincs mit magyarázni. Kezdd a legelső ponttal és húzd ki, ha végeztél. Aztán így tovább egyesével, amíg mindent ki nem húztál az adott napra.

### Tippek

Papíron ez egy egyszerű módszertan, de a gyakorlatban sok ponton el lehet csúszni. Ezért itt van néhány tipp, ami megkönnyíti az időd kezelését.

![Kerüljük a fejfájást](https://blog.fps.hu/content/images/2018/10/Ker-lj-k-a-fejf-j-st.jpg)

#### 1\. Védd az időd

Talán ez a legfontosabb. Nem leszel képes megcsinálni az adott heted vagy napod, ha engeded, hogy más beleszóljon a terveidbe. Ne félj nemet mondani, ha nem megoldható. Az még kínosabb ha elvállalsz valamit és nem tudod megcsinálni.

#### 2\. Tanulj becsülni

Ez biztosan nem fog elsőre menni, de minél többet csinálod, annál pontosabb leszel. Valamint, sokat segít, ha használsz valamilyen time tracking eszközt, ahol látod a korábbi feladataid szükséges idejét.

#### 3\. Ne tervezz 100%-kal

Egy dolog biztos, a váratlan. Egyszerűen nem láthatsz előre mindent és ha az összes rendelkezésre álló időd betervezed, a váratlan dolgok problémát fognak okozni.

Jó módszer, ha kb. 80%-ot tervezel. Ha nem jön semmi, akkor keresel egy új teendőt a következő napról vagy hétről, de ha esetleg megtalál egy váratlan telefon vagy probléma, marad egy kis plusz időd a megoldásra.

#### 4\. Nyeld le a békát

Ne halogass valamit csak azért, mert nincs kedved hozzá. Sőt próbáld minél hamarabb megcsinálni, hogy lehetőség szerint később (amikor fáradtabb vagy) már könnyebb feladatok maradjanak.

![Nyeld le a békát](https://blog.fps.hu/content/images/2018/10/Nyeld-le-a-b-k-t.jpg)

#### 5\. Maradj fókuszban

A jó időmenedzsment egyik fontos eszköze a hatékony időkihasználás, amihez fontos az adott feladatra fókuszálni.

Lehetőleg egyszerre csak egy feladaton dolgozz, ne kezdj másba, amíg teljesen le nem zártál valamit.

Ha lehet, akár kapcsold ki az üzenetekhez tartozó értesítéseket. Senki nem fog megsértődni, ha 2–3 óránként válaszolsz az üzenetekre, de nem fog 10 percenként kibillenteni egy-egy sms, chat vagy e-mail.

#### 6\. Tiszteld mások idejét

Te sem várhatod el, hogy tiszteljék a tervedet, ha te sem foglalkozol másokéval. Fogadd el, hogy nem mindenkinek az a sürgős vagy fontos, ami neked és próbálj másokat minél kevésbé zavarni.  
Ha kialakul ez a kultúra körülötted, sokkal könnyebb lesz hatékonyan dolgozni.

Ha szükséges (például munkában), használhatod a következő kommunikációs sorrendet:

- Általános kérdések feladatok:  
Email, sms, bármilyen feladatkezelő rendszer
- Viszonylag fontos (megakadtál valami sürgőssel):  
Chat, telefon
- Tűzoltás, azonnal meg kell oldani (leáll egy weboldal):  
Személyesen (vigyázz, mert megzavarod abban, amit csinál és nem tudod, az milyen fontos)

#### 7\. Kommunikáció

Mint minden helyzetben, a megfelelő kommunikáció nagyon sokat segít mind az időd tervezésében, mind a terved védelmében, illetve az eltérések kezelésében.

Ha látod, hogy valami nem készül el időben, szólj előre, így kevésbé lesz váratlan probléma (lehet vele tervezni). Például jelezd, ha valami már csak jövő hétre vagy utána fér be.

Amikor valaki új feladattal borítaná a terved, jelezd neki, hogy ha megcsinálod, akkor helyette mi nem fog teljesülni.  
Ha a felettesedről van szó, így neki kell döntenie, mi készüljön el, ha pedig munkatársad az, akkor a feletteseddel kell megbeszélnie. Így egyik esetben sem lesz több feladatod mint időd.

Igazából az a legjobb, ha publikus a terved és már a felesleges köröket is el lehet kerülni.

#### 8\. Ha minden SOS feladat, akkor semmi sem SOS feladat

Persze, könnyű mondani, hogy törekedjünk az első negyed üresen tartására, de tapasztalat szerint sajnos vannak húzós időszakok, amikor tényleg minden összejön.

![Tűzoltás](https://blog.fps.hu/content/images/2018/10/T-zolt-s.jpg)

Továbbra sem lehetséges egyszerre több feladatot megcsinálni, így az első negyeden belül is priorziálni kell. Meg kell nézni, mi az, ami a legfontosabb (esetleg a leghamarabb megoldható) és sorrendet kell felállítani. Így minden érintett félnek meg tudod mondani, kb. mit mikorra várhat. Nem mindig fog tetszeni a válasz, de jobb mint a „nem tudom” vagy a „sok dolgom van” és neked már csak egyesével végig kell menned a felsorolt pontokon.

#### 8+1\. Alakítsd szokássá

Egy jó lista és terv nagy szabadságot ad. Semmit sem kell fejben tartanod, minden fontos dologra sor fog kerülni és még azt is viszonylag jól meg tudod mondani, hogy mire mikor lehet számítani.

Ugyanakkor, ez akkor működik, ha folyamatosan használod. Ezért mindig

- Írd fel, ha bejön egy új feladat
- Becsüld meg a feladatok idejét
- Készíts hét elején heti tervet
- Készíts reggel napi tervet
- Frissítsd a tervet, ha szükséges

Ha ezeket kihagyod, nem lesz megbízható rendszer és elbúcsúzhatsz a nyugalomtól.

### Eszközök, szakirodalom

A leírtak, ha nem is 100%-ban, de nagy mértékben Stephen R. Covey könyvén, A kiemelkedően sikeres emberek 7 szokásának egyik fejezetén alapulnak.  
A könyv részletesen bemutatja az időmátrixot. Továbbá, jó leírást ad az egyes negyedek kezeléséről.

![Könyvajánlás](https://blog.fps.hu/content/images/2018/10/K-nyvaj-nl-s.jpg)

Szintén hasznos könyv az Intézz el mindent, amit David Allen írt. Ebben a gtd-ről (get things done) lehet olvasni, ami egy másik haszonló módszer a priorizáláshoz és könnyen összeegyeztethető Covey írásával.

A [Week Plan](https://weekplan.net/?ref=blog.fps.hu) nevű webalkalmazás pedig egy jó eszköz heti és napi tervek készítéséhez. Az eszköz az időmátrix módszertanára épül és ha feliratkozol, hetente kapsz tippeket a hatékonyságod növeléséhez. Ezek között vannak tényleg hasznosak is.  
Tartozik hozzá mobil alkalmazás is. A használata, alapjában ingyenes, de vannak prémium (fizetős) funkciók is.

A [Toggle](https://toggl.com/?ref=blog.fps.hu) egy népszerű és egyszerű time tracking rendszer, amivel könnyen optimalizálhatod az időbecslésedet.  
Van mobil alkalmazása is, illetve az alapverzió ingyenes.

### Összegzés

Napjainkban nem egyszerű mindent fejben tartani és megfelelő prioritással kezelni, ezért érdemes valamilyen módszertan szerint kezelni az idődet is.

A fent írtak, azt a módszert mutatják be nagyvonalakban, amit Covey könyve alapján a saját munkában használok és ami segít eligazodni a mindennapokban.

A cél, hogy ezeket az alapokat felhasználva te is olyan rendszert dolgozz ki, ami segít hatékonyan kezelni a teendőidet.

#### Előadás diái

Erről a témáról beszéltem az ITrend meetups-on:
### Brief me if you can
URL: https://blog.fps.hu/brief-me-if-you-can/
Last updated: 2026-07-17T08:23:01.000Z
Minden a digitális világban dolgozó, üzletfejlesztéssel és értékesítéssel foglalkozó ember életében vannak olyan kiemelt projektek, amelyekre jó szívvel gondol vissza. Szerencsére az [fps ecosystem](https://www.behance.net/fpshu?ref=blog.fps.hu) listája ezen a téren is elég hosszú. Hisszük, hogy egy sikeres együttműködés mindig egy sikeres pre-sales időszakkal kezdődik. De hogyan lesz egy megkeresésből eredményes és kiegyensúlyozott partneri viszony, és melyek a legfőbb kritériumai annak, hogy a nap végén mind az üzleti partner, a termék jövőbeni felhasználója, a közreműködő szakemberek és a sales-es is boldogan hajtsa álomra a fejét?

### Minden a brief-fel kezdődik.

Megkereséseiteket szívesen fogadjuk, és nagy izgalommal szoktuk megnyitni az e-mail csatolmányokban az összeállított kezdő koncepciót, vagy pályázati/ tenderkiírást. Bevalljuk, sok esetben ezután hosszas fejvakarás, adott esetben méltatlankodás következik.

### Melyek a leggyakoribb hibák, amelyekkel találkozunk?

- arrogáns stílus: nem is gondolnátok mennyiszer fordul elő, hogy már a szövegezés alapján érezhető, a leendő megrendelő nem partnerként fordul hozzánk. Ennek egyik ékes formája, amikor kihangsúlyozásra kerül, hogy nekünk bizony örömtáncot kellene járnunk már csak a megszólítás miatt is.
- irreális határidők: *„Kérem ajánlatukat 48 órán belül megküldeni.”* November 20-i keltezéssel: *„A website kötbérterhes élesítési határideje: december 31.”* Azt hiszem ez nem igényel további magyarázatot.
- a feladó nem hagy elérhetőséget: bizony, ez is gyakran előfordul, hogy egy telefonszám sincs, ahol a kapcsolatfelvétel meg tud történni. Ez alapján determinálható, hogy a partner csak kötelességből küldte ki 50 helyre az ajánlatkérést, és retteg attól, hogy kommunikációba bocsátkozzunk.
- kedvenc mondatunk tenderkiírásból: *„Az Ajánlattevő az ajánlattételi határidő lejárta után ajánlatát csak az Ajánlatkérő kérésére és az Ajánlatkérő számára kedvezőbb irányban módosíthatja.”* Magyarázzuk? Ha esetleg a tervezés során időközben kiderül plusz igényként, hogy egy kisebb csillagrombolót bele kell építeni a projektbe, nem változtathatunk az áron. Vagyis de, csak kizárólag lefelé! :)
- a mindent IS akaró ügyfél: részletes leírás, nagy célok, én akarok lenni az új Facebook, Booking, Amazon stb. Majd a telefonos előszűrés alatt kiderül, hogy úgy gondolja, „nettó négyszázból" kihozható, mert már kapott egy ilyen ajánlatot a szomszéd Pistitől.
- a szuperparanoiás: a brief megküldése előtt 30 oldalas titoktartási szerződés aláírásának kierőszakolása, a kötbér, károkozás és a hibás/hiányos teljesítés szavak kötőszóként való használata minden beszélgetés során, más cégekkel korábbi, befuccsolt együttműködések felemlegetése, grátiszban kihangsúlyozva, hogy övé a város legjobb ügyvédje. Bizalomépítés level 2000!
- a „tételes mániás”: egy 3-6 hónapos projekt esetén ajánlatunkban tételesen tüntessük fel a felhasználandó erőforrások mennyiségét munkaórában kifejezve. Tételesen mutassuk be az összes projekten dolgozó kollégát, tételesen vegyünk számba minden feladattípust, tételesen adjuk meg a (jövőbeni elképzelt) rendszer alatt futó szerver paramétereit, és tételesen adjuk meg a cégtulajdonosok ükapjainak születési adatait …

Hosszú a sor, nem is folytatom. Bár most biztos azt gondoljátok, hogy túloztam, de nem. A fenti esetek 99%-a nálunk elvérzik az ügyfél scoringon… De innentől kezdve fókuszáljunk arra, hogy milyen is a jól induló együttműködés!

### Nyitottság, bizalom, kémia

Van ma Magyarországon nagyjából 30 olyan digitális terméktervező és fejlesztő cég, amelyik a legmagasabb szakmai színvonalon képes digitális termékek megvalósítására és piacra lépésük segítésére. Tehát csupán szakmai és ár alapon ötletgazdaként elég széles merítési lehetőség mutatkozik a partner kiválasztásakor.

A legfontosabb kérdés talán a szakmai kompetenciákon és a versenyképes árazáson túl, hogy sikerül-e egymásra hangolódni, kialakul-e a közös megértés, tudunk-e egy nyelvet beszélni. És ez bizony az ajánlatatási szakaszban alapozódik meg.

Közös nyelv alatt nem azt értjük, hogy kapásból tudnod kell mi az a UX design, a termékvalidáció, prototípus készítés, vagy, hogy mi a különbség front-end és back-end fejlesztés között. (Persze örülünk, ha megrendelőként van már korábbi tapasztalatod website-ok, vagy alkalmazások fejlesztésében, mert akkor túl vagy már jó pár kihíváson, esetleg kudarcon, jó és rossz élményeken egyaránt.) Programnyelveket sem kell ismerned feltétlenül, hisz az a mi feladatunk, hogy üzleti céljaidat technikai követelményekké és megoldásokká transzformáljuk.

Tehát mindegy, hogy otthonosan mozogsz-e a digitális világban, vagy sem, a saját szakterületedet úgyis te ismered a legjobban, és ez a siker egyik kulcsa. Mi pedig ígérjük, hogy nyitottan, érdeklődve állunk a kihívások elé, tiszteletben tartjuk a tudásodat, tapasztalatodat, és segítünk a legmegfelelőbb utat választani, hogy a jövőbeni felhasználóid számára élmény legyen a végeredmény használata, és üzleti sikereket érsz el vele!

### Mi az, amit hozz nekünk?

- A problémát, amire megoldást keresel. Ez lehet termékkel kapcsolatos probléma, a felhasználóid problémája, illetve bármilyen elakadás a digitális üzleti stratégiádban, digitális transzformációdban, vagy ha gyorsan kell reagálnod megváltozott piaci, környezeti, technológiai változásokra.
- Legyen víziód! A mi dolgunk, hogy eljuttassuk a verzióig. Ha nincs, abban is tudunk segíteni, hogy megalkossuk veled közösen!
- Elképzelést a termékről/ megoldásról! (Elsőre nem azt kérjük, hogy pontosan fogalmazd meg hány db menüpontot szeretnél, vagy azt, hogy egy adott szöveg hány bekezdésből álljon! Ne a mezőszintű definíciókkal legyél elfoglalva, hanem a bigpicture-től haladj befelé az átgondolás során)
- Legyenek céljaid, amelyben megfogalmazod, melyek a siker legfőbb kritériumai.
- Elképzelt, reális (vagy annak tűnő) timingot a termék piacra lépéséig. Adj időt magadnak, és nekünk is. Hogy ez mit jelent pontosan? Korábban írtunk arról, hogy [milyen feladatokra számíthatsz](https://blog.fps.hu/5-1-feladat-ha-webes-projektbe-kezdesz/), és mennyi időt fog elvenni tőled ha fejlesztési projektbe kezdesz.
- Tervet, ötletet, hogyan fogod megismertetni a terméked a felhasználóiddal!
- Legyen büdzséd! Igen, sokan félnek elmondani, azonban rengeteg kellemetlen szituációt, és felesleges munkaórákat tudnánk elkerülni, ha ez a kezdetektől transzparens lenne. A büdzsé megosztása nem azt jelenti, hogy az információt kihasználva indokolatlanul kimaxoljuk a keretet. Épp ellenkezőleg, megpróbáljuk a legtöbbet kihozni belőle, és őszintén elmondjuk azt is, ha nem látjuk reálisnak a megvalósítást. Ez sem jelenti rögtön azt, hogy nem egymást keressük, hiszen egy jó MVP szemlélettel kisebb költségkeretből is lehet látható értéket szállítani. Számunkra fontos a transzparencia és a bizalom, az első pillanattól fogva.
- Legyél döntéshozó! Ha nem vagy az, biztosítsd, hogy a projekt előkészítési szakaszban mindig rendelkezésre tudjon állni döntéshozó!

### És most nézzük meg, hogy ezek után ideális esetben hogyan indul a közös munkánk!

**Összeállítunk neked egy ütős, seniorokból álló tanácsadó csapatot.**

Intenzív közös workshopokat tartunk, amelyen:

- Megtudunk mindent rólatok, az üzleti problémátokról
- Feltárjuk a piaci környezetet, ahova a termék készül
- Felhasználói kutatást végzünk, personákat állítunk. Igény szerint - illetve ha a digitális termék jellege úgy kívánja - lehetséges felhasználókat toborzunk, velük mélyinterjúkat készítünk, vagy kérdőíves megkérdezést végzünk
- A fentiek alapján funkciókat határozunk meg és értékelemzést követően priorizáljuk őket
- Felhasználói útvonalakat (User journey) rakunk ki
- Prototipizálunk, validálunk
- Definiáljuk az MVP (Minimum Viable Product avagy a Minimum Életképes Termék) scope-ját
- Technológiai felmérést végzünk és megvalósítási scenariokat rakunk össze

Mindeközben rendkívül sokat kérdezünk, rajzolunk, post-iteket ragasztgatunk ([itt olvashatsz róla miért fontos a vizualitás](https://blog.fps.hu/vizualitas/)), újra kérdezünk, információkat szintetizálunk.  
A követelményelemzés során eszköztárak és módszertanok széles repertoárjaiból merítünk, használunk például Inception Deck, [Lean Canvas](https://blog.fps.hu/lean-canvas-tervezes-az-fps-ben/) és Service Design elemeket.

![brief_barbi_02](https://blog.fps.hu/content/images/2018/10/brief_barbi_02.png)

A fenti folyamat eredményeképp kialakul a scope, és nem mellesleg egy mély közös megértés, amely minden további munka és a partnerek közötti szükségszerű [digitális szimbiózis](https://blog.fps.hu/digitalis-projektek-partnerseg-szimbiozis/) alapja. Ezután a projekt teljes megvalósítására biztonságosan tudunk költségkalkulációt és roadmap-et adni, pontosan tudunk erőforrást és szükséges kompetenciákat tervezni. A kezedben az összeálló dokumentációnak köszönhetően pedig egy validált ÉRTÉKCSOMAG lesz.

**Kipróbálnád? Várjuk a briefedet! :)**
### YAGNI, KISS, DRY…
URL: https://blog.fps.hu/yagni-kiss-dry/
Last updated: 2026-07-17T08:23:11.000Z
Nem, nem Yagni száraz csókjáról lesz szó, sokkal inkább az informatikában elterjedt szabályok betűkombinációiról. Az [extrém programozás](https://wiki.prog.hu/wiki/Extr%C3%A9m%5Fprogramoz%C3%A1s?ref=blog.fps.hu) összegyűjt olyan [alapelveket](http://www.extremeprogramming.org/rules.html?ref=blog.fps.hu), amik a fejlesztést *extrém* hatékonyá teszik. A három leggyakrabban emlegetett szabályt szeretném újra sorra venni én is. Számos [cikk](https://www.becube.hu/single-post/2018/02/06/Extr%C3%A9m-programoz%C3%A1s---KISS-YAGNI?ref=blog.fps.hu) született már a témában, de úgy gondolom, nem lehet elégszer ismételni őket.

### KISS – Keep It Simple, Stupid

Több megfelelője is létezik ennek a mozaikszónak, mivel nem mindenhol használták szívesen a stupid szót. Így lehet a *„Keep it simple, silly”*, *„keep it short and simple”* vagy akár a *„keep it simple and straightforward”* kifejezés rövidítése is.  
Egy mondatban összefoglalva: „A legtöbb rendszer akkor működik a legjobban, ha egyszerű, ahelyett, hogy bonyolult lenne”.  
Az egyszerűség nem kevesebb kódsort vagy rövidebb változóneveket takar, sokkal inkább átlátható és könnyen értelmezhető tiszta kódot, a [SOLID elveknek](https://www.refaktor.hu/tiszta-kod-5-resz-a-s-o-l-i-d-alapelvek/?ref=blog.fps.hu) való megfelelést.

### YAGNI - You Ain’t Gonna Need It

Biztosan veled is előfordult már, hogy egy adott problémát megoldó scriptet, osztályt, metódust kibővítettél annak szellemében, hogy „ha netán erre szükség lenne a jövőben”, vagy „felkészítem *arra* is”. Lássuk be, az esetek többségében [nem lesz rá szükség](http://www.extremeprogramming.org/rules/early.html?ref=blog.fps.hu), és nem kell, hogy mást is tudjon, azon kívül, mint ami az akkori létrejöttének célja. Az univerzalitás helyett a kulcsszó a bővíthetőség és átláthatóság legyen, így ha a későbbiekben extra igények merülnének fel, félelem és/vagy káromkodás nélkül nyúl a munkánkhoz a kolléga, hogy a saját céljaira is felhasználja azt.

### DRY – Don’t Repeat Yourself

Régi kódban rendszeresen előfordul *kopipészthuszárok* hagyatékaként, amikor egy függvényből kettő van, minimális eltéréssel és joggal akad ki a [CDP](https://github.com/sebastianbergmann/phpcpd?ref=blog.fps.hu). Ez fenntarthatóság szempontjából jelentősen csökkenti a projekt esélyeit, meg amúgyis, nem szép megoldás duplikálni a kódot megfelelő paraméterezhetőség és OOP szemlélet alkalmazása helyett.  
Lényege, hogy a kód, illetve a mozdulatok minden megduplázása az inkonzisztenciához vezető úton visz tovább ([forrás](http://www.clean-code-developer.hu/category/red/elvek/?ref=blog.fps.hu)).  
A **DRY** szabály ellentéte nem is lehetne más, mint a *WET*, azaz *„write everything twice”*, *„we enjoy typing”* vagy *„waste everyone’s time”*.

#### Ha érdekel a téma...

- [Extreme Programming: A gentle introduction](http://www.extremeprogramming.org/?ref=blog.fps.hu)
- [Design principles: kiss, dry, tda, soc, yagni](https://medium.com/@derodu/design-patterns-kiss-dry-tda-yagni-soc-828c112b89ee?ref=blog.fps.hu)
- [Clean Code Developer](http://www.clean-code-developer.hu/?ref=blog.fps.hu) (magyar)
- [Letscode.hu podcast – Elefántcsonttorony](https://soundcloud.com/letscodehu/elefantcsonttorony?ref=blog.fps.hu) (podcast)
### Phaser kedvcsináló
URL: https://blog.fps.hu/phaser-kedvcsinalo/
Last updated: 2026-07-17T08:23:21.000Z
A napi szintű internetmágiába hosszú távon kissé bele lehet fásulni, ilyenkor szoktam a nosztalgiamániámat kihasználva HTML5 játékfejlesztésről olvasgatni vagy próbálkozni vele, hátha valami feleleveníti azt a kellemes hangulatot, amit annak idején egy Super Mario, vagy egy Donkey Kong végigjátszása okozott. A 2 dimenziós platformer kutatásom vezetett el a Phaser-hez, ami gyakorlatilag a szekrényen porosodó nintendot a böngészőre cseréli. Február környékén megesett egy 3.0-ás release, szóval még ráfogható, hogy aktuális vele a demózás.

### WTF is Phaser?

Egy WebGL és Canvas renderelést támogató, 2D-s, HTML5 játékfejlesztéshez használatos JavaScript alapú keretrendszer. Ez tömören annyit jelent, hogy nem kell a fizikával, hitboxokkal, ütközésekkel foglalkoznod, a böngészős játékodhoz csak egy ötlet és egy működési elv kell, a nehezét ez majd megoldja helyetted. Ennek alátámasztására összedobtam egy kis „játékot”, aminek összesen annyi célja lenne, hogy a Phaser felépítése mellett szemléltesse kb. mennyi effortot is igényel egy ilyen alapszintű dolog.

See the Pen [Infinite hopper](https://codepen.io/feoMango/pen/EdxdrV/?ref=blog.fps.hu) by feo ([@feoMango](https://codepen.io/feoMango?ref=blog.fps.hu)) on [CodePen](https://codepen.io/?ref=blog.fps.hu).

Az elv borzasztóan egyszerű: a kis nyúlszerű képződményt egy megállás nélkül lefelé mozgó platformszéria egyikére dobjuk, majd elvárjuk tőle, hogy a blokkok résein keresztül felugrálva elkerülje a képernyő legalját. Ha ez nem sikerül, a játék újraindul.

### Játékmenet gyakorlatban

Először is össze kell rakni a projektet [a phaser oldalán](https://phaser.io/phaser3/gettingstarted?ref=blog.fps.hu), vagy [githubján](https://github.com/photonstorm/phaser?ref=blog.fps.hu) felvázolt módszerek egyikével. Amint ez megvan, inicializálhatjuk a Phasert, hogy ellenőrizni tudjuk minden megfelelően működik-e, valahogy így:

```javascript
let config = {
    type: Phaser.AUTO,
    width: window.innerWidth,
    height: window.innerHeight,
    physics: {
        default: 'arcade',
        arcade: {
            gravity: {
                y: 1200
            },
            debug: false
        }
    },
    scene: [
        gameLoader,
        gameLauncher
    ],
    input: {
        activePointers: 2
    },
    backgroundColor: '#c34'
};

let game = new Phaser.Game(config);

```

Az elképzelésben ugyan még semmi extra nincsen, de a config paraméter rendelkezik néhány olyan értékkel, amik nem mondanak túl sokat, szóval fussunk rajta végig gyorsan:

- **type**: a Phaser renderelési módszere, amit ha automatikusra állítunk, ahol lehet WebGL-t használ, ahol nem támogatott, Canvas-ra fallback-kel.
- **physics**: a játékban használt fizika típusa, ezek közül az arcade a legkisebb és legegyszerűbb (az alternatívák egyébként az „impact” és a „matter”). Beállítunk egy globális gravitációt, illetve ki/be kapcsolhatjuk a debug funkciót (ami egyébként hitboxoktól kezdve a mozgó objektumok pályájáig minden apróságot megjelenít szóval fölöttébb hasznos tud lenni).
- **scene**: beállítunk 2 scene-t a játékhoz, az első az assetek betöltésére szolgál, a második a játék elindításáért és működéséért felel
- **input**: alaphangon minden játék 1 pointerrel indul, ez az egérkurzort vagy a tappolást reprezentálja, a minimális mobil használhatóság végett felvettem egy extra pointert, hogy a karakter draggelése mellett egyidőben tappolhassunk is

Ezek mindegyikéről borzasztó sokat lehet olvasgatni különféle Phaser-es dokumentációkban, így innen csak egy dolgot emelek ki:

#### Scene

Mint ahogy az elnevezésből is rá lehet jönni, ezeket legegyszerűbben egy felvonásként vagy jelenetként lehet elképzelni pl. így:

1. Betöltjük az asseteket
2. Menüpontokat jelenítünk meg
3. Elindítjuk a játékot és megvalósítjuk a funkcionalitást

Innentől a játékunk kellemesen elkülöníthető blokkokból áll össze, amik között fölöttébb egyszerűen váltogathatunk:

```javascript
scene.start('startGame');

```

Ezzel elkerülhetjük azt, hogy a rendszer újraindítása oldalfrissítést, assetek újrafeldolgozását vagy bármi hasonlóan tré dolgot igényeljen.

Szóval nézzük a kódot relatíve röviden csak a Phaser-specifikus részekre koncentrálva, az egyszerű JavaScript logikát max. futólag érintem.

#### Assetek betöltése

```javascript
class gameLoader extends Phaser.Scene {
    constructor() {
        super('initializeGame');
    }

    preload() {
        this.load.image(
            'clouds',
            'sky.png'
        );
      
        this.load.image(
            'ground',
            'ground.png'
        );

        this.load.spritesheet(
            'player',
            'playersprite.png',
            {
                frameWidth: 47.5,
                frameHeight: 75
            }
        );
    }

    create() {
        this.anims.create({
            key: 'left',
            frames: this.anims.generateFrameNumbers(
                'player',
                {
                    start: 0,
                    end: 1
                }
            ),
            frameRate: 10,
            repeat: -1
        });

        this.scene.launch('startGame');
    }
}

```

A *preload()* metódusban létrehozzuk statikus képeinket, a spritesheeteket és minden egyebet, majd ellátjuk őket egy kulccsal, amivel hivatkozhatunk rájuk. Ha ezek betöltődtek, a *create()*\-ben összerakjuk az animációinkat, amik közül a karakter balra tartó mozgását emeltem ki: a „player”-ként generált spritesheetet 47.5\*75-ös frame-ekre bontjuk, majd a „left”-ként definiált animáció meghívására 10 frame/sec sebességgel, ismétlődve meghívjuk ennek 0\. és 1\. elemét.

#### A játék indítása

```javascript
class gameLauncher extends Phaser.Scene {
    constructor() {
        super('startGame');
    }

    create() {
        this.initBaseElements();
        this.initTimedEvents();

        this.initTileParameters();

        this.spawnInitialTiles();
    }

    update() {
        if (this.cursors.left.isDown) {
            this.moveLeft();

        } else if(this.cursors.right.isDown) {
            this.moveRight();

        } else {
            this.stayIdle();
        }

        if (this.cursors.up.isDown) {
            this.jump();
        }

        if(this.player.body.onFloor()) {
            this.gameOver();
        }
    }
}

```

Egyelőre maradjunk a Phaser meglévő metódusainál, a sajátokat az átláthatóság kedvéért kiszedtem. Itt már elhagyhatjuk a preload lépést, mivel minden fontosabb dolgot előre betöltöttünk az előző jelenetben. A *create()*\-ünk létrehozza a definiált assetekészletünkből a játékhoz szükséges objektumokat, elindítja az időzített eseményeket illetve létrehozza a kezdéshez elengedhetetlen, egyszer használatos platformjainkat.  
Az akció minden egyéb része az *update()* lépésben történik. Ez az, ami a játék minden egyes belső tickje alatt lefut, szóval minden valós idejű interakciót itt kezelünk:

- Az arrow gombok használatára a karakter jobbra-balra mozoghat, ugorhat vagy ácsoroghat magának (az animáció miatt szükséges)
- Ha a nyúl a meghatározott játékterület aljához ér, a játék véget ér (esetünkben újrakezdődik)

[Olvass bővebben a Phaser belső lépéseiről, „tickjeiről”](https://phaser.io/phaser3/contributing/part7?ref=blog.fps.hu)

#### A mozgatás megvalósítása

```javascript
moveLeft() {
    this.player.setVelocityX(-500);
    this.player.anims.play('left', true);
}

```

A játékos objektumának egyszerűen beállítunk egy sebességet az x tengelyen, majd elindítjuk a korábban „left” kulccsal létrehozott animációt.  
Ugyan ezen az elven működik az ugrásunk is, annyi különbséggel, hogy az y tengelyen állítunk sebességet az objektumnak:

```javascript
this.player.setVelocityY(-750);

```

Még a földetéréssel sem kell foglalkoznunk, ugyanis ezt a korábban beállított gravitáció elintézi helyettünk.

#### A játékfolyamat

Most, hogy a jeleneteket letudtuk, megpróbálom kiemelni a játékfolyamat fontosabb részeit:  
Az *initBaseElements()* metódusban definiáltuk paramétereink alapértelmezett értékét, beállítottuk a kurzort és pointer objektumainkat, illetve csináltunk egy hátteret a játékhoz.  
Közvetlen utána létrehoztuk az időzített illetve a játék lépéseitől független, fix időközönként ismétlődő eseményeinket:

```javascript
initTimedEvents() {
    this.timedEvent = this.time.addEvent({
        delay: 2500,
        callback: this.addTile,
        callbackScope: this,
        loop: true
    });

    this.time.delayedCall(
        2500,
        this.startGame,
        [],
        this
    );
}

```

Első eseményünk 2,5 másodpercenként ismétlődik, ez hivatott a fentről érkező platformokat legenerálni.  
Közvetlen ezután beállítunk egy időzített hívást ami valami ilyesmit jelent: 2,5 másodperccel a felvonás kezdése után, indítsd el a játékfolyamatot.

Furcsán kinéző nyulunknak azonban szüksége van még némi támaszra, kéne neki egy alap, amin meg tud állni. Először is meghatározzuk a karakter és a platformot kezelő csoport ütközésének kezelését:

```javascript
this.physics.add.collider(this.player, this.tiles);

```

majd a *spawnInitialTiles()* metódus segítségével létrehozzuk a statikus platformokat. Ezek minden egyes eleme ugyanazzal a módszerrel jön létre: fogjuk az 50x50-es képünket, kiszámítjuk hányszor fér ki a képernyőn, hagyunk benne némi helyet, amin a karakterünk átfér, majd legeneráljuk a négyzeteinket:

```javascript
spawnTileSprite(index, alignY)
{
    let tile = this.tiles.create(
        (index * this.tileWidth), alignY,
        'ground'
    );

    if(index % 2 == 0) {
        tile.setFlipX(true);
    }
  
    tile.body.setAllowGravity(false);
    tile.setImmovable(true);
    tile.setVelocityY(this.tileVelocity);
}

```

- a tiles nevű csoportunk tagjaként létrehozzuk a sprite-ot a „ground” kulccsal ellátott képből
- minden másodikat vízszintesen tükrözzük, hogy megtartsa a hullám mintát
- kikapcsoljuk a rá ható gravitációt, hogy a lefelé irányuló sebességét ne befolyásolja
- „mozdíthatatlanná” tesszük, hogy ha a karakterünk nekimegy, ne tolja el őket
- elindítjuk negatív Y irányba egy előredefiniált sebességgel

Ezzel nagyjából véget is ér a játékfolyamat, remélem érezhető, hogy a munka nehezét a Phaser végzi, nekem csak az alap ötletemet kell köré építenem.  
Nyilván rászorulna némi optimalizálásra, de ettől eltekintve kb. 280 sorból a funkcionalitását bőven ellátó játékot össze lehet tolni, szóval **hajrá, set your phasers to stun**.

[**Játssz a karácsonyi játékunkkal, ami szintén Phaserben készült!**](https://hotride.fps.hu/?ref=blog.fps.hu)

### Források

- [Phaser 3 dokumentáció](https://photonstorm.github.io/phaser3-docs/?ref=blog.fps.hu)
- [Példák](https://labs.phaser.io/?ref=blog.fps.hu)
- [Touch + Drag events](https://rexrainbow.github.io/phaser3-rex-notes/docs/site/touchevents/?ref=blog.fps.hu)
- [Kiindulási alapok](https://phaser.io/tutorials/making-your-first-phaser-3-game?ref=blog.fps.hu)
- [Felhasznált texture pack](https://kenney.nl/assets/jumper-pack?ref=blog.fps.hu)
### Emberi hibázás felderítése
URL: https://blog.fps.hu/emberi-hibazas-elemzese/
Last updated: 2026-07-17T08:23:32.000Z
Digitális és fizikai termékek tervezésével egy olyan eszközt szertnénk adni a felhasználók kezébe, amivel egy adott folyamatban segítjük az aktuális célja elérésében. A termékek minőségét az határozza meg, hogy milyen mértékben tudjuk segíteni az adott cél elérését. Egyes esetekben ez mérhető a folyamat során elkövetett hibák kiértékelésével.

Hibák mindenhol jelen voltak, vannak és lesznek. Teljes mértékben nem zárhatóak ki, viszont tudatossággal, hibaelemzéssel csökkenthető számuk és mértékük.

A hibák nemkívánatos akciók vagy tétlenségek, melyek időzítés, tudás, interfészek vagy eljárások elvárt szabványoktól vagy normáktól való eltérésének következtében hátrányos kimenetelűek felszerelés, rendszer és/vagy egyén tekintetében.

A leggyakrabban feltett kérdések:

- Milyen hibák léphetnek fel?
- Milyen gyakran?
- Mik a következmények?

A kérdések gyors áttekintést adhatnak, ha a termék-környezet-ember kontextusában a lehető legtöbb esetben megválaszoljuk őket. Ez végezhető egy folyamatot végigkövetve vagy egy termék funkcióin végighaladva.

Az alábbiakban bemutatok néhány modellt, ami alapján könnyebben megfogalmazható a hibák típusa és eredete.

### Emberi kockázatelemzés

Az emberi kockázatelemzés lényege véleményem szerint, hogy az egyénen túl a környezeti és folyamatbeli tényezőkre is egyenlő figyelmet fordít.

Három fő szakasza:

1. **Hibák felismerése:** kontextus, folyamatelemzés, személyes tényezők feltárása
2. **Modellalkotás:** esemény fa, hibafa rajzolása az átláthatósághoz
3. **Mérhetőség biztosítása számszerű adatokkal:** tesztek, adatbázisok építése

Típusát tekintve lehet:

- **Retrospektív:** a korábban bekövetkezett hibák kiértékelése. Leginkább a tesztelési szakaszban észlelt hibák fixelése, legyen az design, funkció vagy koncepcionális hiba.
- **Prospektív:** a jövőbeli hibák előbecslése. Leginkább egy vegyes szakterületű csapat brainstorming során összegyűjti a lehető legtöbb hibaokot.

Hibabecslés során vegyük figyelembe, hogy az aktív, közvetelenül észlelhető hibákon túl látens hibák is jelen vannak, melyek a jővőben egy váratlan aktív hibaként jelentkeznek. A lehető legtöbb esetben látens hibák vannak jelen, csak még nem érkezett vagy figyelmen kívül esett az információ a jelenlétükről.

![HRA-1B-1](https://blog.fps.hu/content/images/2018/07/HRA-1B-1.png)  
*Amikor egy látens hiba a felszínre kerül*

A tervezés során főként látens hibákkal állunk szemben, ugyanis csak egy későbbi tesztelési vagy használati szakaszban derül ki, hogy az általunk tervezett funkció vagy módosítás eléri a kívánt célokat, vagy sem. Az iterálás emiatt elengedhetetlen.

![HRA-Swiss-cheese-modell-B-2](https://blog.fps.hu/content/images/2018/07/HRA-Swiss-cheese-modell-B-2.png)  
*A helyzetet Reason „Svájci sajt” modellje szemlélteti*

A modell jól illusztrálja azt is, hogy hiba esetén az egyén hibáztatása helyett inkább a teljes képet érdemes figyelni. Az egyén csak egy szelete azoknak a tényezőknek, melyek kivédhetnek vagy tovább engedhetnek egy hibát.

A szabályrendszerek és módszerek kiválasztásakor és követésekor, a felhasználói és piaci igények felmérésekor, a vízió és a koncepció kitalálásakor, a koncepció validálásakor, a tervezési és tesztelési szakaszban még mindig jelen vannak olyan hibák, melyek csak éles használatban kerülnek elő.

### Emberi hibázás

Az emberi hibázás mindenhol jelen van. Sok esetben fel sem ismerjük, mert a szervezetünk alkalmazkodott a kizárásukhoz.

> A Cbmaidrge Egeytem ktáatusa srzinet az olavsott sövezg mégertéshéez nem sízámt a bűtek srornjdee egy szavon bleül. Edelegnő ha az eslő és az ulotsó bteű a mefeglelő heylen van. A többi leeht tlsejeen véelteln szeűr heeyln, aokkr is könynedén el tuodd oslanvi. Ez azért van mret az agynuk az egyeüdli bteűk heeltyt a tleejs svazakat ovlassa.

A Cambridge Egyetem [kutatása szerint](http://www.mrc-cbu.cam.ac.uk/people/matt.davis/Cmabrigde//?ref=blog.fps.hu) az agyunknak elegendő a szavak első és utolsó betűje az olvasáshoz, a többi véletlen sorrenben is jelen lehet, ugyanis az agyunk az egyedüli karakterek helyett a teljes szavakra koncentrál.

### Személyes alakító tényezők

Az emberek komplex dinamikus rendszerek, akik észlelnek, értelmeznek, értékelnek és tevékenységeket hajtanak végre. Mindegyik szakasz lehetőséget ad a hibázásra.

Az adott szakaszokban nagyban befolyásolják a hibák mennyiségét és kimenetelét a külső és belső személyes alakító tényezők.

Külső tényezők:

- pszichológiai kontextus (pl.: stressz görbe)
- ergonómia (pl.: eszközök segítsége, hátráltatása)
- környezet (pl.: zajhatás)
- normák és szabályzatok (pl.: kötelező procedúrák, megkötések)

Belső tényezők:

- fiziológia (pl.: napi 24 órás ébrenlét-alvás szakasz)
- hangulat az adott pillanatban
- tudásbázis, az adott feladatban szerzett ismeretek mértéke
- következmények
- elvárások
- attitűd
- figyelmi erőforrások

**A személyes alakító tényezők javíthatók** a megfelelő eszközök használatával, tréning és gyakorlat szerzésével, folyamatszervezéssel, időbeosztás javításával, munkaterhelés optimalizálásával, ideális környezet kialakításával, csapatmunkával és kommunikációval.

### Elemzés viselkedési síkon

Jó betekintést ad a hibák definiálására Rasmussen modellje, ami viselkedések síkján csoportosítja a hibákat. A viselkedéseket három fő csoportban: **rutin, szabály** és **tudás szinten** különbözteti meg.

![HRA-Rasmussen-modell-6](https://blog.fps.hu/content/images/2018/07/HRA-Rasmussen-modell-6.png)  
*Rasmussen emberi hibázás modellje*

**Rutin szinten** a feladatok végrehajtása automatikusan, nagyobb tudatosság nélkül történik. A személy végre szeretne hajtani egy folyamatot, de az a tervezettől eltérően végződik. Itt a hibák történhetnek figyelmetlenségből (elvétés) vagy memória kihagyások (mulasztások) miatt.

**Elvétés** lehet időzítési hiba (pl.: rossz ütemben akar elkapni egy labdát és kiesik a kezéből), észlelési zavar (pl.: fénytörés miatt rosszul állapítjuk meg egy távoli tárgy színét), sorrend hiba, interferencia vagy pozícionálási hiba (pl.: mobil billentyűzetén hüvelykujjal N helyett space-t vagy M-et tappol).

**Mulasztás** oka lehet kihagyás (pl.: bezárja a bejárati ajtót és az utcáról visszafordul, hogy biztosan bezárta-e), ismétlés (pl.: internetes vásárlás során újból kosárba tesz egy terméket, pedig csak egyszer akarta), vagy csökkent szándék.

**Tudatos szinten** végzett feladatok esetén jelen vannak szabályok követéséhez köthető és tudás alapú hibák.

**Szabály alapú hiba** lehet egy rossz szabály pontos követése (pl.: egy elavult, javításra szoruló szabályzatot követünk), vagy egy jó szabály követése rosszul. A szabályok tudatos elhagyása is megtörténhet. Ez lehet vandalizmus, szabotázs vagy éppen kockázatvállalás.

**Tudás alapú hiba** történhet elfogultság, szelektivitás vagy az egyén számára ismeretlen terület miatt. Egy asztronauta számára minden edzés és felkészülés ellenére a világűr egy olyan új terep, ami folyamatos, tudatos figyelmet igényel a lehető legkevesebb hibával járó feladatmegoldáshoz. Jelenleg hasonló terep az emberek számára az AR és VR világa is.

### Felderítés

Ha egy vélt hiba miatt probléma adódik, egy hatékony módszere a hibák forrásának felderítésére a Toyota által kidolgozott és alkalmazott 5M vagy más néven [5 miért-módszer](https://en.wikipedia.org/wiki/5%5FWhys?ref=blog.fps.hu). Lényege, hogy a problémás szituációból kiindulva felteszi, hogy: „Miért történt ez így?”. A kérdésre kapott válasz alapján újra felteszi a kérdést. Ez addig megy egymás után, míg fény nem derül a hiba kiváltó okára.

Tegyük fel, hogy egy általunk tervezett webhopban folyamatosan visszaküldik a terméket rossz méretre hivatkozva.

- Miért alakulhatott ki a probléma? Nem voltak tisztában a pontos méretekkel.
- Miért nem voltak tisztában a pontos méretekkel? Nem találták meg a mérettáblázatot.
- Miért nem találták meg a mérettáblázatot? Nem elég szembetűnő a link.
- Miért nem elég szembetűnő a link? Nem elég kontrasztos.
- Miért nem elég kontrasztos? A háttér és a szöveg színének kontrasztaránya 1,3:1, a [WCAG által ajánlott minimum](http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html/?ref=blog.fps.hu) pedig: 3:1.

Az ötödik kérdés megválaszolása után már a javaslat is konkrétan megfogalmazható. A módszer komplexebb problémák esetén a legcélszerűbb.

### Összefoglalva

Hibák mindenhol jelen vannak és lesznek, de megértve a kiváltó tényezőket, a teljes képre összpontosítva észlelhetővé és orvosolhatóvá válnak. A megértést segíti a hibák felfedezése, modellezése és számszerűsítése. A felfedezés lehet retrospektív vagy prospektív jellegű. Számos probléma elkerülhető, ha az aktívon kívül a látens hibákra is fordul figyelem. A hibák jellege viselkedés tekintetében rutin, szabály és tudás szempontja szerint csoportosíthatóak. A hibák feltárásához egy gyors és hatékony módszer az 5M. A hibák feltárásával és kiértékelésével javítható a termék és szolgáltatás minősége, ezzel közelebb hozva a felhasználókat céljaik eléréséhez.
### Ne bántsd a felhasználót!
URL: https://blog.fps.hu/ne-bantsd-a-felhasznalot/
Last updated: 2026-07-17T08:23:43.000Z
Nemrég az [ITrend meetupon](https://www.meetup.com/ITrend/?ref=blog.fps.hu) tartottam egy rövid előadást, ami a címbeli gondolat köré épült. A gondolatot pedig Sara Wachter-Boettcher [Technically Wrong](https://www.amazon.com/Technically-Wrong-Sexist-Algorithms-Threats-ebook/dp/B06XJBGPT9/ref=mt%5Fkindle?%5Fencoding=UTF8&me=&qid=1530531311&ref=blog.fps.hu) című könyve ültette el a fejemben.

Nem is előadás volt, valójában csak kifejtettem ezt a gondolatot valamelyest. A könyv olvasása olyan húrokat pendített meg bennem, hogy égtem a vágytól, hogy beszéljek róla.

### Miért is?

Hasonló okokból fogyasztom az internetes oldalakat, használom az online eszközöket és mobil appokat, mint körülöttem a legtöbben. Szörfölök, keresek, ügyet intézek, játszom, zenét hallgatok, videót nézek, és így tovább.

A munkám miatt talán egy picit jobban rááll a szemem a hibákra, a furcsaságokra, de ugyanakkor észreveszem a szuper megoldásokat és az apró jóságokat is.

Nagyon tudok lelkesedni, amikor érződik egy terméken, hogy a készítői odafigyeltek arra, hogy ki fogja azt használni. Amikor érzem, hogy én, a felhasználó fontos voltam, hogy nekem szánták, hogy a kezemre áll, hogy valóban könnyebbé, jobbá, és szebbé teszi az életem. Boldogabb leszek tőle. De éppen annyira le tud hangolni, ha egy termék bántja a felhasználót, ha bánt engem. Boldogtalan leszek tőle.

#### Jacky esete a Google Fotókkal

A Google Fotók nevű szolgáltatással a mobiloddal készült képeket automatikusan fel tudod tölteni a felhőbe, majd bármely eszközről elérheted. A szolgáltatáson belül a képeket rendezheted, szerkesztheted vagy megoszthatod másokkal. Sőt, pár éve a Google egy remek új feature-rel bővítette a szolgáltatást: a feltöltött fotóidat egy algoritmus segítségével automatikusan kategóriákba rendezte.

2015 nyarán Jacky Alciné egy szabadtéri koncerten szelfizgetett a barátjával. A több mint 50 fotót a mobilja automatikusan felszinkronizálta a felhőbe, majd a Google Fotók az összeset bekategorizálta. A rendszer a kategóriának az a nevet adta, hogy [„Gorrilák”](https://www.wnycstudios.org/story/deep-problem-deep-learning/?ref=blog.fps.hu).

Természetesen nem ember csinálta a kategorizálást. A használt algoritmus egy neurális háló alapú technológia, amely egy kezdeti betanítási fázis után képes saját maga döntést hozni. Bár a betanításban emberek is részt vesznek, a későbbi, automatikus működés során a gép már a tanult minták alapján cselekszik.

A feladat nyilván nem triviális. A képek lehetnek nagyon komplexek, akár több kiemelkedő fontos témával, vagy ezernyi apró részlettel. Bármilyen jó volt a betanítási fázis, bármekkora volt a minta, nem várható el, hogy a gép által hozott döntés tökéletes legyen.

A fontos kérdés itt talán nem is az, hogy tévedhet-e a Google Fotók, hogy belefér-e az, hogy egy-egy képünket rosszul kategorizálja. A kérdés inkább az, hogy megteheti-e azt, hogy egy fekete bőrű felhasználót legorillázzon, és ezzel évszázados sebeket feltépve vérig sértse.

*Az eset nem egyedülálló.*

#### Emlékeid a Facebookon

2014-ben a Facebook egy új feature-e, az „Emlékeid a Facebookon” a felhasználók idővonaláról a legtöbb reakciót kiváltó bejegyzést felajánlotta újraposztolásra. Az ötlet egyszerű és nagyszerű, hiszen ha valami sok embernek tetszett az év során, akkor arra szívesen emlékszünk, és szívesen megosztjuk ismét. Eric Meyer azonban ahhoz a kisebbséghez tartozott, akit ez az új feature nagyon bántott. Karácsony estéjén dobta fel neki a Facebook az év során meghalt kislánya, Rebecca fényképét, amit Eric a gyászhírt bejelentő bejegyzésében használt. A gyászhír akkor nagy reakciót váltott ki, hiszen rokonai, barátai és ismerősei mind kommentben fejezték ki együttérzésüket, így a Facebook automatikus algoritmusának számára egyértelmű választás volt – ha sokan reagáltak, akkor ez fontos volt az életedben. Ez igaz is lehet. Viszont [Rebecca fényképe körül ünneplő emberek táncoltak lufik és szerpentinek kavalkádjában](http://www.slate.com/blogs/future%5Ftense/2014/12/29/facebook%5Fyear%5Fin%5Freview%5Fmy%5Ftragic%5Fyear%5Fwas%5Fthe%5Fwrong%5Ffodder%5Ffor%5Ffacebook.html?ref=blog.fps.hu).

*És még…*

#### Pislogásmentes képek

A Nikon néhány éve egy új feature-t fejlesztett a Coolpix fényképezőgépeibe. A kép elkattintása után azonnal figyelmeztet, ha a képen valaki pislogott. Szuper ötlet, mert ott és akkor új képet készíthetsz, ha szükséges. Mindenki számára nagyon hasznos. De kiderült, hogy vannak kivételek. Van, aki számára nemcsak hogy nem hasznos, de még bántó is. Mert mi történik akkor, ha bármennyi képet is készítesz, mindig úgy érzékeli a gép, hogy valaki pislogott, miközben nem is? Ha csak annyi a [baj a képen szereplővel, hogy ázsiai származású](http://content.time.com/time/business/article/0,8599,1954643,00.html?ref=blog.fps.hu)?

Sajnos sok példa jöhetne még ide, ahol a dizájn bántó, kirekesztő, agresszív, lenéző, rasszista, szexista, age-ista, elidegenítő, kihasználó, elnézi vagy akár segíti is a trollkodást.

Teszi ezt úgy, hogy közben a szolgáltatás jó, a tervezők és fejlesztők mind jót akartak. Hiszem, hogy jól átgondolták, sőt, le is tesztelték. Csak valami mégis félre ment.

**Miért?**

### Nem mi vagyunk a felhasználók

Ősrégi mantra ez, tudom.  
Szinte soha nem ismerjük a felhasználóinkat. A saját kis mikrokörnyezetünkben élünk, abból indulunk ki. Ülünk a belvárosi irodában, a fejlesztő, a dizájner, a projektmenedzser kollégák között, akik hasonló életkorúak, hasonló végzettséggel rendelkeznek, és az érdeklődésünk is legalább a munka szintjén hasonló. Majdnem azonos helyről tekintünk a világra, a legnagyobb különbségeink – kis túlzással – kimerülhetnek abban, hogy sört vagy fröccsöt igyunk este.

Emellett [rengeteg olyan kognitív torzítás](https://blog.kolboid.eu/67-modszer-hogyan-novelheted-a-konverziot/?ref=blog.fps.hu) van, amely meggátolja, hogy az agyunk racionálisan döntsön, hogy másokra is odafigyeljünk, hogy ne saját magunkból induljuk ki. Így működünk, és ezen hatékonyan csak akkor tudunk változtatni, ha megismerjük a torzítások mechanizmusait, ha tudatosan teszünk azért, hogy leküzdjük őket.

### Mit tehetünk?

Igazán egyszerű: mielőtt belevágnánk a projektbe, ismerjük meg a jövőbeli felhasználóinkat. Beszéljünk velük. Derítsük ki, hogy milyen megoldásra váró problémáik vannak. Figyeljük meg, hogyan próbálják megoldani azt most, a termékünk nélkül. Kérdezzük meg őket, hogy mire vágynak, mitől lenne könnyebb az életük, mi tenné őket boldoggá. Vonjuk be őket a tervezésbe, kérjük ki a véleményüket, mutassuk meg nekik, hogy törődünk velük. Hagyjuk, hogy segítsenek, sőt, kérjük a segítségüket.

Az IDEO kultikus dizájn cég [desingkit.org](http://www.designkit.org/?ref=blog.fps.hu) alatt található remek gyűjtése segít elindulni és eligazodni a UX eszközök széles tárházában. (Nem csak kezdőknek!)

A gyűjtésben szerepel két gyakran használt eszköz: a perszóna és a felhasználói (használhatósági) tesztelés. Mindkettő kiváló eszköz, mi is használjuk ezeket a projektjeinkben. Perszóna nélkül el sem kezdjük a tervezést, ahogy valós felhasználókkal történt tesztelés nélkül nem engedünk útjára terméket.

*Miért emeltem ki ezt a két eszközt?*

#### A perszóna veszélye

A perszóna egy személyben megtestesíti a célközönségünket. Számára készítjük a terméket, az ő igényeire szabjuk, őt szeretnénk kiszolgálni. Azt feltételezzük, hogy a perszónánk lefedi az összes jövőbeli felhasználónkat. És ez így oké is, hiszen nem lehet és nem is kell mindenkit figyelembe venni. Koncentráljuk a perszónánkra. De tegyük ezt úgy, hogy közben a többi, a perszónánk által nem lefedett esetleges felhasználónkat ne bántsuk. Még ha elenyésző számú kisebbségről van is szó, ne tervezzünk olyat, ami őket sérti, kirekeszti, lenézi, stb.

#### Felhasználói tesztelés fontossága

Megmutatjuk a terméket a felhasználóinknak. Tudják használni? Értik? Jó ez nekik? A visszajelzések alapján tudunk rajta változtatni, vagy akár teljesen újratervezeni. Ha a fejlesztés korábbi szakaszaiban nem is derült ki, hogy valami félrement, ezzel az őszinte és szemfelnyitó eszközzel lehetőségünk van még az élesítés előtt javítani rajta.

#### Soha nem vagy kész az első verzióval

És a másodikkal, harmadikkal, …, n-edikkel sem. Jönnek a visszajelzések, a mérések eredményei, azok alapján újratervezed a terméket és mehet a következő verzió. Ha minden erőfeszítés ellenére sem sikerült jól egy verzió, akkor lehetőség van azt gyorsan kijavítani.

Ha érdekel, pörgesd át a diákat:

Vagy nézd meg az előadásról készült videofelvételt:
### A design systemről – UI szemmel
URL: https://blog.fps.hu/a-design-systemrol-ui-szemmel/
Last updated: 2026-08-09T09:25:46.000Z
*Korábbi posztjaimban már elkezdtem feszegetni a témát és háromnegyed éve úgy hagytam félbe az egyik posztom, hogy mindjárt érkezik a folytatás. Szerencsémre nem jött, mert közben a Figma annyit fejlődött, hogy havonta írogathattam volna át az idejétmúlt megoldásokat. A mostani írás sem a folytatás, hanem egy [meetupon](http://meetup.com/ITrend/events/251262147/?ref=blog.fps.hu) elhangzott előadásom lenyomata. A téma az elmúlt egy év tapasztalatai és meglátásai UI-osként.*

*Mondanám, hogy öveket becsatolni és indul a hullámvasút, de itt most nem lesznek nagy megfejtések, se homlokcsapások, csak egy lassú, hömpölygő, megállíthatatlan folyamat ami felé tartunk. *Ez a design system. UI szemmel.**

![irogep-alkatreszei-1](https://blog.fps.hu/content/images/2018/06/irogep-alkatreszei-1.gif)

*A képen egy Adler Favorit típusú 1930-as években gyártott írógép és alkatrészei jelennek meg.*

Ahogy látható, sok-sok elem alkot egy egészet, amiket valahol, valaki kitalált, finanszírozott, összerakott rá egy csapatot, akik megtervezték, legyártottak. Másvalakik összerakták, és voltak akik kipróbálták mielőtt piacra dobták. Ha a képeken látott elemek közül egy hiányzik, vagy épp hibás, máris nem működött volna jól, vagy nem úgy működött volna az írógép, ahogy azt szerették volna.

Nincs ez máshogy a digitális termékek világában sem. Ha csak egy elemkészletet látunk, amit esetünkben hívhatunk UI kitnek, abból még sok mindent össze tudunk rakni, és ahány ház annyi szokás. Ahhoz, hogy úgy történjenek a dolgok a kezdetektől a felhasználói visszajelzésekig, és az ezekből történő módosításokig, ahogy azt szeretnénk, abban lehet nagy segítségünkre a design system.

Hogy mire volt jó ez a kis bemutató, arra kicsit később térek majd vissza, most inkább egy kis eredettörténet.

### Honnan jött?

Az 1960-as években a számítástechnika adta lehetőségek meghaladták a szoftverprogramozás sebességét. A számítógépek relatív gyorsabbak és olcsóbbak lettek, de a szoftverfejlesztés továbbra is lassú, nehezen fenntartható és hibákkal küszködő munka volt. Ezt a korszakot és problémakört hívják „software crisis” szoftveres válságnak.

Erre vázolta fel megoldását *Douglas McIlroy,* egy 1968-ban tartott szoftverfejlesztésről szóló NATO-konferencián, ahol bemutatta a komponensalapú fejlesztést mint lehetséges megoldást. A komponenslapú fejlesztés lehetővé tette a programozás felgyorsítását a kód újrahasználásával. Ez csökkentette az erőforrásigényeket, gyorsította a szoftverfejlesztést, miközben lehetővé téve a szoftverek számára, hogy jobban kihasználják a modern számítógépek erejét.

40 évvel később, hasonló kihívás előtt álltunk, de ezúttal a designban. A design küszködik:

- a felületek különböző méretivel,
- a fileok tárolásával, frissítésével,
- az elnevezésekkel,
- az egységesített rendszerek hiányával,
- mivel a design még mindig sok esetben egyedi, személyre szabott megoldásokkal állt elő.

Nem kell ahhoz UI-auditot készíteni senkinek –elég csak front-endes kollégákkal beszélni–, és máris sorolják a design oldalról kapott forrásokkal a problémákat. A szürke 50 árnyalatától kezdve, a méretezési, eltartási különbözőségeken át az elnevezések és sokszor a következetlenségek is jelen vannak.

> Itt minden egyedi.

– ahogy Pardi kollégám fogalmazott egy site buildelése közben.

Ha ez az általános, és egy oldalon ennyi eltérést ismerünk fel, akkor szorozzuk meg ezt a problémát minden egyes felhasználói felületen, és máris felismerhető, hogy egy bizonyos méret után a következetlenségek és hiányosságok erdejében képtelenek vagyunk tartani a kialakított csapást. Egyszóval ne csodálkozzunk, ha olyan a fogadj isten, amilyen az adjon isten.

Persze ezt tervezői oldalon is látták és igyekeztek is orvosolni, de inkább tüneti kezelések voltak azok, mint gyógyászat.

- Alkalmazz több embert, így gyorsabb lesz! – *vagy nem.*
- Dolgozz gyorsabban! – *köszi.*
- Alakíts ki egyedi megoldásokat! – *amik ha az adott folyamat egy részét gyorsították is, az egészet sokszor inkább lassították.*
- [Photoshop etikett.](http://photoshopetiquette.com/?ref=blog.fps.hu) – *maga a környezet nem volt megfelelő a probléma megoldására.*

Mindig jelen volt a probléma, hogyan tudod egységben tartani a terveket, hogyan lesznek azok következetesek és hogyan tudod azokat egységesen gyorsan módosítani? És még nem beszéltünk arról, hogy hogyan adod át ezt az információt, akár a fejlesztő, akár az ügyfél felé. Tehát **elérte a design is a saját válságát,** vagy még inkább **megszületett az igény egy egységes rendszerben történő tervezésre.**

Ezzel kezdődött úgy 10 éve a design system előretörése, fejlődése.

### A problémát ismerjük. Mi a megoldás?

Tehát az alapprobléma szépen lassan körvonalazódott és általánossá vált. Ennek kapcsán, viszont felmerültek továbbiak…:

- Hogyan lehet egy szerteágazó terméket konzisztensen megtervezni?
- Hogyan tudjuk az iterációkat értelmezhető határokon belül tartani, mind idő, mind erőforrás tekintetében?
- Hogyan lehet a megnövekedett tervezői csapatokat egy olyan mederbe terelni, ahol a termék is jól érzi magát, de nem vágjuk el a torkát a kreativitásnak sem?

Egyre több cikk, majd könyv foglalkozott a problémával és egyre többen látták a megoldást a szabványosításban, a lefektetett, előredefiniált munkafolyamatokban. Ezzel egyidőben a szoftvergyártók is kezdték ebbe az irányba fejleszteni programjaikat és próbáltak megoldást nyújtani a felhasználói felületeket tervező emberek számára. A Photoshopot szép lassan leváltották a célszoftverek. Így jutottunk el mi is, az fps-nél a Figmáig, mert láttuk, hogy mennyi felesleges erőforrás egy-egy psd elkészítése, rendszerezése, tárolása azok módosítása, nem beszélve a tervek fejlesztői környezetbe történő implementálásáról.

### OK, de kell ez nekem?

Spoilerezek egy kicsit és elmondom. Több mint valószínű, hogy nem. Viszont maga a rendszer olyan elemekre bontható, és olyan megoldásokat tartalmaz, amik segíthetik a későbbi munkádat, még akkor is, amikor nem használod ki az egészet.

Ha az alábbi listából ráismersz a termékre, amivel foglalkozol, akkor a válasz igen.

#### Olyan terméken dolgozol…

- amikor fontos a hasonló megjelenés és a hasonló viselkedés - *konzisztens felületek*
- ahol ismétlődő UI komponenseket kell használni – *akár egy komplex site*
- ahol ismétlődő alacsony funkcionalitás tartalmazó UI elemekkel dolgozol
- amikor „white label”, vagy template maga a termék
- amikor folyamatosan, visszatérve módosítani kell a felületen – *termékfejlesztés*
- amikor különböző „tech stack”-ekkel dolgozol – *akár már van a terméknek applikációja és weboldal is*

#### Mik az előnyei?

##### **Általánosan:**

- egy központi helyen kezeled a UI elemeket
- időt és ezáltal pénzt takarítasz meg
- nagyban növeli az egységességet
- csökkenti a karbantartási időt

##### **Tervezők számára:**

- átláthatóbb és könnyebben kezelhető felületek
- gyorsabb, globális módosítási lehetőség
- rövidebb iterációs hossz, ezáltal több megoldási javaslat, ami a végén nagyobb elégedetséget is szül, nem csak a felhasználóban, hanem a tervezőben is.

##### **Fejlesztők számára:**

- kevesebb idő a UI elemek megismerése
- csökken a refaktorálásra fordított idő
- következetes implementáció lehetséges  
  - *persze ezekhez szükséges a szoros együttműködés, és a megfelelő kommunikációs csatornák megléte, ami jelenthet akár egy dokumentációt, vagy élőbeszédet is a tervező és a fejlesztő között*

##### **Üzleti oldal számára:**

- időt spórol → pénzt teremt
- ezt a folyamatot már nehéz lesz visszafordítani, így mihamarabb a céges design kultúra része lesz, annál fájdalommentesebb a későbbi átállás
- jó a felhasználónak és az ügyfélnek, hisz egyre jobb terméket kap
- és persze jó a dolgozóknak, mert a munkafolyamatai átláthatóbbak és gyorsabbak lesznek, így egyre több ideje marad a kreatív ötletelésre

#### Hol a csapda?

Ott, hogy ha egy teljes, átfogó design systemet próbálunk kialakítani, akkor az nagyon költséges folyamat. Ha csak azt nézzük, hogy mennyi szereplő kell egy teljes paletta lefedéséhez:

- **Tervezők,** akik meghatározzák a rendszer vizuális elemeit.
- **Front-end fejlesztők,** akik moduláris kódot képesek fejleszteni.
- Legyen egy **akadálymentes szakértőd,** hogy a rendszer megfeleljen nemzetközi szabványoknak.
- **Tartalomstratégák** – akik segíthetnek, hogy a rendszered egységes, jól használható tartalommal jelenjen meg
- Olyan **kutatók,** akik segítenek megérteni az ügyfelek igényeit
- **Teljesítmény-szakértők,** akik biztosítják a rendszer gyors betöltését minden eszközön
- A **termék menedzserei** biztosítják, hogy a rendszer megfeleljen az ügyfél igényeinek
- **Vezetők** (döntéshozók és igazgatók), hogy az egész vállalatot – beleértve a vezetőket is –, elsajátítsák és összehangolják a jövőképet.

Ennek a csapatnak az összeszokása, a megfelelő edukálása, a csapat számára leginkább kézreálló módszertanok megtalálása – hogy segítsék és ne hátráltassák egymást –, és persze maga a termék üzleti és felhasználói oldalról történő megismerése is időigényes. [Erről lehetne bővebben beszélni,](https://www.youtube.com/watch?v=Eq0-Sz5S9iI&ref=blog.fps.hu) de az inkább már design menedzseri feladat lenne. Mi összpontosítsunk inkább a UI oldalára továbbra is.

### Hogyan kezdjünk neki?

**Nathan Curtis** design system evangélista szerint –

> Design system is not a project. It's a product, serving products.

– Azaz ez nem egy projekt, hanem egy termék. Egy olyan termék, amely termékeket szolgál ki.

![design-folyamat](https://blog.fps.hu/content/images/2018/06/design-folyamat.png)

Így is kell nekifogni. Meg kell tervezni magát a tervezést. Fontos, hogy mindig határozd meg a célokat, mit szeretnél elérni és milyen problémát akarsz megoldani. Ennek persze vannak a UI részén kívül más vetületei is a rendszer tekintetében, de maradjunk fókuszban.

#### A vizuális nyelv megszületése

UI tekintetben ez a mi feladatunk. Megalkotni egy termék vizuális nyelvezetét.  
Ha feldaraboljuk a vizuális rendszer elemeit, akkor a nyelvezetünket a következők alkotják:

- **Színek**
- **Tipográfia** *(méret, sorvezető, betűtípus stb.)*
- **Méretezések, eltartások** *(gridek, margók, igazodások)*
- **Ikonok** *(igazából az ikonok mellett, képek és illusztrációk)*

Egy szofisztikáltabb nyelvezet a következőket is tartalmazhatja:

- Vizuális formák
- Mozgás
- Hang

*Ez utóbbiak kevésbbé kötődnek szorosan a UI vonalhoz, így az előadásból is kimaradtak.*

#### Design tokenek

Mielőtt továbbmennénk, két dolgot is meg kell említeni. A tokenek, a design system „szubatomikus” alapjai. A fogalom [Brad Frost, Atomic design](http://bradfrost.com/blog/post/atomic-design-book/?ref=blog.fps.hu) című „kiáltványa” nyomán született.

A tokenek, azok a legegyszerűbb elemek – [részecskék,](https://daneden.me/2018/01/05/subatomic-design-systems/?ref=blog.fps.hu) amik tartalmazzák azokat az adatokat, amik egy atomi szintű elemnek az alaptulajdonságait tartalmazzák. Ilyenek a név, és azok az egyszerű változók, amik meghatározzák majd a későbbi elem egyes részeit. Például a lekerekítés nagysága, a vonalvastagság, annak stílusa stb. Fontos, hogy ezeket az elejétől egy helyen kell alkalmazni és a későbbi elemekbe, majd komponensekbe be kell építeni, hogy megmaradjon a konzisztencia és csökkentse a design system kezelésének terhét.

#### Dokumentáció

![dokumentacio-elnevezesek](https://blog.fps.hu/content/images/2018/06/dokumentacio-elnevezesek.png)  
*A képen egy nevezéktan táblázatba vezetett részlete látható.*

A másik, ami nem szoros része a vizuális nyelvnek, az pedig a dokumentáció. Ebben már nagyon hasznos, ha egy követ fújtok a front-endessel, mert akkor már az elejétől közösen tudtok egy olyan listát készíteni, amiben felvezethetitek a elemeket, azok neveit és egyedi tulajdonságait. Ki-ki majd kitölti a maga celláját, de a lényeg, hogy legyen egy élő lista, ami segíti mindkettőtök munkáját.

#### 1\. Színek

Természetesen jó, ha foglalkoztál színelmélettel, így könnyebb dolgod van. Viszont olyan nagy újdonságot nem kell várni, inkább csak a rendszerben történő tervezéshez igazított momentumokat emelném ki.

##### **Hierarchia**

Alkalmazz hierarchiát és alkoss csoportokat a színeknek, hogy később könnyeben tudjál rá hivatkozni. Válaszd külön az elsődleges, másodlagos színeket, a informális színeket és a szürke skáláidat is határozd meg. Ha már az elején felkészülsz az árnyalatokra, akkor később meg lehet akadályozni a színek elszaporodását is.

##### **Nevezéktan**

A korábban is említett **egységes nevezéktanhoz** jó gyakorlóterep a színek meghatározása. Ha tudod, már az elején kezdj el állapotokat rendelni a színekhez, amik a nevükben is megjelenhetnek.

##### **Stílusok**

[**Definiálj és alkoss stílusokat!**](https://help.figma.com/properties-panel/styles?ref=blog.fps.hu) Ami újdonság, hogy a digitális termékek korában is elérkeztünk ahhoz az állapothoz, mint amit a tördelőprogramok a kezdetektől alkalmaznak. Ez nagyon megkönnyíti az egység egyben tartását, és a későbbi globális módosítást is. Ezen felül segít neked is, hogy fókuszban maradj a tervezés során. Amikor pedig a fejlesztő próbálja a munkádból kiolvasni a a színeket, akkor végre nem találja magát szemben a harmincféle kékek állapotával.

##### **Általánosan**

A színharmóniák mellet viszont mindig **figyelj a kontrasztokra!** Építsd be és használd a UI elemek részeként a brand színeit és úgy általánosságban elmondható, hogy az eddig használt módszerek működni fognak.

##### **Tudásmegosztás**

Amikor véglegesíted a színeket, akkor dokumentáld, és oszd meg másokkal is az információt. Ez igaz arra az esetre is, amikor változtatás történik a színekben.

- [Itt látható, egy rövid videó, hogy miért éri meg a színeket stílusokként használni.](https://www.useloom.com/share/b6d5b22061994ff785c935b8aeaa5db3?ref=blog.fps.hu)
- [Itt pedig egy remek összefoglaló, a témáról.](https://www.uxpin.com/create-design-system-guide/build-color-palette-for-design-system?ref=blog.fps.hu)

#### 2\. Tipográfia

Ahogy a színeknél itt is a tipográfiai ismeretek használata révén olyan nagy újdonságokat nem fogunk tapasztalni. Sőt! Sokkal inkább egy tördelő program adta lehetőségek kezdenek itt is megjelenni.

##### **Skálázz!**

Az egyik fontos „újdonság” a méretezési rendszerek bevezetése. Itt is találhatsz számos mintát és kiválaszthatod a termékedhez a megfelelőt. Erre számos mintát lehet a neten találni, az aranymetszéses méretezéstől a négyes alapúig.

Erre egy jó kiindulási pont a <type-scale.com> oldala, vagy a [modularscale.com](http://www.modularscale.com/?ref=blog.fps.hu) ahol előre beállított arányokkal kísérletezhetsz. Ezeknek a méretezési standardoknak köszönhetően a reszponzívitással kapcsolatos problémák is leegyszerűsödnek.

##### **Segédvonalak**

Ahogy a színeknél, itt is eljönnek a tördelőprogramok megoldásai. Az egyik ilyen a vertikális segédvonalak (sorvezető), amikhez igazíthatod a sortávolságot, és ezzel is könnyeben meg tudod teremteni a vizuális egyensúlyt.

##### **Fent-lent**

Ami még fontos egy rendszer építésekor a tipográfia tekintetében, hogy már az elején igyekezz meghatározni, az eltartásokat. Sokat tudsz spórolni amikor már oldalakon használod és nem csak a Shift+nyíl nyomkodásával tolod el a betűtörzs, vagy betűszár aljától, tetejétől a következő szövegblokkot. Ez egyébként egy örök dilemma, hogy mely betűk, mettől-meddig határozzák meg a vertikális méretüket. Tapasztalataim alapján úgy jársz a legjobban, ha inkább a lelógó és felnyúló betűszárakat veszed alapul, aljának, illetve tetejének. A legjobb viszont ha csatlakozol a GridLoverek népes társaságához, és az oldal vertikális ritmusát már [ezen az oldalon beállítod.](https://www.gridlover.net/?ref=blog.fps.hu)

##### **Stílusok**

És az elmaradhatatlan stílusok. Ahogy a színeknél itt is elengedhetetlen, hogy stílusokban gondolkozz. Ezt inkább nem is magyarázom, [hanem egy videóban gyorsan bemutatom,](https://www.useloom.com/share/f71a9af0b1494c92b6a9fba889c8da5d?ref=blog.fps.hu) hogy miért működik végre ez remekül a Figmában.

##### **Mutasd be!**

Amikor úgy érzed, hogy pont jó (tökéletes sose lesz), akkor ahogy a színeknél, itt is dokumentáld, és oszd meg másokkal is az információt. Ez igaz arra az esetre is, amikor változtatás történik.

#### 3\. Méretezés és eltartások

![meretezesek-dokumentalasa-2](https://blog.fps.hu/content/images/2018/06/meretezesek-dokumentalasa-2.png)  
*A képen a bevitelimezők dokumentált méretezései és eltartásai láthatóak.*

Erre is [sok bejáratott direktíva](https://blog.prototypr.io/9-best-grid-system-for-web-mobile-ui-265c68d30c09?ref=blog.fps.hu) létezik és akár már a fejlesztésben is alkalmazott keretrendszereket is alapul veheted. A lényeg, hogy ezt minden esetben egyeztesd a fejlesztővel. Sokszor már ők olyan korlátokat fognak szabni, amikor nem lesz akkora mozgástered.

##### **Grid system**

Ez sem egy új dolog, de annál hasznosabb. Leveszi a terhet a válladról. Mindig ott lesznek az oszlopok, amik mankót nyújtanak, így neked már nem kell azzal bajlódnod, hogyan viszonyulnak az elemek és hova igazodnak, legyen szó desktop, vagy mobil nézetről. Ergo, az itt megspórolt időt a finomításokra és szépítésekre tudod fordítani, nem beszélve arról, hogy ha így dolgozol, akkor a fejlesztővel is jóban leszel.

##### **Légy következetes!**

A lényeg, hogy az elején tedd le a voksod egy mellé, mert ez mind a fejlesztésben, mind a további tervezésben lényeges méreteket fog meghatározni.

Amit én mostanság előszeretettel használok [az a 8-as,](https://spec.fm/specifics/8-pt-grid?ref=blog.fps.hu) vagy 4-es osztás. Amikor viszont ki kell lépnem a 8-as bűvköréből, akkor is igyekszem azt elszigetelt és egyedi esetnek megtartani és törekszem külön jelezni egy kommentben a fejlesztő felé, hogy itt a standardizált méretektől eltérő esettel van dolga.

Ami itt is fontos, hogy amennyire csak lehet **specifikáld és dokumentáld** az egységesített méreteket, majd ezt add tovább!

#### 4\. Ikonok

Ez az elmúlt években egy külön elszeparált munkakörré fejlődött. [Olyan szabályokat kezdenek alkalmazni,](https://medium.muz.li/icon-set-3b4fc87dc6b5?ref=blog.fps.hu) amikbe jómagam már nem biztos, hogy biztonságban érezném magam, így még nem merészkedtem bele.

##### **Az ideális**

Viszont vannak designerek akik a felismerhetőségen és a stílusosságon felül, a következőket is igyekeznek egységesíteni:

- **Optikai gridek** – a befoglaló és maga az ikon elhelyezkedésé azon belül
- **Pixel gridek** – itt nem csak a pixelpontosság, hanem a körvonalak igazodását is előre meghatározzák
- A **méretezési standardok** bevezetése → 24px → 36px → 48px → 72px
- És ami a legfontosabb, a **tiszta SVG-k** készítése. Ez már olykor inkább front-endes feladatba csúszik át, mert a grafikai programok még mindig szemetelnek exportálás közben.

![egyseges-ikonkeszlet](https://blog.fps.hu/content/images/2018/06/egyseges-ikonkeszlet.png)  
*A képen a Material Design 2 legújabb [ikonkészletének](https://material.io/tools/icons/?ref=blog.fps.hu) elemei láthatóak.*

De mondom, ilyen mélységekig még én se merészkedtem. Ahogy a képen látható, igyekszem úgy építeni az ikonokat, hogy azért megfeleljenek a standardoknak, de inkább a felhasználói és nem az ikon tervezői oldaláról szoktam közelíteni.

##### **Amikre figyelj az ikonoknál**

- Egységes méretezések és azok skálázása.
- Az elnevezések, és azok helyes használata.
- Komponensbe ágyazás, a könnyebb kezelhetőség miatt. *[Ennek előnyéiről készítettem egy videót.](https://www.useloom.com/share/2a9c12d3e724499a9bdf2c834583a3fa?ref=blog.fps.hu)*
- A befoglaló és maga az ikon különválasztása.

[A Google Material ikonrendszer elveiről pedig itt olvashatsz.](https://material.io/design/iconography/system-icons.html?ref=blog.fps.hu#icon-themes)

### Tovább is van…

És amikor végigmentél a fentieken, akkor foghatsz neki magának a [Pattern Library](http://patternlab.io/?ref=blog.fps.hu) kialakításának. Ezzel kapcsolatban szerencsére egyre több helyen lehet kimerítő olvasmányokat találni, melyek különböző mélységekben és eltérő megoldásokkal operálnak.

A lényeg, hogy kezd el strukturálni azokat a munkafolyamatidat, aminél a legnagyobb erőforrás-veszteséget érzed, és aztán majd ha tényleg szükségességes, belevághatsz a saját rendszeretek építésébe. Ebben segíthet ez a remek gyűjtőhely [designsystemsrepo.com](https://designsystemsrepo.com/?ref=blog.fps.hu), ahol a már megvalósult és kódszintre átültetett rendszerek listáját találod.

A végére pedig [egy joggal mondható klasszikus](http://mek.oszk.hu/03800/03821/03821.pdf?ref=blog.fps.hu) előszavából idéznék.

> „Ne feledjük, évtizedekkel korábban az újságokat és a folyóiratokat „készítették", most és a jövőben méginkább „gyártják", a szerkesztés-tervezés-ipar integrált bázisán gyártják. Ha tehát korszerűen gyors információról beszélünk, feltételezzük a szerkesztés-tervezés olyan egybehangolt munkáját, ahol a pontosan bemért szándékok tudatos, értelmes tartalmat kapnak.”

– 1976, **Lengyel Lajos** – Laptervezés, tipográfia-Előszó

#### Köszönöm, hogy elolvastad. 👋

---

Kapcsolódó prezentáció

---

A prezentáció diái

---

Források amik segítettek és irányba állítottak az előadással kapcsolatban.

- [Nathan Curtis Medium csatornája.](https://medium.com/@nathanacurtis?ref=blog.fps.hu)
- [Anne Grundhoefer Senior UX tervező előadása.](https://www.slideshare.net/annegrundhoefer/design-systems-enterprise-ux-evolution?ref=blog.fps.hu)
- [Paul Farino product design manager videója az InVision Design Talk sorozatából.](https://www.youtube.com/watch?v=Eq0-Sz5S9iI&ref=blog.fps.hu)

Két remek online könyv a design systemről:

- [A UXPin tervező csapatától,](https://www.uxpin.com/create-design-system-guide/?ref=blog.fps.hu)
- [A designbetter.co kézikönyve a témáról.](https://www.designbetter.co/design-systems-handbook?ref=blog.fps.hu)
### dailyDevNote – tudásmegosztás játékosan
URL: https://blog.fps.hu/dailydevnote-tudasmegosztas-jatekosan/
Last updated: 2026-07-17T08:24:03.000Z
Tavaly olvastam egy érdekes [cikket](https://medium.com/mito/hogyan-%C3%BAj%C3%ADtottuk-meg-a-kreat%C3%ADv-%C3%B6nk%C3%A9pz%C3%A9st-5bfc90029784?ref=blog.fps.hu), amiben az önképzés és tudásmegosztás egy kreatív és hatékony módját fejtették ki. Tetszett az ötlet, ki is próbáltuk, viszont nálunk sajnos nem lett akkora sikere a dolognak. További sikertelen próbálkozások után végre sikerült kialakítani egy olyan módszert, ami eddig beváltotta a hozzá fűzött reményeket.

### Cégen belüli tudásmegosztás

A tudásmegosztás fontosságáról [kolboid írt egy remek posztot](https://blog.fps.hu/tudasmegosztas-elonyei/), ami után már csak az merülhet fel kérdésként, hogy hogyan is kezdjünk hozzá, esetleg hogyan tegyük rendszeressé? A cégen belüli tudásmegosztásnak is sok eszköze lehet, a belső képzésektől kezdve a [mob programingon](https://en.wikipedia.org/wiki/Mob%5Fprogramming?ref=blog.fps.hu) át a workhshopokig. A belső szakmai kommunikáció elengedhetetlen a közös irányvonalak meghatározásához, az esetleges felzárkózásokhoz vagy építő jellegű vitákhoz. Ugyanakkor az is fontos, hogy minden szakmai közösség, vagy csapat más és más, így valószínűnek tartom, hogy nincs univerzális megoldás, éppen ezért érdemes kisérletezni.

### A személyes megszólítás

Számtalan alkalommal belefutottam abba a szituációba, hogy belső körlevelet küldök, amiben segítséget kérek, kb. az összes címzettől. Ezek tipikusan a *"ha valakinek van valami jó ötlete…"* vagy *"ha valaki tud egy jó linket…"* és hasonló mondatok. No mi is történik ilyenkor? Mindenkit megszólítasz, de valójában csak keveseket, vagy senkit. Persze, vannak mindig proaktív emberek, akik ilyenkor magukra veszik a dolgot és ezzel sokszor oda kerül a szituáció, hogy a többiek már nem is érzik fontosnak a kérést, hiszen valaki úgyis magára vette, akkor nekik már nem szükséges foglalkozni vele.

A fentieket sokan bebizonyították már, de a sokadik tapasztalás után, egy véletlenszerű ötletként jött, hogy hogyan is változtassunk a formán. Biztosabb eredményre vezet a folyamat, ha minden esetben egy, konkrétan megnevezett *"felelőse"* van a feladatnak és rajta múlik, hogy ne szakadjon meg a folyamat.

### Fontos az egyensúly

Érthető módon, senki nem örülne, ha egyszercsak valaki kiválasztaná, hogy márpedig egy héten belül készüljön el egy belső képzés anyagával. Nem reális, nincs rá elkülönített időkeret és sokunknak igenis felesleges feszültséget okoz, ha ilyen felelősséget osztanak ránk, arról nem is beszélve, hogy egyáltalán akartuk, vagy sem. Ez kérdésként is felmerült egy meetup alkalmával, amikor a témáról tartottam előadást és vitatkozni nem is tudtam vele. Éppen ezért úgy fogalmaztuk meg a szabályokat, hogy mindenki számára vállalható legyen, ne terheljen le indokolatlanul senkit a teljesítése, továbbá az egész részvétel opcionális legyen.

### Napi fejlesztői jegyzet

A dailyDevNote cím gyakorlatilag leírja a lényeget. **Rendszeres időközönként küldött, rövid szöveges jegyzet, ami a fejlesztésről szól. Elindulása óta fejlesztőről fejlesztőre száll a feladat, hogy írjon egy levelet, majd a végén az ő joga kiválasztani, hogy kitől vár következő alkalommal levelet a közös címre.** A teljes leírást elolvashatod [ebben a gistben](https://gist.github.com/totya24/e8debbfcacbb7d31eba84f13d026263d?ref=blog.fps.hu), a szabályok felsorolva a következők:

- a levél témája kapcsolódjon a munkádhoz, bármilyen szinten. Lehet egy téma körbejárása, poén, szimpla érdekesség, de a legjobb, ha saját tapasztalataidat osztod meg, amit a közelmúltban szereztél és érdemesnek tartasz erre
- ha kiválasztanak, 3 napod van arra, hogy elküldd a levelet!
- valakit akkor jelölhetsz meg következőnek, ha az visszamenőleg minimum 3 alkalommal nem küldött levelet, vedd figyelembe a kiválasztott kolléga leterheltségét!
- a levélnek van egy sablonja (lásd [gist](https://gist.github.com/totya24/e8debbfcacbb7d31eba84f13d026263d?ref=blog.fps.hu#p%C3%A9lda))
- elvárt a minimum 3 mondatos tartalom (mi ez, miért jó, hol találtad, stb.)

### Működik!

Gyors közvéleménykutatás, és az elmúlt fél év tapasztalatai alapján a rendszer működik, szeretik és javarészt hasznosnak is találják a fejlesztők.  
15 ember esetén is az a kényelmes helyzet alakul ki, hogy 2–4 naponta jön valakitől egy tartalmas és érdekes levél, viszont egy-egy fejlesztő átlagosan kéthavonta kerül sorra. 60 naponta 30 perc nem nagy áldozat és fenn tudjuk tartani a folyamatosságot.

- A témaválasztás még mindig pillanatnyi frusztrációt okoz
- Van, aki előre megírja és várja, hogy sorra kerüljön
- Jellemzően mindenki betartja a határidőt, ritka a késés és akkor is minimális
- Egymás leveleit javarészt hasznosnak és érdekesnek találják a résztvevők
- Megvan az egymás iránti tisztelet, figyelemmel kísérjük, elolvassuk a másikét és visszajelzést adunk

### Kontra

Ahogy az elején is írtam, nincs két egyforma csapat, lehet, hogy ami nálunk működik, az máshol eleve kudarcra van ítélve. Beszélgettem is olyan fejlesztőkkel, akik már csak a szabályokat hallva fel voltak háborodva, hogy ők egy ilyenben nem tudnának részt venni, nem tehetem azt a nyomást a vállukra! Ezt teljes mértékben el tudom fogadni, ezért is opcionális a részvétel, ugyanakkor azt gondolom, hogy ez még a vállalható és teljesíthető feladat.

### Kapcsolódó prezentáció

#### A prezentáció diái
### Egyedi termék- és szolgáltatásfejlesztések első lépései: a Lean Canvas.
URL: https://blog.fps.hu/lean-canvas-tervezes-az-fps-ben/
Last updated: 2026-07-17T08:24:13.000Z
Sok olyan digitális, szolgáltatás, és termékötlet is megtalál minket, ami egyedi és újító. Egyedi és újító, mert nincs igazán előzménye, új az üzleti modellje, új felületet kíván meg, egy korábbi viselkedést ír felül, vagy éppen új a felhasználási módja. Egy valami biztosan közös ezekben: van benne valami, amit így még soha, senki sem próbált ki élesben.

Hasonló lehet, hogy már létezik, de pont olyan, pont abban a formában még nincs. A jövőjét tehát mindenképp bizonytalanság övezi.

Az, hogy az ötlettel milyen formában, előkészítettséggel találnak meg minket nagyon változó. Van, amikor egy már késznek gondolt hosszú specifikációba öntött megoldással, több oldalas prezentációval, egy A4-es oldalt kitevő gondolathalmazzal, vagy épp egy paragrafus hosszúságú problémafelvetéssel (eláruljuk, hogy ez utóbbit szeretjük a legjobban) jelentkeznek nálunk.

Emellett persze mindig megspékelve reménnyel, hogy a termék értékelhető és használható része időre kész lesz, egy nem túl távoli időhorizonton belül üzleti sikert is hoz, és természetesen a célcsoportba tartozó összes ember örömközpontját stimuláló márkává válik.

Ami a legfontosabb ebben a korai, embrionális szakaszban: a termék gondolatát életrekeltő **probléma közös megértése**. Közös megértés az ötletgazdával, a tervező és megvalósító csapatainkkal.

Nekünk, akik egyfajta építész szerepben elkezdjük majd felrajzolni a lehetséges megoldásokat nem szabad szerelembe esni a már késznek gondolt, "hozott" megoldással.

Nekünk a problémát kell első körben randira hívnunk. Azt a problémát kell megismernünk, amit a termék vagy szolgáltatás a leendő használói számára megoldani kíván.

A közös probléma megértéshez való eljutáshoz az egyik, általunk használt módszer, eszköz a [Lean Canvas](https://canvanizer.com/new/lean-canvas?ref=blog.fps.hu), ami a startupok által széles körben használt és az elmúlt évtizedben igen közismertté vált [Business Model Canvas továbbfejlesztése.](https://blog.leanstack.com/why-lean-canvas-vs-business-model-canvas-af62c0f2?ref=blog.fps.hu)

Lényege a probléma fókuszú termék definíció, melynek alapján egy térképen (ez maga a Lean Canvas) ábrázoljuk az elképzelt termék és a termék piacának legfontosabb jellemzőit. A térkép alapján az is jól meghatározható, hogy mik a termék és az üzlet legnagyobb kockázatai.

Egy megfelelően előkészített helyzetben pár nap alatt eljutunk odáig, hogy egy fokkal magabiztosabban állunk a tervezői terepasztalunkra kiterített térképünk felett. A félreértéseket minimalizáljuk és mindenkinek, belelértve az ötletgazdát és megvalósító csapatot, kialakul egy közös képe arról, hogy az elképzelt termék milyen emberi problémákra, feladatok elvégézésre kínál megoldást.

Az általunk használt és ajánlott online [Lean Canvas eszköz: a LEANSTACK](https://leanstack.com/?ref=blog.fps.hu).

Ha eddig sikeresen lekötöttem a figyelmed az írással, akkor biztosan felfigyeltél a fent használt „megfelelően előkészített” kifejezésre. A következő posztban az ilyen előkészületeket segítő, felesleges megvalósítási köröket lerövidítő, a problématerületet jól körülhatároló módszerről, J. Rasmusson által megalkotott [Agile Inception Deckről](https://www.slideshare.net/dleyanlin/99-inceptiondeck?ref=blog.fps.hu) fogok írni.
### Az elveszett iteráció fosztogatói
URL: https://blog.fps.hu/az-elveszett-iteracio-fosztogatoi/
Last updated: 2026-07-17T08:24:23.000Z
Mindannyian számtalanszor találkoztunk azzal a jelenséggel, hogy a saját magunkba vetett bizalmunk ellenére is meglepődünk, ha a kódunk működik. Lelkiismeretes szakember lévén rengeteg álmatlan éjszakát okoztak a kérdesek:

> *Mit csináltam most jól?* 
> *Miért szeretnek engem a kollégáim?* 
> *Miért nem okoznak nekem nehézseget ezek a feladatok?*

Eme kérdesek válaszainak kutatása sokkal messzebbre nyúlik a történelemben, mint azt képzelnénk. A XXI. század derekán is komoly fejtörést okozó egzakt válasz keresése valószínűleg a közeljövőben véget érhet.

De hogyan is jutunk el ezekhez a válaszokhoz? Mennyire kell mélyre ásni a történelem hátsóudvarának sóval égetett sötét kertjében a megértésig? Milyen rejtélyek várnak bennünket a korántsem veszélytelen kutatás közben? Mikor lesz vége ennek a teljesen feleslegesen hosszú és túlfogalmazott bevezetőnek?

…Most!

…És az egész egy hibás kóddal kezdődött.

### A nulladik keresztes hadművelet

Az írásos fejlegyzésekből kimaradt hadjárat indoka VII. Gergely pápa bíborosaihoz intézett Kr.u. 1075-ben kelt levele, melynek lezáró mondata:

> *\[…\] és engem nem érdekel, ki cseszte el, delutánra ki kell javítani, mert holnap van a deadline!*

*(VII. Gergely pápa, project-owner)*

A titokban előkészített hadjáratnak egyetlen célja volt: feltárni és eliminálni a hibát. Hogy ne kerüljön napvilágra, a pápa megszervezett egy álháborút a Szentföld, vagyis *Jeruzsálem* visszafoglalásáért. VII. Gergely furfangjáról árulkodik a korántsem véletlen helyválasztás. *Jeruzsálem* ugyanis az *„árus jelmez”* anagrammája, ami a hadművelet módjára utal: a pápai katonák magukat kufároknak álcázva észrevétlenül jutottak be Egyiptom területére.

![Jeruzsálem – árus jelmez](https://blog.fps.hu/content/images/2018/05/Untitled-1-1.gif)

A küldetés 1099-re hozta meg a várva várt eredményt, amikor Abu-Szir mellett levő barlangban a katonák végre felfedezték a hibás töredéket. Az akkor regnáló II. Orbán pápa igyekezett lezárni az álháborút és minden erőforrását az egyiptomi város felé irányította. Több grafikussal másoltatta le és vitette Rómába a kódot személyes áttekintésre.

![Abu-Szir hibás iteraciójáról készült kódmásolat](https://blog.fps.hu/content/images/2018/04/tmp243020121570803713.jpg)

*(Abu-Szir hibás iteraciójáról készült kódmásolat)*

A Vatikán levéltára szerint a hetekig tartó szüntelen review-t követően következőkeppen szólt II. Orbán:

> Komolyan ennyi volt csak a hiba és mi eddig nem vettük észre?! Hát én meghalok!

Szavát jó keresztényként betartva, másfél órával később 1099\. július 29-én meghalt.  
Nem derült ki, min akadt meg a szeme, bíborosai pedig érezték, hogy a további kutatás veszélyes lehet, ennek okán 1113-ban hosszú időre elzárták Málta szigetén és csak a legtapasztaltabb szakembereknek engedték a további review-kat.

A szigorítást a XIV. század közepén vegül VI. Ince pápa oldotta fel egyik bíborosának *„Ince tele a pince”* szóviccét hallva, akire bosszúból ráosztotta az egész feladatot.

![A bosszús VI. Ince pápa átadja SSH kulcsot és a projekt dokumentációját a visszakozó bíborosnak.](https://blog.fps.hu/content/images/2018/05/pope.png)  
*(A bosszús VI. Ince pápa átadja az SSH kulcsot és a projekt dokumentációját a visszakozó bíborosnak.)*

A hibás iteráció – amire a XIV. századtól röviden "*hiERRORglifa*" néven hivatkoznak – magában rejt egy különös együttállást, ami nem csak a laikus szemnek, de még a hozzáértő mesterembereknek sem tűnt fel egészen a XVI. század első feléig.

### Da Vinci Sárospatak mellett is élt?

A szigorítás feloldása után kezdett körvonalazódni az akkori emberek mélyen lesújtó hozzáállása: *„Ez nem az én problémám, miért kellene nekem foglalkoznom vele?”* Akik mégis hozzáfogtak a rejtély kulcsának kereséséhez, rendszerint elakadtak, gyakran már a kód olvasásakor: *„Ülő emberek. Háromfejű hattyú. Leveses kanál. Ki ír ilyet?”*

**Leonardo da Vinci** azon kevés emberek közé tartozik, akik nem adták fel az első bukásnál és kitartóan keresték a kód mögött rejtőző titkot. Fiatal diákként találkozott először a hiERRORglifával, tanulmányai befejezése után ideje nagy részét az azzal kapcsolatos kutatásba fektette.

Miután sikertelenül járta végig elődei útját, egy akkor új szemszögből közelített: Az ezotériát kérte segítségül. Jósok, halottlátók és okkult társaságok segítségével dolgozott tovább.

További egy év eredménytelenséget követően úgy döntött, maga is aktív résztvevője lesz a szeánszoknak, ellenőrzött körülmények között megissza a főzeteket, meditál, és várja a látomást. Az italok mellékhatásai visszatérő álmokat hoztak egy sámánisztikus figuráról, aki álmában hívta őt: *„Gyere őrült! Gyere őrült!”* Eme álom segítségevel jutott el ahhoz az emberhez, aki alapjaiban változtatta meg a kód értelmezését.

#### Mi van a kör közepén?

**Sáros-Pataki Attila** zempléni látó munkássága haláláig csak kevés emberhez jutott el kortása, Nostradamus nagy népszerűségnek örvendő jóslatai miatt. Vízióit a teljesség igénye nélkül jegyezték le, megfelelő fordítások sem készültek.

Da Vinci-t szerencsére ez sem állította meg abban, hogy felkeresse az álmában megjelenő sámán egykori lakhelyét. Többször utazott a Zemplénbe, kutatási során jó viszonyt ápolt a helyi magyar lakossággal, akik az elején azt hitték, Leonardo beszédhibájából kifolyólag töri a nyelvüket. (*Érdekesség, hogy a Sárospatak melletti települést később az itáliai polihisztor tiszteletére keresztelték át *Somogyszentbikkről* *Bodrogolaszira*.*)

Zempléni kutatása során bukkant rá Attila egyik lejegyzett látomására:

![A zempléni látó álmodik egy világot magának](https://blog.fps.hu/content/images/2018/05/Artboard-1-1.png)

*(kép: A zempléni látó álmodik egy világot magának (1894) | festő: Benczúr Gyula)*

> És látám és ímé egy kör közepén állék, s álltomban köröttem barátságban jók és barátságban rosszak vala.

A vízió többszöri hangos felolvasása után da Vincinek eszébe jutott, hogy Abu-Szir kódján csupán egy, rejtélyesen kezével az ég felé nyúló alak szerepel *(„…egy kör közepén ÁLLÉK…”)*. Leonardo azonnal tudta, hogy ez nem lehet véletlen. Ez ki is derül jegyzetéből:

> Ez nem lehet véletlen!

*(Leonardo ~~di Caprio~~ da Vinci)*

Azonnal rajzolni kezdett, keresvén az alak köré rajzolható kör pontos rádiuszát.

![kor1](https://blog.fps.hu/content/images/2018/05/kor1.png)

A meghatározatlan sugárban rajzolt körök közül egyetlen egy volt, mely nagyjából megfelelt a sámán látomásának. Ezt követően próbaképpen szelektálta a negatív, illetve pozitív alakzatokat mint róka, madár, másféle madár és vizet kiöntő asszony. Ha egymás mellé helyezzük egy korábbi munkájával, a *Vitruvius-tanulmánnyal*, döbbenetes hasonlóságot vehetünk eszre. Csupán véletlen egybeesés lenne, vagy valami több is áll az egyezés mögött?

![kor2](https://blog.fps.hu/content/images/2018/05/kor2.png)

Da Vinci olyan közel állt a kód megoldásához, ahogy előtte még soha senki, viszont az áttöréshez a kor számítógépeinek alacsony számítási kapacitása közel sem volt elég. Leonardo hagyatékát és céljait képviseli a halála előtt alapított **Dél-Itáliai Kód Közösség Hűséges Egylete** *(DIKKHE)*, egy zárt és rejtőző társaság, akik életüket tették fel a polihisztor munkájának befejezésére. Képviselői általában kevésbé ismert emberek úgy, mint napjainkban:

- **Banvölgyiné Kemenes Annamária** bolti eladó *(Kondásnémeti)*
- **Fodorodszki Tibor Elemér** testnevelés tanár *(Üstökfüles)*
- **Kolozsvári Kálmán** kolozsvári lakos *(Kolozsvár)*

### A XX. század és a *Sajátgép-felismerés*

A társaság tagjai a modern időkben sem voltak tétlenek, a közelgő technológiai robbanást már érezni lehetett a levegőben. Egyre hatékonyabb eszközökkel kerültek egyre közelebb a majdnem 1000 éves kérdéshez: *Miért nem megy ez a s\*\*r?*

**Hugo Abendessen** (osztrák rendszergazda, állandó DIKKHE tag) a két világháború közötti munkássága nagy részét töltötte ki a kód tanulmányozása.

Szűk társaságának egyik tagja, aki csak hobbi szinten foglalkozott a rejtélyes kóddal, állította, hogy sikerült lefuttatnia hiba nélkül a töredéket. Abendessen szkeptikus ember lévén a saját szemével, saját gépén szerette volna látni az eredményt, így megkérte barátját, mutassa meg neki a sikeres futtatás pontos folyamatát. Itt aztán kibújt a szög a zsákból. Több óra sikertelen próbálkozás után sem bírta rávenni a korabeli masinát a kód futtatására. A barát a következő, mára már legendássá vált mondattal reagálta le a esetet: *"Ja, naturlich, aber ich habe keine SevenUp."* Ami annyi tesz:

> *Pedig ez az én gépemen működött.*

![Abendessen (sárga ingben) barátaival Abu-Szir kódját vizsgálja](https://blog.fps.hu/content/images/2018/05/USN-XIV-p46-1b.jpg)  
*A képen: H. Frühstück, A. B. Mittagessen, H. Abendessen, N. Pausenbrot mit Marmelade*  
*Abendessen (sárga ingben) barátaival Abu-Szir kódját vizsgálja*

Abendessen egyertelműen látta, mi is történt. Barátai csupán kifogást kerestek. Később így írt az esetről.

*„Amikor megkérdeztem őket, milyennek látták a kódot, nem kaptam egyenes válaszokat. folyamatosan kitértek, egymásra mutattak és úgy látszott, meg sem értették miről van szó. Hivatkoztak arra, hogy ezt előttük sem oldotta meg senki, miért tudnák pont ők? Mivel lennének ők többek? Miért nem kerdezzük meg azt, aki írta? Ekkor jöttem csak rá…*

*Magam sem vetettem egyetlen egy pillantást sem a kódra. A kódra, ami már ki tudja mióta kijavítatlanul várja, hogy egyátalán ránézzen valaki. Azért nem vették észre elődeim sem a nyilvánvalót, amiért én sem. Eleve kétségek között vettem át és mielőtt egyetlen betűt is láttam volna belőle, a fejemben már a hibákat kerestem.*

*Mindenki mítoszokkal volt elfoglalva és hogy miért nem lehetett megoldani. Még a törtenelmet is képesek voltak a saját fantáziáik mentén megváltoztatni azért, hogy igazolják magukat. Hitelesnek tűnő történetek, hamis alátámasztások és puszta véletlen egybeesések. Ezek engem is megvezettek. De végül döntöttem. Egy éjjel elővettem a kódot, megtettem azt, amit előttem nem tettek meg: Ránéztem a szememmel.”*

![pontosvessző](https://blog.fps.hu/content/images/2018/05/ponts.png)

#### Abendessen hagyatéka

Hugo Abendessen felismerése alapjaiban változtatta meg a szemléletmódomat. A probléma megoldásának kulcsa nem a szakértelem, hanem a hozzáállásunk. Ugyanazzal az alázattal kell dolgoznunk más kódjával akkor is, ha az jó és akkor is, ha kívánni valókat hagy maga után.

És mik is a válaszok?

- **Mit csináltam most jól?**  
Mert nem picsogtam, hogy más kódjával kell dolgoznom még akkor sem, ha azt dokumentálatlanul vettem át.
- **Miért szeretnek engem a kollégáim?**  
Mert nem keresek kifogásokat, amikor valaki egy legacy kód áttekintésében és javításában kér segítséget tőlem.
- **Miért nem okoznak nekem nehézseget ezek a feladatok?**  
Mert az időm nagy részét a feladatok megoldására fordítom és nem a kód minőségének becsmérlésére.
### Androidos újdonságok a Google I/O 2018-on
URL: https://blog.fps.hu/google-io-2018-android/
Last updated: 2026-07-17T08:24:34.000Z
A Google asszisztens felhívja a fodrászt és lefoglalja a számomra ideális időpontot nála. Talán ez volt az idei I/O leginkább hűha pillanata. Ezen kívül volt viszont Android-ot érintő bejelentés és hasznos előadás. Összeszedtem mik voltak ezek.

### Jetpack

Létrehoztak egy olyan csomagot, amelyben fejlesztést segítő eszközök és dokumentációk találhatóak meg. 4 nagy részre oszlik:

- Foundation (KTX, appcompat, multidex, test)
- Architechture (databinding, Lifecycles, ViewModel, LiveData, Room, Paging, Navigation, WorkManager)
- Behavior (Download manager, Media, Notifications, Permissions, Sharing, Slices)
- UI (Animations, Auto, Emoji, Framgent, Layout, Palette, TV, Wear OS)

#### AppCompat

A legnagyobb változás, mert átírták a namespace-t. Az android.support.v4 átváltozik androidx-re, ami Android eXtensions-t takar. Ez érinti a többi support névteret használó könyvtárat is és mindegyik az új alatt lesz elérhető.  
v4 a 4-es apival való kompatibilis osztályokat rejtette magában. Sok év eltelt és a minimum API 16 már, de a név beragadt.

Külön eszközt írtak az Android Studioba, ami a projektedet átírja az újra. Függőségekben is át kell írni, így egy Jetifier nevű eszköz azokban is átírja. Egyelőre ezek az eszközök tesztelés alatt vannak és az Android Studio 3.2 canary verziójában érhetőek el.

A verziózás is megváltozik és 28.0.0 az utolsó API-hoz kötődő verzió. [Semantic versioning](https://semver.org/?ref=blog.fps.hu)\-et fognak alkalmazni. Függetlenek lesznek egymástól a komponensek verziói, tehát ha kijavítanak a RecyclerView-ban egy hibát, azt a verziójának növelésével azonnal ki lehet adni.  
Mindezekről és a további újdonságokról [nézd meg az előadást](https://www.youtube.com/watch?v=jdKUm8tGogw&index=27&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu).

#### WorkManager

Egy új lib a Jetpackban a [WorkManger](https://www.youtube.com/watch?v=IrKoBFLwTN0&index=31&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu), ami a háttérben történő munkákat könnyíti meg. Ezzel nem kell vacakolni JobSchedulerrel, Alarmokkal Firebase JobDispatcherrel. Az előadás alapján egész jónak tűnik, a munkákat akár össze is láncolhatjuk és egyik kimenete a másik bemenete lehet. Play Service sem kell hozzá, de egyelőre még alfában van.

#### [Navigation](https://www.youtube.com/watch?v=8GCXtCjtg40&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=39&t=0s&ref=blog.fps.hu)

iOS oldalon jártas arcoknak Storyboard jellegű lesz ez funkció. Egy navigation editoron dolgoznak, ahol összekötheted a kis nyilacskákkal melyik képernyőből hova megy a felhasználó. Kódban pár sor és működik. Szerencsére itt az XML olvasható és szerkeszthető nem úgy, mint iOS-en. A WorkManagerhez hasonlóan alfa verzióban érhető még csak el.

#### Paging

Már egy ideje készülőben volt, de végre kijött az 1.0 verzió. Ezzel egy RecycleView-ben lehet nagy listákat lapozással kezelni. Room-mal és Retrofit-tel kompatibilis. A [prezentációban](https://www.youtube.com/watch?v=BE5bsyGGLf4&index=55&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) nagyszerűen elmagyarázzák hogyan hozták létre és milyen lehetőségek vannak.

[Android developer oldal](https://developer.android.com/jetpack/?ref=blog.fps.hu)  
További Jetpack prezentációk:

- [ktx](https://www.youtube.com/watch?v=st1XVfkDWqk&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=44&ref=blog.fps.hu)
- [Architecture components újdonságok](https://www.youtube.com/watch?v=pErTyQpA390&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=21&ref=blog.fps.hu)
- [Fragmentek használatáról, történetéről](https://www.youtube.com/watch?v=WVPH48lUzGY&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=19&ref=blog.fps.hu)

### Build

#### Fordítás

Az elmúlt időszakban több fejlesztés is történt. Például 3.0-ás Android Gradle pluginnal (AGP) jött az aapt2, ami a tudja az incremental resource compilationt. Aki még nem állt át erre, az tegye meg, mert az aapt1-nek hamarosan annyi.  
D8-at is bevezették egy hónapja és az 3.1-es Android Studio-ban ez az alapértelmezett dexer. A dexer feladata alakítani a Java bytekódot Dalvik bytekóddá, hogy futhasson Androidon. Inkrementális és jobban kezeli a debug információkat, míg a DX-ben azok elveszhettek, amivel biztos [találkozott mindenki](https://youtu.be/gGOOkk2y%5FSs?t=13m59s&ref=blog.fps.hu).  
R8 lesz a Proguard-ot leváltó shrinker, ami kiszedi a kódodból a felesleget és optimalizálja. R8 kompatibilis a meglévő Proguard szabályokkal, de gyorsabb, kisebb dex fájlokat eredményez és Kotlin specifikus optimlizálások is kerülnek bele. Tesztelheted az Android Studio 3.1 verziójában is egy Gradle kapcsolóval.

Magyarázat a működésről és a változásokról bővebben [az előadásban](https://www.youtube.com/watch?v=gGOOkk2y%5FSs&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=30&ref=blog.fps.hu).

#### Gradle

A javac és kotlinc támogatják az incremental fordítást, de ha annotation processort használsz ez nincs kihasználva, újra lesz fordítva minden. Az olyan könyvtárak, mint a Butterknife vagy Glide azt használnak, így ez sok fejlesztőt érint.  
Szerencsére a Gradle 4.7 már támogatja ezeket, ami egy lépés előre. Üröm az örömben, hogy a könyvtáraknak fejleszteni kell ehhez.

Ami meglepett, hogy az R fájlok generálása meg fog változni. Ebben vannak a resource id-k. Ezek nem lesznek többé final mezők, azaz kódban például nem lehet többé switch-ben használni őket. Lehetséges, hogy nem is R-nek fogják ezeket az osztályokat hívni. Ezt a változást Android Studio 3.3-ban lehet várni, de lesz eszköz, ami segít migrálni.

Új AGP API és több infó [az előadásban](https://www.youtube.com/watch?v=N5xONyp69eU&index=33&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu).  
[Proguard előadás](https://www.youtube.com/watch?v=x9T5EYE-QWQ&index=52&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) a működéséről és jobb szabályok írásáról.

### Play Console

#### Verziókezelés

Most már lehet több zárt tesztelési csatorna is. Például minden új funkciónak külön létrehozhatsz egyet. Ezen kívül ugyebár az elmúlt hónapban a perceken belül megjelenő belső tesztelést is bevezették.  
Ezt megtámogatják az API oldalról a vázlat (draft) létrehozásának lehetőségével. Tehát első lépésként egy CI szerverrel előkészítheted kiadásra az applikációt, majd pedig te magad manuálisan kiengedheted, ha minden rendben van.  
[Az előadásban](https://www.youtube.com/watch?v=Thp9%5FKVSZ1Y&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=24&ref=blog.fps.hu) a Google appok kiadásának folyamatát is bemutatják.

#### Vitals

Be lehet kapcsolni, hogy küldjenek emailt, ha anomáliák, kiugró értékek történnek. Hozzáadtak egy új mutatót is, ami jelzi hányan utasították vissza az engedély kéréseket.  
Érdemes nézegetni a vitals opciót Play Console-on, mert olyan crasheket is elkaphat, amikor még egy külső lib be sem töltött. Továbbá a Play Store-ban keresésében elfoglalt helyet is befolyásolja, milyen jól fut az alkalmazás.  
[Az előadásban](https://www.youtube.com/watch?v=dx6LBaFqEHU&index=5&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) megtekintheted, milyen eszközökkel keresheted meg ezeket a hibákat.

#### Tesztelés

Kibővítik a pre-launch tesztelést deep link, accessibility és demo loop támogatással. A demo loop a játékfejlesztőknek lehet érdekes, ami tulajdonképpen felvett OpenGL parancsok visszajátszása.  
Több részletet [megtudhatsz a prezentációból](https://www.youtube.com/watch?v=zTy-ur1Wnq4&index=42&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu).

#### Fizetés

Egy új központi helyet mutattak be a Play Store alkalmazásban, ahol a felhasználók kezelhetik a feliratkozásaikat. Jön az új billing library és Google Pay-t kiterjesztik majd hamarosan Magyarországra is.  
A [feliratkozásokról](https://www.youtube.com/watch?v=x1AYelepG6o&index=6&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) és a [Google Pay-ről](https://www.youtube.com/watch?v=YT1JfH71k%5Fk&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=4&ref=blog.fps.hu) szóló előadásokat is érdemes megtekinteni.

#### Kötelező targetSdkVersion

Nem szabad elfelejteni, hogy a 26-os API lesz a kötelező targetSdkVersion új appoknak augusztustól és létezőknek novembertől. A könyebb migráció érdekében erről is tartottak egy [előadást](https://www.youtube.com/watch?v=YyDnYaFtRS0&t=0s&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=62&ref=blog.fps.hu).

### App Bundle

Minél nagyobb az APK mérete, annál kevesebben töltik le az adatlapot meglátogatók közül. Ez a konverziós ráta körülbelül 6MB-onként 1%-kal csökken. A nagyobb app méretek hatalmas sávszélességet és szerverkapacitást is felemésztenek a Google oldaláról, ezért jött elő az [App Bundle](https://g.co/androidappbundle?ref=blog.fps.hu) formátummal. iOS-ben jártas kollégáknak az App Thinning nevű funkció kell, hogy beugorjon, mert ez hasonló.  
A használatához nem kell módosítani a kódot csak ezzel a funkcióval kell elkészíteni az apk-t és feltölteni. A Google szétdarabolja és a megfelelő apk-kat juttatja el a felhasználónak. Ez kiváltja a Gradle-ben használt split apk kódot.

Ide kapcsolódik a Dynamic features. Ennek segítségével csak akkor történik meg egy funkció letöltése, amikor azt el akarja érni a felhasználó az app használata közben. Például ha egy funkciót csak nagyon kevesen használnak, akkor nem kell mindenkinek letöltenie csak annak, aki használni akarja. Ehhez modulárisan szükséges felépíteni az alkalmazást. Egyelőre bétában van ez a lehetőség és jelentkezni kell rá.

A moduláris, instant és dinamikus appokról szóló [előadás vár rád](https://www.youtube.com/watch?list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC¶ms=EAIYATgBYgtsdTNMNkR4VUJSQWgK&v=0raqVydJmNE&mode=NORMAL&ref=blog.fps.hu).

### Android P

Érdemes figyelni a standby buckets-re, ahol gépi tanulás segítségével 4 kategóriába sorolják az appokat, aktívtól kezdve a ritkán használtig. Itt a ritka kategóriára már elég nagy megszorítások várnak, de a töltőn mindenkinek van mindene:

![Standby bucket restrictions](https://blog.fps.hu/content/images/2018/05/standby_restrictions.png)

Egyelőre kérdéses erre mekkora ráhatásuk lesz a gyártóknak.

Biztonsági javítások is történtek. Le lett tiltva a mikrofon, kamera és a szenzorok közvetlen hozzáférése, ha háttérben van az app. Erről és sok biztonsági újításról, mint a kötelező biztonsági patch-ek gyártók számára, nézd meg az ide vágó [előadást](https://www.youtube.com/watch?v=r54roADX2MI&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=47&ref=blog.fps.hu).

Épületen belüli navigáció egy érdekes képesség, ami a megfelelő hardveres támogatással elérhető lesz. A [prezentációban](https://www.youtube.com/watch?v=vywGgSrGODU&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=40&ref=blog.fps.hu) dual frequency GPS telefonokról és működésükről is szó volt. Érdemes megnézni.

Android Runtime(ART)-ban is történtek igen érdekes fejlesztések. Appok futtatásakor a profil készül róluk, ami alapján optimalizálva van később a háttérben. Ezt feltöltik a felhőbe, majd amikor letöltöd az alkalmazást letöltöd vele a profilt is. Így lett a Google Maps első futtatása például 25%-kal gyorsabb. Kerültek be Kotlin specifikus optimalizációk is. A profilozás működéséről és egyéb új optimalizálásokról nézd meg az [előadást](https://www.youtube.com/watch?v=Yi9-BqUxsno&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=7&ref=blog.fps.hu).

### Tesztelés

Egységes API-t készítenek a teszteléshez, amivel mind készüléken és anélkül tesztelheted az appodat.  
Továbbá AS 3.2-ben profiling részt is tovább erősítették egy új résszel, ahol látni mekkora hatással lesz az appod az akkumulátorra. Lehet már kódból vezérelni felvételt és már az app indulását is lehet teljes mértékben mérni.  
[Tesztelés](https://www.youtube.com/watch?v=wYMIadv9iF8&index=28&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) és [profiling](https://www.youtube.com/watch?v=O5V9ZSL0BsM&index=54&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&t=0s&ref=blog.fps.hu) további újdonságairól az előadások.

### Egyéb témák

#### Modern Android Development

Végre elkezdtek több [javaslatot adni](https://www.youtube.com/watch?v=IrMw7MEgADk&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=14&ref=blog.fps.hu), hogyan kell fejleszteni Androidra. Sajnos a hivatalos dokumentációjuk ehhez képest el van maradva. Pár érdekes pont az előadásból:

- A Hierarchy Viewer-t és TraceView-t felváltotta a Studióba beépített Profiler, Layout Inspector
- Dalvikot felváltotta az ART
- Kotlin a javasolt nyelv
- Layoutok közül LinearLayout, FrameLayout oké, ha egyszerű és nincs egymásba ágyazva akkor oké, amúgy ContstraintLayout-ot javasolt használni
- ListView, GridView és Gallery nem javasolt, hanem RecyclerView
- Enum oké, de még mindig mobil készülékekre programozunk
- Support lib Fragmenteket javasolt használni a platformba épített az deprecated
- Single Activity app a javasolt forma
- Lifecycle, ViewModel és LiveData komponenst javasolt használni a képernyőforgatások, életciklusok és adatváltozások kezeléséhez

#### Material

Az appok kezdtek megkülönbözhetetlenek lenni, ezért témázható lett. A [material.io](https://material.io/?ref=blog.fps.hu) honlap is megváltozott, ahol új eszközök és leírások segítik az implementálást. Nagyobb erőfeszítést tesznek arra, hogy meglegyen minden lehetőség a platformokon és ez dokumentálva is legyen megfelelően.

#### Android Things

Internet of Things készülékekre is elérhető az Android és ez elérte az 1.0 verziót. Azokra a készülékekre érdemes elsődlegesen választani, ahol gépi intelligencia szükséges a készülékre. Elég sok prezentáció volt róla:

- [Platform újdonságok](https://www.youtube.com/watch?v=e%5FPI%5FNpb3-U&list=PLWz5rJ2EKKc9Gq6&ref=blog.fps.hu)
- [Tapasztalatok](https://www.youtube.com/watch?v=ffxkzgvn%5F1Q&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=39&ref=blog.fps.hu)
- [Hogyan tervezzünk appot rá](https://www.youtube.com/watch?v=dVtYVjGGYmE&index=26&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)
- [Hogyan tervezzünk boardot neki](https://www.youtube.com/watch?v=cyphkm5XluA&index=29&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)

#### Android GO

1GB vagy kevesebb memóriával rendelkező készülékek. Ez a 2017-ban szállított készülékek 25%-a volt. Elsődleges piac India, de ami meglepő lehet, hogy a második Amerika. Másik érdekes statisztika, hogy a felhasználók a kisebb méretű appot választják akkor is, ha rosszabb az értékelése. A [prezentáció](https://www.youtube.com/watch?v=-g7yxxTpF2o&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=25&ref=blog.fps.hu) arról szólt hogyan optimalizáljunk rá.

#### Slices, App Actions és Assistant támogatás

A [Slice](https://www.youtube.com/watch?v=a7IVH5aNwwc&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=16&ref=blog.fps.hu) egy dinamikus felület, ami megjelenhet például a keresőben. Ha a „wifi” szóra keresel, akkor így meg tud jelenni egy wifi kapcsoló. Template-elhető, tehát nem lehet akárhogyan megjeleníteni, de a te appod is megjelenítheti más alkalmazások Slice-ait.

Az App Action egy deep link az alkalmazásodba. Egy fájlban meg kell mondani, milyen akciókat lehet végrehajtani az alkalmazással. Ennek segítségévvel például, ha kijelöli a felhasználó a *Tankcsapda* szöveget akkor a felugró kontextus menüben előjöhet a lejátszás opció.  
Assistant támogatást is lehet építeni, ahol hanggal is végre lehet ezt hajtani.  
Ezeket a nyáron érkeznek majd valamikor dokumentációval együtt.  
A [Slice](https://www.youtube.com/watch?v=a7IVH5aNwwc&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&index=16&ref=blog.fps.hu) és az [App Actions](https://www.youtube.com/watch?v=v0uYZ4rTOrk&index=45&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) prezentációban mindezt megtekintheted.

#### ConstraintLayout

Nemrég kijött az 1.1 verzió, amiben például rádiusz és szög megadásával is be lehet pozícionálni egy másik elemet. Az [előadásban](https://www.youtube.com/watch?v=ytZteMo4ETk&index=57&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu) a 2.0 verzióba lehetett beletekinteni, amiben mint valami grafikus a visual editorban keyframe animációkat hozhatunk majd létre.

#### További érdekes előadások

- [Hogyan kezeli az alacsony memóriát a rendszer és mit tehetünk mi?](https://www.youtube.com/watch?v=w7K0jio8afM&index=32&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)
- [Render pipeline Androidon](https://youtube.com/watch?list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC¶ms=OAE%253D&v=zdQRIYOST64&mode=NORMAL&ref=blog.fps.hu)
- [Szöveg renderelés](https://www.youtube.com/watch?v=x-FcOX6ErdI&index=36&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)
- [Snapchat hogyan csinált kamera appot](https://www.youtube.com/watch?v=d1gLZCSLmaA&index=50&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)
- [ChromeOS-en Android Studio](https://www.youtube.com/watch?v=6kIZ%5Fu4QE9U&index=43&list=PLWz5rJ2EKKc9Gq6FEnSXClhYkWAStbwlC&ref=blog.fps.hu)
### Pszichológia? Pszichológia!
URL: https://blog.fps.hu/ux-pszichologia-konyvajanlo/
Last updated: 2026-07-17T08:24:46.000Z
Ez egy könyvajánló blogbejegyzés.

Egy hónapja szembe jött velem David C. Evans [Bottlenecks: Aligning UX Design with User Psychology](https://www.amazon.com/Bottlenecks-Aligning-Design-User-Psychology-ebook/dp/B06W2J32CK/ref=mt%5Fkindle?%5Fencoding=UTF8&me=&ref=blog.fps.hu) (Szűk keresztmetszet: A UX Design és a felhasználói pszichológia összehangolása) című könyve.

Nem ez az első dizájnerek számára írt pszichológiával foglalkozó könyv. Sok remekmű között ott van a listán egyik nagy kedvencem, Susan Weinschenk [100 dolog, amit minden tervezőnek tudnia kell az emberekről](https://bookline.hu/product/home.action?%5Fv=%5F&id=107999&type=22&gclid=CjwKCAjwopTYBRAzEiwAnU4kb4wEjoowcJElZgOT9Rl6tbQodDAEbaEBND-HeLd1wbOd5lzlWlt7JxoC3LsQAvD%5FBwE&ref=blog.fps.hu) című fantasztikus könyve, Daniel Kahneman [Gyors és Lassú Gondolkodás](https://hvgkonyvek.hu/konyv/gyors-es-lassu-gondolkodas?ref=blog.fps.hu) című tudományos igényességű könyve, vagy a méltán megkerülhetetlen, örök klasszikus, [The design of everyday things](https://www.amazon.com/Design-Everyday-Things-Revised-Expanded-ebook/dp/B06XCCZJ4L/ref=sr%5F1%5F1?ie=UTF8&qid=1527086206&sr=8-1&keywords=the+design+of+everyday+things&ref=blog.fps.hu) Donald Normantől. Nálam erre az illusztris listára be tudott bekerülni Evans könyve is. Mondom miért.

Soha nem tagadtam, hogy a pszichológiai ismereteket tartom egy UX-es számára az egyik leghasznosabb kompetenciának. Mindig nagy lelkesedéssel osztottam meg nézeteimet a hallótávolságon belül került ártatlan nézelődőkkel. Sok évvel ezelőtt, amikor a UX hazai gyakorlóinak jelentős része még fejlesztői, marketinges, közgazdász vagy bölcsész háttérrel vágott bele a szakmába, többen is őszintén rácsodálkoztak a véleményemre. Emlékszem, olykor még parázs viták is kialakultak a témáról, mindenki a saját ismeretei, UX-ről alkotott elképzelése alapján védte a véleményét.

Természetesen mindenkinek igaza volt, hiszen a felhasználói élmény rengeteg sok összetevőtől függ. Ki-ki a saját szakterületéhez és meggyőződéséhez mérten tartott fontosnak bizonyos összetevőket, azokat alkalmazták a tervezés során, és végül készítettek remek termékeket.

De Evans mindjárt a könyve elején azt írja, hogy *„ahogy a jó szakácsművészet tudománya a kémia, úgy a jó design tudománya a pszichológia.”* Így minden fentebb említett szakterületből származtatott összetevő a dizájnhoz csak egy eszköz, amit a pszichológia ad a kezünkbe, csak egy alkalmazott réteg, ami a pszichológiára épül.

Ezzel összecseng Donald Norman véleménye is a fentebb említett könyvéből: *„az emberek szükségleteinek megismeréséhez a dizájnernek ismernie kell az emberi viselkedés alapelveit.”*

Jó hír, hogy nem kell beülnünk az iskolapadba, nem kell elvégezni a pszichológia szakot ahhoz, hogy alkalmazzuk a pszichológia alapelveit. Még csak egy gyorstalpaló tanfolyamra sem kell beiratkoznunk. Szerencsére itt van Evans könyve, ami segít eligazodni ebben a tudományban, pont annyira, amennyire nekünk szükségünk van rá.

### Miről szól a könyv?

Evans arra vállalkozott, hogy nem csak a mára számtalan blogbejegyzésben hódító néhány népszerű alapelvet ([Gestalt alapelvek](https://www.interaction-design.org/literature/topics/gestalt-principles?ref=blog.fps.hu), [zsigeri reakciók](https://uxmag.com/articles/how-to-design-for-the-gut?ref=blog.fps.hu), [színek pszichológiája](https://uxplanet.org/how-color-can-effect-emotion-ccab0431b1d?ref=blog.fps.hu), [Hick törvénye](https://en.wikipedia.org/wiki/Hick%27s%5Flaw?ref=blog.fps.hu), csak hogy néhányat említsek) mutat be, hanem egy teljesen az alapoktól induló, szakmailag átfogó képet ad a technológia és pszichológia kereszteződésének területéről. Kezdi az **észlelés**, a **figyelem**, és a **memória** működésével, kitér a **motiváció**ra, a **viselkedés- és fejlődéspszichológia**, valamint a **személyiség- és szociálpszichológia** szerepére a tervezés folyamatában. Minden tárgyalt alapelvet életszerű példákkal mutat be weboldalakon, alkalmazásokon, játékokon vagy fizikai, hardver termékeken keresztül. Teszi ezt ráadásul olvasmányosan, közérthető nyelvezettel.

### Mitől szűk a keresztmetszet?

Így működünk.

Evans egy [mém](https://hu.wikipedia.org/wiki/M%C3%A9m?ref=blog.fps.hu)en keresztül mutatja be, hogy mi és hogyan akadályoz minket abban, hogy felfigyeljünk vagy emlékezzünk a ránk ható ingerekre, azokat megértsük vagy rendszerbe helyezzük.

A teljesség igénye nélkül néhány fejezet…

#### Figyelem

A **figyelmünk fókuszának** szűk keresztmetszetét jól illusztrálja például [Nielsen 2006-ban végzett kísérlete](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content-discovered/?ref=blog.fps.hu), ahol szemmozgáskövető berendezés segítségével vizsgálták meg, hogyan olvasunk a weben.

![F alakú olvasási minta weben](https://blog.fps.hu/content/images/2018/05/f_reading_pattern_eyetracking.jpg)

A kísérlet eredménye a mára jól ismert **F alak** lett (a nagy F betűre hasonlító minta). Az olvasást a bal felső sarokból kezdjük, balról jobbra olvasunk, és soronként haladunk lefele. Egyértelműen látszik, hogy ilyen esetben a képernyő jobb alsó sarka Evans szavaival élve egy figyelmi sivatag, ahova nem érdemes fontos tartalmat tervezni.

#### Memória

A **munkamemória** egyike a memóriánkat alkotó három összetevőnek (szenzoros memória, munkamemória és hosszútávú memória). Szűk keresztmetszetét a tárolókapacitása és tárolás időtartama jelenti, hiszen egyszerre csak néhány „adag” információt tud tárolni (Miller bűvös száma, a [7 +- 2](https://en.wikipedia.org/wiki/The%5FMagical%5FNumber%5FSeven,%5FPlus%5For%5FMinus%5FTwo?ref=blog.fps.hu)), és ismétlés nélkül azt is csak néhány másodpercig.

Ha a munkamemóriánk egy nehezebb, koncentrálást igénylő feladattal van elfoglalva, akkor megtelhet, és új információt nem tud felvenni. Ezt Daniel Simons pszichológus és társa egy nagyon egyszerű kísérlettel bizonyította. Nem spoilerezem el, nézzétek meg ezt a másfél perces videót:

Elképesztő, ugye? Annyira telítődött a feladattól a munkamemóriád, hogy semmilyen, a feladathoz nem kapcsolható egyéb információ nem kódolódott.

Felhasználóink munkamemóriájának válláról a terhet le tudjuk venni például azzal, ha minél kevesebb információt kell észben tartaniuk. Amit lehet, írjunk ki az oldalra, legyen mindig látható helyen, így [azt nem kell megjegyezni](https://www.nngroup.com/articles/recognition-and-recall/?ref=blog.fps.hu).

A **kódolással** az információt eltároljuk a hosszú távú memóriába, az **előhívással** pedig kinyerjük onnan. A szűk keresztmetszet szinte adja magát mindkét irányból. Meg kell valamit jegyeznem valahogy, majd később, akár sokkal később, amikor szükség van rá, emlékeznem kellene rá.

Evans triviális példája a jelszó. Az a jelszó, amiből jó esetben minden szolgáltatásra különbözőt használunk, és ami technológia-központúság (értsd: biztonsági előírások, vagy ha úgy tetszik nem-ember-központúság) miatt valahogy így néz ki: *H4gyjal\_B3ken!*.

Hogyan jegyzed meg, ha van ilyenből 10, majd hogyan fogod előhívni, ha szükség van rá?

Feladod már az elején, és használod [mások jelszavát](https://en.wikipedia.org/wiki/List%5Fof%5Fthe%5Fmost%5Fcommon%5Fpasswords?ref=blog.fps.hu) :) Ha ennél jobbat szeretnél, akkor ez előhívást meg tudod könnyíteni olyan jelszóval, [ami jelent számodra valamit](https://labs.eleks.com/2014/04/strong-unique-and-memorable-passwords-a-creative-approach.html?ref=blog.fps.hu).

#### Befolyásolás

A **társadalmi befolyás elmélete** szerint akkor leszünk befogadóbbak egy mémre, ha azt legalább hárman ajánlják (több nem kell), akiknek az indítékait önérdek nem csökkenti, és akik a barátaink, vagy az ellenségeink ellenségei.

Solomon Asch pszhichológus egyszerű vizuális feladatokkal operáló [kísérleteiben bemutatta](https://hu.wikipedia.org/wiki/Asch-k%C3%ADs%C3%A9rlet?ref=blog.fps.hu), hogy milyen hatással van a kísérleti személyek válaszaira három, szándékosan rossz választ adó beépített ember. Az eredmény szerint egy vagy két beépített ember rossz válasza nem volt jelentős hatással a kísérleti személy válaszára, de három már akkora befolyással bírt, hogy az alany sok esetben hozzájuk igazította válaszait.

Példa. Ha egy étterem értékelésénél látsz egy vagy két negatív visszajelzést, azt gondolhatod, hogy rossz napja volt a szakácsnak vagy a pincérnek. Három rossz vélemény esetén már meggyőzve érezheted magad, hogy kerüld el a helyet.

### Olvassátok, tetszeni fog!

Ha érdekel, hogy hogyan működik a felhasználód, mit szeret vagy utál, mivel tudod a figyelmét megfogni, lekötni, cselekvésre késztetni, motiválni, vagy mi az, amivel inkább eltántorítod a terméked használatától, akkor neked való ez a könyv.

Végezetül még egy másfél perces videó. Don Normant egyszer megkérdezték, hogy milyen dizájnernek tartja magát. UI, UX, IxD, …? Nem választotta egyiket sem, inkább kitalált magának egy újat: *"Kognitív dizájner"*.

(Borítókép forrása: [fps Behance](https://www.behance.net/gallery/65629145/Company-Value-Kit?ref=blog.fps.hu).)
### LED és audio visszajelzések hardver eszközökön
URL: https://blog.fps.hu/visszajelzesek-hardver-eszkozokon/
Last updated: 2026-07-17T08:24:56.000Z
Nemrég egy IoT projekt keretein belül egy olyan kijelző nélküli hardver eszköz visszajelzésein dolgoztunk, ahol LED-ek és csipogók álltak a rendelkezésünkre. A teljesség igénye nélkül összegyűjtöm, hogy milyen eszköztár állt a rendelkezésünkre, és milyen szempontok merültek fel a tervezés során.

### A visszajelzések fontossága

A természet és egyes mesterséges eszközök folyamatos visszajelzéseket küldenek, amiből (sok esetben már tudat alatt) következtetéseket tudunk levonni. Pl.: egy ablakon kitekintve a meghajló ágakból sejthető, hogy fúj a szél vagy éppen a vízforraló bugyborékoló hangjából már a szomszéd szobában tudni, hogy felforrt a víz. Viszont mi van abban az esetben, ha egyes folyamatokat nem olyan egyszerű lekövetni?

A megfelelő visszajelzések elengedhetetlen részei egy rendszer kiszámítható működtetéséhez. Ha a felhasználó megnyom egy gombot, hogy elindítson egy folyamatot, akkor visszajelzést kell kapnia, hogy a gomb megnyomása sikeres volt, a folyamat elkezdődött és éppen folyamatban van, továbbá arról is, ha befejeződött. Ennek hiányában az eszköz kezelése bizonytalan vagy egyes esetekben lehetetlen.

#### A kevesebb több

Hogy az eszköz kezelése a lehető legátláthatóbb legyen, célszerű az egyszerűségre törekedni. Fel kell tenni azt a kérdést: valóban szükség van arra a visszajelzésre a használat során? Fontos a megfelelő arány. A felhasználó elárasztása irreleváns információkkal olyan átláthatatlan helyzetet teremt, ami hátráltathatja a produktivitásában.

A visszajelzések esetében a kevesebb több elvének kell érvényesülnie. A [The Laws of Simplicity](http://lawsofsimplicity.com/?ref=blog.fps.hu) könyvben bemutatott SHE (Shrink, Hide, Embody) módszer jól alkalmazható ebben az esetben. A visszajelzések intenzitását és mennyiségét az éppen szükséges szintre kell csökkenteni (Shrink). Ehhez meg kell vizsgálni, hogy az adott visszajelzés valóban elengedhetetlen része a rendszer működtetéséhez. A nem szükséges folyamatokat szerencsésebb elrejteni a felhasználó elől (Hide), hogy a használathoz kevesebb dolgot kelljen átlátnia és kezelnie.

- **Csökkentés:** visszajelzések számának minimalizálása a szükséges szintig
- **Csökkentés:** intenzitás és hangerő csökkentése a szükséges szintig
- **Rejtés:** az eszköz kezeléséhez szükségtelen háttérfolyamatok rejtve tartása

### Fény- és hangjelzések

Számos esetben hozzászoktunk, hogy az eszköz (pl.: okostelefon, laptop) egy kijelzőn komplex vizuális visszajelzéseket ad. Ha csak minimális számú és folyton visszatérő jelzésekkel dolgozunk, akkor azt egyszerű LED-ekkel és hangjelzőkkel is megoldhatjuk. Így javítható az átláthatóság, csökkenthetők az alkatrészköltségek, és nem kell digitális felületet készíteni.

#### Fényjelzések

A fényjelzések ideálisak minimális darabszámú visszajelzések esetén, vagy ha egy jelzés frekventáltan visszatérő jellegű. Ilyen pl.: a TV készenléti LED-je, vagy a kis LED a billentyűzeten, ami a caps lock ki- és bekapcsolt állapotát jelöli.

![caps-lock](https://blog.fps.hu/content/images/2018/04/caps-lock.png)  
*Egy minimális jelzés is sokat segíthet*

Ahogy egy laptopon is, LED-ekkel kiegészíthető egy kijelző működése is, ha a folyamatosan felmerülő rendszer visszajelzések (pl.: on/off gomb, töltést vagy processzor működését jelző LED). Emellett a legtöbb esetben egymagában is megállja a helyét pl.: mozgásérzékelőn felgyulladó piros LED, ha valaki a látóterébe sétált.

A fényjelzések egymagukban kevés információt hordoznak, így mindig kell melléjük egy kiegészítő információ, hogy minek az állapotát jelzi a fény. A kiegészítés lehet ikon, szöveg, szín, darabszám vagy egy adott alkatrész. Ilyen pl.: az autók többségének világító műszerfal ikonjai, ahol az ikon a jelentéshordozó a LED pedig az állapotjelző.

A fehér, sárga, piros és zöld bevált színek a jelzések terén.

- **Fehér:** általános állapotjelző
- **Piros:** egymagában általános állapotjelző, zölddel párosítva tiltást vagy hibára utalhat
- **Zöld:** siker vagy engedély megadása
- **Sárga:** veszélyre való felhívás

#### Hangjelzések

Figyelmünk kifejezetten jól reagál a hangokra, így a hangjelzések kiválóak a figyelem felkeltésére. Mivel ennyire jól reagálunk rá érdemes minimalizálni a használatukat, ugyanis egy elhanyagolhatónak tűnő jelzés is hosszú távon frusztrációhoz vezethet.

- Kitűnő kiegészítés multitasking során, vagy amikor a kezelőfelület kiesik a figyelmünk fókuszából. Ilyen pl.: a GPS hang alapú navigációja vagy az autó tolatóradarja, amikor a figyelmünk az úton van és nem szeretnénk folyamatosan a kijelzőre tekinteni.
- A természetes hangjelzés hiányában pótolja azt. Számos játék alkalmaz olyan hangefektusokat, ami a digitális környezetben utánozza a fizikai tárgy hangját, így vezetve rá a játékost a megoldásra. Hasonlóan pl.: egy funkció feloldásakor egy retesz hangjának bejátszása.
- Segít kialakítani egy hangulatot és könnyebben megkülönböztethetővé teszi a terméket a piacon. (pl.: már az iroda végéből megmondható, hogy valaki egy Skype vagy Slack üzenetet kapott)
- Megszemélyesíti magát az eszközt. Sokkal személyszerűbbnek tekintünk egy olyan eszközt, ami hang alapú visszajelzést is küld. A megszemélyesítést segíti, ha a szabályos gépi hangok helyett organikusabb „earcont” (egy eseményhez fűződő hangjelzést) használunk. (pl.: a Skype sóhajtása a kikapcsolás pillanatában)

### Kontextus

Az eszközt minden esetben egy kontextusban fogják használni, így a jelzéseit is ennek megfelelően kell átgondolni.

![kontextus-2](https://blog.fps.hu/content/images/2018/04/kontextus-2.png)

**Környezeti fényerő**  
LED jelzések esetén figyelni kell arra, hogy milyen fényviszonyú környezetben kell teljesítenie. (pl.: egy közúti jelzőlámpának nappali és esti fényviszonyok között is jól láthatónak kell lennie, ezért a nappali üzemhez árnyékolókkal vannak ellátva)

**Környezeti zaj**  
Hangjelzéseknél a környezeti zaj szintjét érdemes figyelni. Figyelmünk igen érzékeny a hanghatásokra így gyorsan felfigyelünk a hangjelzésekre. (pl.: egy telefon csörgése a metrón vagy egy csendes tárgyalóteremben)

**Kezelőfelület zsúfoltsága, vizuális zaj**  
LED-ek esetén nem mindegy, hogy az adott jelzés egymagában áll vagy egy sűrű irányítópultra kell beépíteni. Zsúfolt felületen a jelzők csoportosításával és elkülönítésével javíthatunk az átláthatóságon. Példaként vehető egy vízparti viharjelző is, amit ha a vízből nézünk, a város fényei mellett kell érvényesülnie.

![viharjelzo](https://blog.fps.hu/content/images/2018/04/viharjelzo.png)  
*Fényár, ahol egy viharjelzőnek érvényesülnie kell. Fotó: Fonyód [http://mapio.net/pic/p-21053782/](http://mapio.net/pic/p-21053782/?ref=blog.fps.hu)*

**Ember és a gép távolsága**  
A távolság növelésével a fény és hangjelzések intenzitása csökken. Így test közvetlen közelében használt eszközök (pl.: laptop, karóra) minimális, a pár méteres környezetében lévők (pl.: mozgásérzékelő, TV) kisebb, míg a távolabbiak (pl.: balatoni viharjelző lámpa) nagyobb intenzitású jelzést igényelnek.

**Emberi tényező**  
Érzékszervek állapotától függően változik a jelek észlelésének képessége. Ez lehet életkor során kialakuló, balesetből adódó vagy veleszületett adottság. Változó igények léphetnek fel továbbá a kezdő, haladó és profi felhasználók között is. Így a visszajelzések tervezésénél ismerni kell a felhasználókat.

Ha olyan eszközt tervezünk, mely több kontextusban is használatban lesz, akkor ha van rá lehetőség célszerű szenzorokkal követni a környezeti tényezőket vagy manuálisan beállíthatóvá tenni a visszajelzéseket. Pl.: fényerő automatikus csökkentése sötét környezetben, beállítható erősségű hangjelzés vagy kikapcsolható figyelmeztetés.

### Intenzitás

A kontextusokat figyelembe véve a jelzések intezitása a következőképpen alakítható ki: nem adunk jelzést, indikálunk, figyelmeztetünk, riasztunk.

![intensity_4A-1](https://blog.fps.hu/content/images/2018/04/intensity_4A-1.png)

**Jelzés elhagyása**  
A felhasználók és üzemeltetők számára nem releváns folyamatokat és eseményeket célszerű rejtve hagyni.

**Indikálás**  
Alacsony intenzitású. Egy indikátor célja, hogy csak akkor legyen jelen, hogy ha indikál valamit, ha nem, akkor ne legyen jelen. Mondta Johnatan Ive, mikor [bemutatta](https://www.youtube.com/watch?v=YdVG4LcoY4Y/&ref=blog.fps.hu) a MacBook egyik készenlét jelző LED-jét. Az indikátoroknál cél, hogy úgy jelöljenek egy értéket, hogy az ne zökkentse ki a felhasználót a használati flowból, viszont legyen jelen, ha arra kerül a sor. (pl.: caps lock bekapcsolva, kikapcsolva; bekapcsolás gomb)

**Figyelmeztetés**  
Közepes intenzitású. Úgy kell kialakítani, hogy felkeltse a felhasználó figyelmét, de ne legyen harsány. Mivel a figyelem jobban reagál a mozgásra és a hangokra így ebben az esetben jól működnek a hangjelzések és villogó fényjelzések. Fontos, hogy ne vigyük túlzásba a használatát. (pl.: ATM a bankkártya kiadásakor egy villogó LED és szaggatott hangjelzés figyelmeztet, hogy biztosan ne felejtsük ott a kártyánkat.)

**Riasztás**  
Magas intenzitású. Cél, hogy a személy azonnal felhagyjon az éppen végzett tevékenységével és teljes mértékben a riasztás okának megoldásával foglalkozzon. Az intenzitásnak olyan nagynak kell lennie, hogy minden környezetben egyértelműen észrevehető legyen. A jelzés hosszánál viszont figyelembe kell venni, hogy az erős jelzés hátráltathat a problémára fókuszálásban és így a mihamarabbi megoldásában. Ez okból kikapcsolhatónak kell lennie.

### Idő tényező

Az intenzitás mellett fontos a jelzés hossza is. Egy hosszú ideig tartó alacsony intenzitású jelzés frusztráló, egy hosszú intenzív hanghatás elviselhetetlen, egy rövid, de váratlan intenzív jel pedig riasztó tud lenni. A [WCAG 2.0 ajánlásai](https://www.w3.org/TR/2008/REC-WCAG20-20081211/?ref=blog.fps.hu#visual-audio-contrast-dis-audio/) alapján, ha egy hangjelzés magától elindul és több, mint 3 mp-ig tart, akkor célszerű kikapcsolhatóra tervezni.

Az idő tényező a jelzés érzékelésében is szerepet játszik. Folyamatos jelzéssel folyamatosságot, a villogó jelzés felkelthetjük a figyelmet vagy veszélyt jelezhetünk, a jeledási frekvencia növelésével és csökkentésével pedig közelítő mértéket adhatunk meg. (pl.: tolatóradar a mögöttünk lévő falhoz közelítve)

### Összegezve

A természet és egyes eszközök folyamatai során olyan természetes visszajelzések érkeznek, ami alapján következtetni tudunk a folyamat állapotára. Vannak esetek, amikor ez nem lehetséges és mesterséges visszajelzésekre van szükség. Ez történhet LED és audio visszajelzésekkel is, melyek alkalmasak a kijelző kiegészítésére vagy kiváltására, ha minimális számú visszajelzéssel dolgozunk. A visszajelzések elengedhetetlenek egy rendszer működtetéséhez viszont a tervezésüknél a kevesebb több elve kell, hogy érvényesüljön. Ügyelni kell arra, hogy az eszközt milyen célcsoportok milyen kontextusban fogják használni és ennek megfelelő formájú és intenzitású jelzést kell küldeni. A sikeresen megtervezett visszajelzések úgy segítik a felhasználót, hogy közben nem zökkentik ki a használati flowból. Kivéve természetesen, ha éppen egy tűzjelzőn dolgozunk.
### Játékfejlesztés a múlt században
URL: https://blog.fps.hu/fejlesztes-a-mult-szazadban/
Last updated: 2026-07-17T08:25:06.000Z
2017\. tavaszán láttam a [Vakondok 4 - végigjátszás](https://vakondok4.hu/?ref=blog.fps.hu) című dokumentumfilmet, ami azonnal felkeltette az érdeklődésem a téma iránt, arról nem is beszélve, hogy én is részese voltam a Commodore korszaknak. A film amellett, hogy szórakoztató, rengeteg érdekes és tanulságos sztorit tartalmaz.

### Magyarok

A Vakondok 4 kifejezetten a magyar játékfejlesztés történetéből szemezget és szerencsére van is miből. Kishazánk hatalmas eredményeket mutatott fel a 80-as évek végén és gyakorlatilag az ipar egyik meghatározó szereplője lett, leginkább a Novotrade munkássága által. (A miskolci iroda mellett pár méterre még mindig található egy). Van fpses vonatkozása is ennek az időszaknak, ugyanis [kolboid](http://plus4world.powweb.com/members/CSM?ref=blog.fps.hu) aktív résztvevője volt a demoscene-eknek.

Nem csak a véletlen műve, hogy a magyarok kiemelkedtek a többi ország fejlesztői közül.

- Számos tényező közrejátszott a siker okaként, de talán az egyik kiemelkedő az, hogy Magyarországon gyakorlatilag elméleti matematikusokból és villamosmérnökökből álltak a játékfejlesztő csapatok. Elég csak [Mérő László](https://hu.wikipedia.org/wiki/M%C3%A9r%C5%91%5FL%C3%A1szl%C3%B3?ref=blog.fps.hu), méltán híres matematikusra és pszichológusra gondolni, akinek többek között a [Buffalo Roundupot](https://hungame.blog/2017/06/30/buffalo-roundup/?ref=blog.fps.hu) köszönhetjük.
- A magyarok találékonysága itt is visszaköszönt. A Nintendo akkoriban zárt rendszerként kezelte a saját eszközeit és nem adtak csak úgy fejlesztői dokumentációt bárkinek. A Novotrade-esek viszont pár hónap alatt megcsinálták a saját fejlesztőkörnyezetüket, ami igen csak meglepte a japánokat, sőt a világon is híre ment és fellendítette a megkeresések számát.
- Természetesen nem szabad megfeledkezni [Stein Róbert](http://iddqd.blog.hu/2016/02/08/a%5Fmagyar%5Faki%5Fmegismertette%5Fa%5Ftetrist%5Fa%5Fkapitalizmussal?ref=blog.fps.hu) nevéről sem, aki megalapozta a külföldi kapcsolatokat. Elég menő lehetett magyar fejlesztőként kezedben tartani a *S00000002* szériaszámú C64-est, amit ő intézett.

### Azok a régi szép idők…

![c64_impossiblemission](https://blog.fps.hu/content/images/2018/05/c64_impossiblemission.jpg)

Nézve és hallgatva a régi sztorikat, egyszerre fog el tisztelet és valamiféle gyermeki csodálat. A kilencvenes évek elején szájtátva játszottunk a [Last Ninja](https://en.wikipedia.org/wiki/The%5FLast%5FNinja?ref=blog.fps.hu) vagy az [Impossible Mission](http://iddqd.blog.hu/2010/05/19/szerdai%5Fretro%5Fimpossible%5Fmission%5Fi%5Fii?ref=blog.fps.hu) játékokkal, és közben nem is gondoltuk, hogy magyarok keze is benne van a dologban. Úttörőként kezdtek bele egy teljesen új dologba, aminek csak az alapjai körvonalazódtak, hiszen a többi nagy játékfejlesztő cég is abban az időben alakult.

- A játékok műfajai épp csak kezdtek kialakulni, mindenki próbálkozott, kísérletezgetett. Magyarországon is meghirdetett pályázat útján próbáltak ötleteket gyűjteni, hogy milyen játékot csináljanak. Érdekes eltérés volt viszont a világ többi részéhez képest, hogy míg mindenki „lövöldözős” játékban gondolkodott, a magyarok (kezdetben) törekedtek az erőszakmentességre és a kreatív megoldásokra.
- Adott pár pesti sokdiplomás, pályaelhagyó-pályakezdő, akik rendkívül jó fejlesztők, viszont nem igazán érték el őket a külföldi trendek. Viszont, közlik velük, hogy márpedig most egy [golfjátékot](https://soundcloud.com/st-ki/checkpoint-2x10-a-magyar-jatekfejlesztes-a-szocializmusban?ref=blog.fps.hu#t=40:00) kell írniuk. Oké, de mi az a golf és mik a szabályai? Kaptak néhány VHS kazettát külföldről, amikre alapozniuk kellett minden tudásukat.
- Utólagos hibajavítások, patchek kiadására nem volt lehetőség. Ha egyszer kiadta a fejlesztő ([vagy kidobta utolsó pillanatban a harmadikról](https://soundcloud.com/st-ki/checkpoint-2x10-a-magyar-jatekfejlesztes-a-szocializmusban?ref=blog.fps.hu#t=52:00)) a master-példányt, onnantól kezdve az már elkészült, sok-sok példányban került terjesztésre.
- A magyar fejlesztőcsapat sok esetben nem új játékot írt, hanem csak portolt. Viszont nem az átírandó játék forráskódjával dolgoztak, hanem konkrétan megkapták a játéktermi gépet, amihez iskolásokat kellett foglalkoztatni, hogy játsszák végig és mutassák meg a fejlesztőknek, mikor mi történik. …Én meg mehettem fiatalkoromban gyülömcsöt szedni… :(

### Érdekel a téma?

![c64_jani](https://blog.fps.hu/content/images/2018/05/c64_jani.jpg)

A filmet leszámítva, elég erős magyar tartalom áll rendelkezésre a témában.  
Megkerülhetetlen az [IDDQD](http://iddqd.blog.hu/?ref=blog.fps.hu) retrójáték blog, amihez egy rendkívül szórakoztató [Checkpoint](https://soundcloud.com/st-ki?ref=blog.fps.hu) podcast is tartozik. Tóth Krisztián áldásos tevékenységének köszönhetően pedig [weben élvezhetjük](http://c64.krissz.hu/jatek-atiratok-webre/?ref=blog.fps.hu) a régi klasszikusokat. Ugyanakkor vannak még [elvault arcok](http://csdb.dk/scener/?id=28167&ref=blog.fps.hu), akik ragaszkodnak a Commodore világához, így jönnek létre még 2010 után is [játékok](http://csdb.dk/release/?id=144193&ref=blog.fps.hu) és demók.

A témához kapcsolódó érdekes podcastok, amiket mindenképp ajánlok:

- [Checkpoint 3x12 - A robotika kezdetei Magyarországon](https://soundcloud.com/st-ki/checkpoint-3x12-a-robotika-kezdetei-magyarorszagon?ref=blog.fps.hu)
- [Checkpoint 3x07 - Mérő László játékai](https://soundcloud.com/st-ki/checkpoint-3x07-mero-laszlo-jatekai?ref=blog.fps.hu)
- [Checkpoint 2x15 - A magyar játékfejlesztés a szocializmusban II.](https://soundcloud.com/st-ki/checkpoint-2x15-a-magyar-jatekfejlesztes-a-szocializmusban-ii?ref=blog.fps.hu)
- [Checkpoint 2x10 - A magyar játékfejlesztés a szocializmusban](https://soundcloud.com/st-ki/checkpoint-2x10-a-magyar-jatekfejlesztes-a-szocializmusban?ref=blog.fps.hu)
- [Checkpoint 2x08 - Ecco és Novotrade](https://soundcloud.com/st-ki/checkpoint-2x08-ecco-es-novotrade?ref=blog.fps.hu)
- [Checkpoint 2x02 - Dokumentumfilm a magyar játékfejlesztésről](https://soundcloud.com/st-ki/checkpoint-2x01-dokumentumfilm-a-magyar-jatekfejlesztesrol?ref=blog.fps.hu)
- [Checkpoint 2x01 - A magyar játékfejlesztés gyökerei](https://soundcloud.com/st-ki/checkpoint-2x01-a-magyar-jatekfejlesztes-gyokerei?ref=blog.fps.hu)
- [Checkpoint 1x14 - A magyar játékfejlesztés kezdetei](https://soundcloud.com/st-ki/checkpoint-1x14-a-magyar-jatekfejlesztes-kezdetei?ref=blog.fps.hu)
### A „Betört ablak” elv
URL: https://blog.fps.hu/betort-ablak-elv/
Last updated: 2026-07-17T08:25:16.000Z
Létezik egy érdekes krimonológiai elmélet, amelyet szoftverfejlesztőként is érdemes ismerni, mert megmagyarázza, hogyan lesznek az eredetileg szépen megírt kódokból vállalhatatlan spagettik, és hogyan válnak a szerelemprojektnek induló munkák „support rémálommá”.

A „Betört ablak” elvet a nyolcvanas évek végén dolgozták ki amerikai kriminológusok, akik megfigyelték, hogy ha egy környéken betörnek egy ablakot és nem javítják meg rövid időn belül, az elhanyagoltság szelleme terjedni kezd és előbb-utóbb egyre több ablak fog betörni arrafelé. Ugyanígy rossz hatással van a környékre egy összefirkált fal, az eldobált szemét és minden, amiből az elhanyagoltság hangulata árad. Az ilyen környéket az emberek még jobban elhanyagolják, ez az ördögi kör pedig egyenes úton vezet a romló közbiztonsághoz, az elharapódzó bűnözéshez.

Az elmélet visszafelé is működik: ha felaszámoljuk a rendetlenséget, csökken a bűnözés. Több esettanulmány is igazolja az elmélet működését.

### Törött ablakok és tiszta kódok

A kódban a hibás döntések, a gyenge kódminőség, a hiányzó vagy rossz tervezés jelentik a problémát. Ha olyan projekten dolgozol, amely ilyen technikai adósságokkal terhelt, főleg, ha gyorsan kell megoldás, te is könnyebben követsz el benne hasonlókat, mert úgy érzed, nem az az egy kis csúnyaság fogja tönkretenni a már egyébként is egyre nehezebben karbantartható projektet.

De nem csak most gondolkozol így, hanem a következő módosításkor is, és nem csak te, hanem az egész csapat. Tisztában vagy vele, hogy az egész kódbázis egy alapos refaktorálásért kiált, de egyre rosszabb még belegondolni is, hogy ezt valamikor el kell kezdeni.

**Ne hagyj tehát törött ablakokat a kódodban**, mert hiába nem tűnik önmagában nagy problémának egy-egy kevésbé elegáns kódsor, könnyen elindulhat a projekt a fenntarthatatlanul rossz kódminőséghez vezető úton. A valóságban persze tudom, előfordul, hogy nincs idő a tiszta megoldás azonnali megvalósítására, de ilyen esetekben is mindig törekedni kell a technikai adósságok mihamarabbi rendezésére.
### Mobilbarát API
URL: https://blog.fps.hu/mobilbarat-api/
Last updated: 2026-07-17T08:25:26.000Z
Ennek az írásnak a célja, hogy a backend fejlesztő kollégák kicsit jobban ráláthassanak a mobil fejlesztők igényeire, valamint problémáira, amik egy közös munka során felmerülhetnek. Vaszil Ádám csapattársam egy [régebbi posztjában](https://blog.fps.hu/android-halozat/) pár pontban már érintőlegesen foglalkozott a backend felé támasztott alapvetőbb mobil fejlesztői igényekkel. Én most bővítem a listát, illetve kicsit részletezem is a felmerülő igényeket, problémákat.

### Dokumentáció

Ha egy új API-val kezdünk dolgozni, akkor az első dolog, amivel ezzel kapcsolatban találkozunk, annak dokumentációja. Sajnos már ekkor is több problémával szembesülhetünk. Természetesen ezek a közös munka során, a fejlesztés közben is megjelenhetnek.

#### Hiányos

A legtöbbször előforduló probléma, hogy hiányos a dokumentáció. Az ugyanezen API-t használó weboldalon (mellesleg általában itt kezdődnek a bajok), esetleg már létező, lecserélni kívánt mobil alkalmazásban látjuk, hogy működik a funkció, viszont a dokumentáció nem tartalmazza a hozzá tartozó hívást. Felmerülhet benned kedves olvasó, hogy ilyen esetben azért vissza lehet fejteni a hívásokat a megfelelő eszközökkel és ez így is van. Viszont nem a mobil fejlesztő dolga ezzel bíbelődni. Hívhatjuk lustaságnak, üzleti érdeknek stb., a hiánytalan dokumentáció minden szereplő érdeke. Az ok általában, hogy a fejlesztő siet, az új funkciókat már várják, levélben, vagy chaten egyeztetett a frontendes kollégával, majd a módosítás kimarad a dokumentációból.

#### Elavult

A dokumentáció elavultsága is rendszeresen felmerülő probléma. A funkció létezik, a felületes olvasó látja, hogy a doksiban is benne van, majd használatkor szembesül vele a fejlesztő, hogy nem a leírtaknak megfelelően működik. Természetesen ekkor meg lehet keresni a backendes kollégát és egyeztetni, hogy mi a probléma, ki lehet javítani a dokumentációt, majd mentegetőzni az ügyfélnél, hogy miért csúszik a fejlesztés. Persze ez egy kicsit túlzó megfogalmazás és a csúszásoknak általában nem csak ez az oka, de nem baj, ha a fejlesztési időbe beleszámítjátok a fejlesztők közti „felesleges” kommunikációt. Lesz.

### Verziózás

Mobil applikáció fejlesztésénél tekintettel kell lennünk arra a tényre, hogy a felhasználók egy része nem frissíti rendszeresen az applikációkat. Ez lehet az operációs rendszer gyári beállításai miatt – tehát napokig nincs wifi hálózatra, esetleg töltőre csatlakozva –, vagy maga a felhasználó kapcsolja ki az automatikus frissítés funkciót. Hogy konkrét számokról is beszéljünk, az egyik applikációnk statisztikái alapján, az első 2 napban az Androidos felhasználók fele frissít, majd a következő két hétben is csupán 85 százalékig jut el a frissítések száma. Nagyjából a felhasználók 10 százaléka le van maradva két verzióval.

Ebből belátható, hogy miért rossz ötlet az éles API-ban olyan módosításokat végezni, ami jobb esetben csak használhatatlanná tesz bizonyos funkciókat az előző verziós appokban, rosszabb esetben pedig összeomlik tőle az alkalmazás. Az ilyen problémák elkerülhetők a verziózott API-val. Hogy ez hogyan oldják meg, az szinte teljesen lényegtelen. A lényeg, hogy legyen verziózás.

### Hibakezelés

Nem kell nagy varázslatra gondolni. Három dologra van szükségünk, egy értelmesen megfogalmazott, az alkalmazás nyelvével megegyező nyelvű hibaüzenetre, amit a felhasználó elé lehet tenni szégyenkezés nélkül, egy státuszra, hogy van-e hiba, illetve egy hibakódra. Ez utóbbira azért van szükség, hogy a kliens oldalon adott esetben a megfelelő eseményeket ki tudjuk váltani, hisz nem minden hibát kell egyformán kezelni, illetve megjeleníteni. Házon belül természetesen ezt megkapjuk a saját fejlesztőinktől. Több hiba esetén ezek mehetnek egy JSON tömbbe.

**Milyen hibákat lehet elkövetni?**

#### Idegen és magyar nyelvű hibaüzenetek keveredése

Mivel a hibaüzenetek egy részét muszáj megjeleníteni a felhasználónak, elég kellemetlen, amikor bizonyos hibaüzenetek mondjuk angolul jelennek meg, míg az alkalmazás és az üzenetek nagy része magyar.

#### Magyar nyelvű, de magyartalanul megfogalmazott hibaüzenetek

Többször futottam már olyan hibaüzenetekbe, amit egyszerűen kínos lett volna megjeleníteni a felhasználónak. A megoldás a kliens oldali validálás és végső esetben valami általános, de értelmes hibaüzenet.

#### Több hiba egy üzenetbe való összefűzése

Ugyancsak a szervertől kapott szöveg megjelenítésekor problémás, főleg ha az előző pontban tárgyalt gonddal párosul.

#### Hibakód hiánya

Nem megoldhatatlan probléma, de sokat könnyít a dolgunkon a megléte.

#### Hibajelzés teljes hiánya

Nem egyszer fordult már elő, hogy a hibajelzés abban merült ki, hogy üres válasz jön. Sajnos ilyen is van.

#### Státusz hiánya

Ez még nem vészes, de azért jobb, ha van. Nyilván a hibaüzenet meglétéből, vagy hiányából és a tartalom meglétéből, vagy hiányából lehet következtetni a sikerességre, de azért könnyebb és kevésbé erőforrás igényes egy boolean-t ellenőrizni és aszerint folytatni a feldolgozást.

### Paraméterezés

Ami igazából a paraméterekkel kapcsolatban problémát okoz, ha változik a paraméter neve, tartalmaz dinamikus elemeket, mondjuk id-t.

Az alábbi formátumot egy post hívás paramétereként láttam:

user\[192834756\]\[firstname\]: Jason

Itt a cél az lenne, hogy a "192834756" id-val rendelkező user "firstname" paraméterét beállítsuk "Jason"-re.

Ezt a formátumot elég szívás bármilyen olyan framework-kel használni, ami nem sima String típusú kulcs-érték párokra épül, hanem esetleg kihasznál olyan nyelvi szinten adott lehetőségeket, mint Javaban az annotációk. Ott bizony a paraméter neve statikus és a dinamikus paraméter nevek kezelése okoz némi fejtörést.

### XML helyett JSON

#### Méret

A JSON formátum egyik legnagyobb előnye, hogy ugyanazt az adatot kisebb helyen tárolja. Ennek alapvető oka az, hogy a tag-ek helyett, csak egy-egy karaktert használ.

JSON (188 karakter):

```javascript
{
	"addresses":[  
    	{
        	"street": "Hős utca 9",
        	"zip": "1870",
        	"city": "Budapest"
    	},
     	{
        	"street": "Futó utca 37-45",
        	"zip": "1870",
        	"city": "Budapest"
    	},
     	{
        	"street": "Kerepesi út 9",
        	"zip": "1870",
        	"city": "Budapest"
    	}]
}

```

Ugyan ez XML-ben (306 karakter):

```xml
<?xml version="1.0" encoding="UTF-8" ?>
<root>
    <address>
   	 <street>Hős utca 9</street>
   	 <zip>1870</zip>
   	 <city>Budapest</city>
    </address>
    <address>
   	 <street>Futó utca 37-45</street>
   	 <zip>1870</zip>
   	 <city>Budapest</city>
    </address>
    <address>
   	 <street>Kerepesi út 9</street>
   	 <zip>1870</zip>
   	 <city>Budapest</city>
    </address>
</root>

```

Jól látható, hogy ebben az esetben az XML több mint 50 százalékkal több helyet foglal. Mobil adatkapcsolat esetén, hosszú távon ez sem elhanyagolható tényező.

#### Sebesség

Nincs túl sok naprakész cikk a témában, de egy 2014-es összehasonlításban az jött ki, hogy bár [a JSON file-ok írási sebessége nem sokban különbözik az XML-től, az olvasásuk meglehetősen gyorsabb](https://tuhrig.de/jaxb-vs-gson-and-jackson/?ref=blog.fps.hu).

#### Használat

Bár ez rajtunk kívül valószínűleg senkit nem érdekel, de az API-val való kommunikációra általunk használt library-ben egyszerűen kevesebb munka létrehozni a parsoláshoz az osztályokat JSON esetén.

### JSON, de nem mindegy milyen

Attól, hogy JSON formátumban kapjuk a hívás kimenetét, az még lehet számunkra nehezen használható. A következő pontokban azt fogom összeszedni, hogy milyen gyakori hibákkal találkoztam már, ami megkeseríti egy mobil app fejlesztő életét. Ezek többnyire abból fakadnak, hogy a backend belső adatstruktúráját kapjuk vissza JSON-be szerializálva.

#### Objektumok felesleges „becsomagolása”

Az alább látható kimenet jó példája a problémának. A lényeges információ itt a „book” tömb. Minden más felesleges. Sajnos többször találkoztam ilyen felépítésű API-val. Ilyen helyzetben teljesen feleslegesen kell a parsernek két osztály helyett ötöt írni, ráadásul 1-1 mezővel. Mindezt úgy, hogy semmilyen többlet információval nem bír számunkra.

```javascript
{
  "library":{
	"shelf":{
  		"books":{
    		"book":[
      			{
        			"id":0,
        			"title":"The art of API design",
        			"author":"Artie Apfel"
      			},
      			{
        			"id":1,
        			"title":"API design for dummies",
        			"author":"Desmond Dumber"
      			},
      			{
        			"id":2,
        			"title":"JSON for PHP developers",
        			"author":"Jason Phonge"
      			}
      		]
   	 
  		}
	}
  }
}

```

És a megfelelő forma:

```javascript
{
    "books":[
        {
            "id":0,
            "title":"The art of API design",
            "author":"Artie Apfel"
        },
        {
            "id":1,
            "title":"API design for dummies",
            "author":"Desmond Dumber"
        },
        {
            "id":2,
            "title":"JSON for PHP developers",
            "author":"Jason Phonge"
        }
    ]
}

```

#### Tömbök helyett kulcs-érték párok

Ebben az esetben az a probléma, hogy ha egy tömböt várunk, ahol általában az elemek sorrendje számít, akkor az Java-ban egy ArrayList-be, Objective C-ben pedig NSArray típusra lesz parsolva, amelyek sorrendtartó listák. Ellenben ha kulcs-érték párokat kapunk a tömb helyett, akkor azt kénytelenek vagyunk valamilyen Map-be, vagy Objective C esetén NSDictionary-be parsolozni. Ezek az adatstruktúrák viszont nem feltétlenül tartják a kulcsok hozzáadás szerinti sorrendjét. A Gson parser – amit Android esetén használunk – szerencsére LinkedTreeMap-et használ, ami a kulcsok iterálásakor tartja a hozzáadás szerinti sorrendet. Az NSDictionary sajnos nem ilyen, márpedig az [NSJSONSerialization abba parsolja a kulcs-érték párokat, így iOS-en vagy újra kell rendezni az egészet](https://developer.apple.com/documentation/foundation/nsjsonserialization?ref=blog.fps.hu), ha van olyan paraméter, ami alapján lehetséges, vagy rendes tömböt kell visszaadnia az API-nak.

#### Így néz ki a gyakorlatban:

```javascript
{
    "books":{
        "book_0":{
            "id":0,
            "title":"The art of API design",
            "author":"Artie Apfel"
        },
        "book_1":{
            "id":1,
            "title":"API design for dummies",
            "author":"Desmond Dumber"
        },
        "book_2":{
            "id":2,
            "title":"JSON for PHP developers",
            "author":"Jason Phonge"
        }
    }
}

```

Sajnos ezzel a problémával is többször találkoztam már. Valószínűleg a PHP azon sajátosságából fakad, hogy [az array nem klasszikus tömb](http://php.net/manual/en/language.types.array.php?ref=blog.fps.hu), hanem egy rendezett map, ami csak [akkor szerializálódik tömbbé, ha az tömbként is van inicializálva kulcsok nélkül](http://php.net/manual/en/function.json-encode.php?ref=blog.fps.hu).

#### XML attribútumok a JSON-ben

Ez egy érdekes jelenség és amikor először találkoztam vele nem is nagyon értettem, hogy ez miért van így, és minek bonyolítják vele az adatstruktúrát. Aztán a közelmúltban találkoztam vele újra, egy XML-ből frissen JSON kimenetre váltó API-nál, ahol mindkét dokumentációhoz volt szerencsém. Ez bizony még az XML kimenethez készült, csak úgy maradt.

```javascript
{
    "books":[
        {
            "@attributes":{
                "id":0
            },
            "title":"The art of API design",
            "author":"Artie Apfel"
        },
        {
            "@attributes":{
                "id":1
            },
            "title":"API design for dummies",
            "author":"Desmond Dumber"
        },
        {
            "@attributes":{
                "id":2
            },
            "title":"JSON for PHP developers",
            "author":"Jason Phonge"
      	}
    ]
}

```

#### Néha tömb, néha objektum

Ami ki tudja még nyírni a parsereket, ha egy adott mező értéke több elem esetén tömbként jön, egy elem esetén pedig közvetlenül az adott elemet tartalmazza az adott mező. Ennek a kezelésére vannak megoldások (természetesen pörgeti a munkaórákat), de nem baj, ha az egy elemű tömb is tömbként jön vissza.

*Több elem:*

```javascript
{
    "books":[
        {
            "id":0,
            "title":"The art of API design",
            "author":"Artie Apfel"
        },
        {
            "id":1,
            "title":"JSON for PHP developers",
            "author":"Jason Phonge"
        }
    ]
}

```

*Egy elem:*

```javascript
{
    "books":{
        "id":0,
        "title":"The art of API design",
        "author":"Artie Apfel"
    }
}

```

#### Hiányzó String helyett üres objektum

Ez az egyik kedvencem. A JSON ismeri a null-t, így ha nincs értéke a mezőnek, akkor legyen null, esetleg be se kerüljön a JSON-be, de üres objektum ne legyen, az eléggé mást jelent.

Az előző példa üres title és hibás hiányzó String kezelés esetén:

```javascript
{
  "book":{
  	"id":0,
  	"title":{},
  	"author":"Artie Apfel"
	}
}

```

Helyesen:

```javascript
{
  "book":{
  	"id":0,
  	"title":null,
  	"author":"Artie Apfel"
	}
}

```

### Végszó

Az említett problémák általában régi appok leváltásakor kerülnek elő, ahol az ügyfél modernizálni szeretné az applikációt, de csak azt. Esetleg egy web applikáció mellé lenne szükség natív mobil appra és a már meglévő API-t kell használnunk.

Ügyfél oldalon nyilván nehezen emészthető, hogy miért is kell az API-hoz is hozzányúlni, illetve minek a mobilnak dedikált API, hisz a felhasználó úgysem látja, ráadásul a meglévő amúgy is évek óta hibátlanul működik.

Fejlesztői oldalon a probléma gyökere az lehet, hogy máshogy gondolkodunk, más megoldások kézenfekvők egy backend, egy frontend, pláne egy mobil fejlesztőnek, ahol egy oldalon relatíve kevés infó jelenik meg egyszerre, illetve akad néhány megkötés, ami a backend fejlesztőknek idegen lehet.

Az API tervezésekor figyelembe kell venni, hogy milyen kliens fogja azt használni, milyen igényei és korlátai vannak. A mobil alkalmazás ilyen szempontból nem túl hálás. Kevésbé tűri a hibákat, legyen az tervezési vagy működésbeli. Ilyen szempontból közelebb áll egy asztali alkalmazáshoz, mint egy webes frontendhez, csak adjuk hozzá az erősen korlátozott számítási kapacitást, a szűkös memóriát és tárhelyet, a korlátozott adatforgalmat, illetve a merülő akksikat.

És hogy mi a megoldás? Mint minden másra az életben.  
**Figyeljünk oda egymás igényeire és kommunikáljunk.**
### Mexikó 68
URL: https://blog.fps.hu/mexiko-68-olimpia-arculat-design/
Last updated: 2026-07-17T08:25:38.000Z
‘91-ben, pont a 11\. születésnapomon találkoztam először 1968-al. A mai napig emlékszem, amikor Carl Lewis és Mike Powell egy 23 éves rekord felett ültek tort, és tolták odébb az emberiség határát [5 centivel.](https://www.youtube.com/watch?v=T0WfsAwvTSU&ref=blog.fps.hu)

### [1968](https://en.wikipedia.org/wiki/1968?ref=blog.fps.hu)

A 20\. század egyik legjelentősebb éve, amikor a [„globális falu”](https://hu.wikipedia.org/wiki/Marshall%5FMcLuhan?ref=blog.fps.hu) történelmileg, társadalmilag, politikailag, popkulturálisan megrázza magát, és a mai napig ható változások alapjait fekteti le.

Ez volt az év, amikor a prágai tavasz kísérletett tett az [emberarcú szocializmus](https://hu.wikipedia.org/wiki/Pr%C3%A1gai%5Ftavasz?ref=blog.fps.hu) kialakítására, míg szerte a világban, [diáklázadások](http://www.eszmelet.hu/gustave%5Fmassiah-1968-majusa-a-nagyvilagban/?ref=blog.fps.hu) nyomán, a konzervatív tekintélyelvűséget kérdőjelezték meg.

Amerikában a vietnámi háború elleni tiltakozás kulturális szinten is megjelenik. Bemutatják a Hairt a Broadwayn, a zombik pedig Romeronak köszönhetően napjainkig tartó társadalomkritikusként jelennek meg, olykor [Az egydimenziós ember](https://hu.wikipedia.org/wiki/Herbert%5FMarcuse?ref=blog.fps.hu#Az%5Fegydimenzi%C3%B3s%5Fember) metaforájaként.

A Majmok bolygója ebben az évben reflektál az atomfegyverektől való félelmeinkre, míg [Dave Bowmannal](https://hu.wikipedia.org/wiki/2001:%5F%C5%B0rod%C3%BCsszeia?ref=blog.fps.hu) együtt rájöttünk, hogy az élet csak egy szimuláció, amiben a mesterséges intelligencia nem mindig a barátunk.

Ebben az évben lesz merénylet áldozata Martin Luther King polgárjogi aktivista és Robert F. Kennedy szenátor is, márciusban pedig Jurij Gagarin szenved halálos balesetet.

Ha már űrhajózás és tervezőgrafika. **Tudod mi köti össze a náci Németországot, Stanley Kubrickot, a NASA-t és a moszkvai olimpiát?**

A Futura. A betűtípus, ami a ‘60-as években épp második virágzásást éli, a kor [tervezőgrafikusainak és művészeinek is köszönhetően,](http://www.tate.org.uk/art/artworks/mayer-alphabet-square-p80977?ref=blog.fps.hu) a NASA pedig ezt a betűtípust használja az Apolló programjához. Így történhetett, hogy ez a „kiemelkedően német betűtípus” lett [az első betűtípus a Holdon](http://www.wired.co.uk/gallery/futura-font-on-the-moon-christopher-burke-book?ref=blog.fps.hu), és ennek cirillre fordított változata pedig a moszkvai olimpia hivatalos betűje is.

És az olimpia. Mielőtt rátérnénk az 1968-ban, Mexikóvárosban megrendezésre kerülő XIX. Nyári olimpiai játékokra, még ugorjunk vissza két évet.

### Mexikóváros

![aztek-napko-mexiko68](https://blog.fps.hu/content/images/2018/01/aztek-napko-mexiko68.png)  
Két évvel korábban, 1966-ban a mexikói olimpiai bizottság Pedro Ramírez Vázquez –nemzetközileg elismert építész – vezetésével, versenyt ír ki az olimpia arculatára. A megelőző évtizedekben gyorsan iparosodott és urbanizált Mexikóváros méreteit tekintve ekkorra már világvárossá nőtte ki magát. A szervezők elvárása volt, hogy az olimpia összképe hűen tükrözze a „mexikói csodának” aposztrofált modernizációt és egyben a tradicionális mexikói kultúrát is.

Vázquez a bizottság elnöke, egy amerikai munkája során találkozott az ekkor még csak 29 éves Lance Wyman tervezőgrafikussal, aki szintén jelentkezik a pályázatra. Wyman az alkalmat megragadva, kollegájával Peter Murdoch formatervezővel ‘66 novemberében érkeztek a városba, csak odaútra szóló repülőjeggyel. Mivel mindketten először jártak az országban, egyből belevetették magukat a helyi múzeumokba, hogy megismerjék az ország történelmét. Ekkor fedezték fel maguknak az [Azték napkövet,](https://hu.wikipedia.org/wiki/Azt%C3%A9k%5Fnapk%C5%91?ref=blog.fps.hu) amit az akkor New Yorkban épp népszerű op-arttal ötvözve, mindössze két hét alatt megalkották a modernkori olimpiák egyik legsikeresebb logóját. A bizottság véleménye alapján a logónak sikerül egyidejűleg tükröznie Mexikó kulturális sajátosságát és a nemzetközi trendeket.

### És a csíkok elkezdtek terjedni

![logo-mexiko68](https://blog.fps.hu/content/images/2018/01/logo-mexiko68.png)  
Itt vége is lehetne az egész történetnek, ám igazából csak itt kezdődött. A nyertes pályázat nyomán mindketten Mexikóba költöznek, Wyman lesz a vezető tervezőgrafikus, míg Murdoch a speciális projektek vezetője. Azonban kinevezésük eleinte kritikus fogadtatásban részesül – felrótták tapasztalatlanságukat és helyi kötődésük hiányát. Ennek ellenére mindketten remekül illettek Vázquez víziójába, aki már korábbi világkiállításokon szerzett tapasztalataiból tudta, hogy milyen szereplőkre lesz szüksége egy egységes arculat megalkotásához. Így építészekből, várostervezőkből, grafikusokból egy fiatal, friss és tehetséges csapatot állított össze.

Wayne az elfogadott logót továbbvezetve egy egyedi betűtípust alkotott, amit később számos formában lehetett újrahasználni. [Eduardo Terrazasnak](https://www.artsy.net/artist/eduardo-terrazas?ref=blog.fps.hu) (várostervező) köszönhetően, a Huichol kulturából átemelt élénk színekkel keveredve jelennek meg városszerte a mintázatok, miközben a városlakók is egyre inkább sajátjuknak kezdik tekinteni az olimpiát. ‘67 decemberében pedig a New York Times kritikusa John Canaday némítja el a maradék kételkedőket. A művészettörténész úgy ír Mexico68-ról, mint a kor kiemelkedő tervezéséről, ami képes túllépni a poszterek, hirdetések világán, és egységes arculatként jelenik meg a tudatos tervezésnek köszönhetően.

### A funkció és a hagyományok találkozása

![piktogramok-mexiko68](https://blog.fps.hu/content/images/2018/01/piktogramok-mexiko68.png)  
A sportágak egyedi piktografikus megjelenése ma már természetes és egyben meghatározó vizuális eleme az olimpiáknak. Ez azonban korántsem volt mindig így – ennek a trendnek az első debütálása éppen a négy évvel korábbi ‘64-es tokiói játékok volt, ahol sportáganként információs piktogramok jelentek meg. Wyman és Terrazas szimbólumrendszerének egyik legfontosabb irányelve az volt, hogy a vizuális kompozíció a látogatók tájékozódását is segítse. Az egyszerű formák hangsúlyozásával a mexikói kultúrára reflektáltak, teli– és változatos színviláguk pedig szintén az ünnepi Mexikót eleveníti meg.

> Aki nem beszéli a helyi nyelvet, az pont annyira analfabéta egy idegen országban, mint az, aki egyáltalán nem tud olvasni. Mindnyájan írástudatlanok vagyunk, ha nem értjük, hogyan jelenik meg az információ.

– reagált Wyman azokra a felvetésekre, amik szerint a mexikói irástudatlanság miatt használ inkább priktogrammokat.

Amíg a csapat egyik fele azzal foglalkozott, hogy a tájékozódást segítő színek, ikonok, formák egy egységes vizuális rendszerré álljanak össze, addig Peter Murdoch egy tájékozódást segítő [moduláris rendszert](http://graphicambient.com/wp-content/uploads/2012/07/mexico-68-olympics-23.jpg?ref=blog.fps.hu) tervezett. Alapvetően két elemből épült fel: oszlopokból és keretekből. Az elemek sajátossága, hogy a legtöbb kültéri felületre ráilleszthetőek voltak, így lehetett postaládából, szemetesből útbaigazító táblát, telefonfülkéből információs pontot létrehozni. A Murdoch által tervezett rendszer rugalmassága és sokrétű használhatósága nagy lépés lett az utcai bútorok tervezésének történelmében.

### Az olimpia előtt 10 nappal

![diaklazadas-mexiko68](https://blog.fps.hu/content/images/2018/02/diaklazadas-mexiko68.png)  
A játékokra fordított hatalmas költekezés sokak szerint azonban éles kontrasztban állt az átlag mexikóiak életszínvonalával. Nem mindenki érezte át a mexikói csodát, de Wyman sokáig a projekt által teremtett buborékban élt. Ugyan az olimpia előtt pár hónappal diáklázadások kezdődtek, az eleinte Kuba mellett tüntető diákok az olimpia közeledtével a bojkottjára szólították az embereket.

A tüntető diákok átszerkesztették Wyman grafikáit, az arculati elemeket saját plakátjaikon kezdték használni, így lett egyfajta államellenes design is az olimpiára tervezett csomag.

Mexikóváros készen állt a nagy eseményre. Az arculat ereje elsöprő sikert aratott, de ezzel párhuzamosan a tragédia is bekövetkezett: 10 nappal az olimpia előtt, több száz tüntető diákot mészároltak le a rendőrök, ami azóta is véres folt maradt Mexikó történelemben. A szíven szúrt Wyman-galamb képe ikonná vált – melyet a mészárlás után sorra festettek át, emléket állítva az áldozatoknak.

### „Békében minden lehetséges”

![megnyito-mexiko68](https://blog.fps.hu/content/images/2018/02/megnyito-mexiko68.png)  
*Fotó: Sergio Rodriguez, [CC BY-SA 3.0](%28https://creativecommons.org/licenses/by-sa/3.0%29%5D)*

A tragédiát követően nemzetközi szinten is felmerült a játékok elhalasztása, ám a Nemzetközi Olimpiai Bizottság (NOB) elnöke, Avery Brundage határozottan elutasította ennek ötletét. Az olimpia fő jelmondata –„Békében minden lehetséges"–, kettős értelmet kapott, amit tovább erősítettek a sporteseményeken történtek.

A 200 méteres síkfutás díjátadóján a győztes, Tommie Smith és a bronzérmes, John Carlos [fekete kesztyűs öklüket az ég felé tartva,](https://en.wikipedia.org/wiki/1968%5FOlympics%5FBlack%5FPower%5Fsalute?ref=blog.fps.hu) lehajtott fejjel tiltakoztak a faji megkülönböztetés ellen. A NOB azonnali eltiltással kizárta őket a további versenyzéstől, és hazaküldte a két atlétát.

Vera Caslavská – négy aranyérmet nyerő csehszlovák tornász –, a szovjet csapattal szembeni hátatfordítása, és győzelmének a cseh reformmozgalom elnökének, Dubčeknek tett ajánlása ha eltiltást nem is, de diplomáciai bonyodalmakat okozott.

### Utóélete

Az olimpia után Wyman még Mexikóban maradt és a város első metróvonalának egységes infografikáján dolgozott. Wyman és csapata a már a játékok alatt bejáratott vizuális rendszert gondolta tovább és használta az állomások egyedi megjelenésénél. Így alakult ki a mai napig is használatban lévő, főként ikonokra és színekre épülő rendszer, ami annyira sikeres lett, hogy úgy tartják, Mexikóváros metrójában képtelenség eltévedni.

Összességében 1968 nem csak a történelem szempontjából volt vízválasztó, hanem a tervezőgrafika is új szintre lépett, amiben a Vázquez által megálmodott csapatnak jelentős szerepe volt.

A végére pedig a személyes véleményem, ha másnem, a grafika terén 1968 ismét a levegőben lóg. Kíváncsian várom merre fog haladni a vizuális kultúránk, és mennyire lesz hatással egy 50 évvel korábbi irányzat korunkra.

Források:

- [A cikk, ami a kiindilópont volt és egy riport is meghallgathatsz Wymannal](https://99percentinvisible.org/episode/mexico-68/?ref=blog.fps.hu)
- [A cikkem alapjául szolgáló átfogó és alapos riport.](https://segd.org/1968-mexico-city-olympics?ref=blog.fps.hu)
- [Egy remek képes összefoglaló Mexico68-ról.](http://graphicambient.com/2012/07/26/1968-mexico-olympics-mexico/?ref=blog.fps.hu)
- [Ahol bőven olvashatsz a '68-as történésekről.](http://www.eszmelet.hu/gustave%5Fmassiah-1968-majusa-a-nagyvilagban/?ref=blog.fps.hu)
- [Heller Ágnes összegzője 1968-ról.](http://www.c3.hu/scripta/beszelo/97/11/13.htm?ref=blog.fps.hu)
### A változtatás varázslata
URL: https://blog.fps.hu/a-valtozas-varazslata/
Last updated: 2026-07-17T08:25:48.000Z
Régóta foglalkoztat, hogyan lehetne rávenni a környezetemben élőket arra, hogy a napi 8–9 óra munkahelyen eltöltött szakadatlan, székbesüppedős, gerincet nem kímélő ülés után szenteljenek időt a rendszeres testmozgásra. Úgy érzem, már csak a varázslat segíthet.

A „miért nem”-ek mögött általában kifogások és sikertelen próbálkozások sorozata leledzik. A többség az idő és képességei hiányára, a lehetőségek szűkére hivatkozik, valamint kudarc élményre.

Túl fárasztó, nem szimpatikus az edző, egyedül unalmas edzeni stb. és nem keressük tovább a megoldást, megpróbáltuk „pipa” és pont…ülünk tovább.

![villanykörték és az első felvillan](https://blog.fps.hu/content/images/2018/01/adri_blogpost_02--1-.gif)

### Szakadék és józan ész

A sikertelen próbálkozások tövisekkel tűzdelt, forró lávaköves ösvényén nehogy azt gondold: te vagy az első és az egyetlen, akinek nem jön össze ez a rendszeres testmozgás dolog. Azt pedig különösen ne gondold, hogy ez azért van, mert felnőtt korban már nem lehetséges a fejlődés ill. a változás, tanulás.

Nagyjából 30 éve az az elmélet volt elfogadott, hogy a fejlődési fázis a húszas éveink végén alapvetően befejeződik. Aztán a 80-as években kiderült, hogy egyes felnőttek ugyan olyan mértékben és minőségben tudnak fejlődni, mint fiatal korban.  
Tehát szellemi képességeink fejlődését ne temessük el a fiatal felnőtt kor befejeztével. Ma már az a nézőpont, hogy az agyunk életünk végéig képes az alkalmazkodásra és ennek az egész változtatási varázslatnak bizony fejben van a mozgatórugója. A felnőttkori fejlődésnek pedig soha nem volt ekkora jelentősége mint manapság.

### Mindezek fényében, akkor miért nem tudunk változtatni?

Csak józan ésszel átgondolva: gyakori jelenség, hogy nagyon messze van egymástól az, amit valóban el szeretnénk érni és az, amire ténylegesen képesek vagyunk. Ekkor szembesülünk ezzel a szakadékkal, ami miatt kellemetlenül érezzük magunkat. Végül is ez jó! …a motiváció egyik elindítója ez a döbbenet, kellemetlen érzés is lehet(ne). A következő pillanatban viszont túl nagyot akarunk ugrani, nem érjük el az áhított célt rövid időn belül és ekkor sokan feladják.

Nem közelíteni akarunk a célhoz, hanem azonnal átugrani az egészséges, fitt és aktív túloldalra majd soha többé nem foglalkozni a mozgással, mert az edzettség és az állóképesség örökké tart! (jaj…te kis naív)

![Spongya Bob](https://blog.fps.hu/content/images/2018/01/giphy-downsized-1.gif)

### Egészség

Lejárt lemez? (ha a válaszod igen, akkor te már megint naív vagy)  
Akkor lesz az, ha visszasüppedünk a kényelmes fotelbe minden áldott nap és tovább panaszkodunk sajgó és zsibbadt mozgásszerveinkre, amelyek az életmódunk áldozatai lettek. R.I.P.

Egészségi állapotunk megtartása, illetve javítása érdekében a két legfontosabb: egészséges és rendszeres táplálkozás rendszeres testmozgással tűzdelve. Egyiket sem kell bemutatnom ismeritek egymást, max. nincs még meg a szimpátia…meg különben is…játszák itt az elérhetetlent!  
A szemetek!

Az egészséges életmódhoz vezető utat felfoghatjuk a K2-nek, amit meg kell másznunk, majd ha felvergődtünk, gyönyörködünk a kilátásban és visszatérünk ugyan oda, ahonnan indultunk…tudod a fotel, meg a „fáj”.

Olvastam egy orvosi kutatásról, amelyből az derült ki, hogy hiába közli a kardiológus a trombózison átesett pácienssel, hogy meg fog halni, ha nem változtat az életmódján (étkezés, mozgás, dohányzás elhagyása), hétből csak egy beteg lesz képes végigvinni a szükséges változtatásokat.

Pedig vitathatatlan, hogy a másik hat is életben akar maradni…

### Ülj kevesebbet, sétálj, sportolj!

A helyzet az, hogy most még lehet nem érzed a negatív hatását, de számíthatsz rá: ha így folytatod hamarosan kopogtat. Ehhez értők szerint az ülés a legkártékonyabb testhelyzet, ami lassan, de biztosan rombol. A testünk dinamikus működésre optimalizált, üléskor más izmokkal tartod magad, mint járás közben. Ezek az izmok sajnos képtelenek túl hosszú ideig aktívak lenni, így elkerülhetetlen a görnyedés, ami egy sor probléma elindítója és hiába a sötét jövő nem tesszük meg még a minimális lépéseket sem.

![Villanykörték ütköznek, elindul a folyamat, az egymásra hatás](https://blog.fps.hu/content/images/2018/01/adri_blogpost_01--1-.gif)

#### Level 1

Mit értek minimális alatt? Óránként kelj fel a székből, egy pohár víz a konyhában és még a folyadék bevitelt is támogattad. Vannak különféle eszközök pl.: fit labda, ékpárna. Ezek nem kerülnek eget rengető összegbe és nem is kell, hogy mindenkinek legyen az irodában, naponta/fél naponta lehet cserélgetni, ezzel figyeltek egymásra és amíg megy a csere, addig sem ülsz. Plusz a szokásos, minden e témával kapcsolatos cikkben sulykoltak: használd a lépcsőt lift helyett, sétálj egy buszmegállót, parkolj kicsit távolabb, mint szoktál.

#### Level 2

Ha reggelente vagy akár nap végén szánsz 10 percet egy kis gimnasztikára, nyújtásra, hidd el sokat segítene. Nem kell bonyolult, nyakatekert gyakorlatokra gondolni: fej-kar-törzs körzés, törzshajlítás stb. Ha nyújtás, akkor ugyan ez a helyzet, a nyújtózkodástól kezdve a fekvő testhelyzetben művelt gyakorlatokig rendkívül széles a választék. Ha példák kellenek: itt ülsz egész nap…biztosan találsz! A lényeg, hogy építsd be a mindennapi rutinba, FOKOZATOSAN.

#### Level 3

A leges-leg ideálisabb az, ha a fentieknél aktívabban, több időt fektetsz a testmozgásba. Ez szó szerint egy befektetés és biztosan megtérül.

Számtalan előnyei egyike, hogy a sport a személyiséget is edzi, nemcsak az izmokat.  
Minden egyes alkalom mentális munka is: kitartani, koncentrálni, fegyelmezetten elvégezni a feladatot. Heti rendszerességgel ez a mentális munka hagy némi lenyomatot a személyiségen.

Növeli a teherbírást, a kitartást, segít a koncentrációban, tanulhatunk belőle fegyelmet, ami a helyes táplákozáshoz és a változások véghezviteléhez is fontos.

…és még sorolhatnánk: tolerancia, pozitív hozzáállás, nyitottság új módszerekre és új ötletekre, konstruktív kritika elfogadása, alkalmazkodó képesség, magabiztosság – egészséges önbizalom, ismerni az erősségeinket, gyengeségeinket, jó szervezőkészség,  
empátia. Hát mi ez ha nem varázslat?

![MOVE – Mozogj](https://blog.fps.hu/content/images/2018/01/adri_blogpost_03.gif)

### Akkor most mi a recept?

Az a recept, hogy alkosd meg a saját recepted! Itt most elküldesz melegebb éghajlatra. A hideget jobban szeretem bocs.

Visszatérve a témához: az elfoglaltságaid, az érdeklődésed és lehetőségeidet figyelembe véve építsd a napi rutinba.

Igen, ez igényel némi tervezést, utánajárást, nem is keveset. Lesz olyan is, hogy valami nem válik be. A legfontosabb, hogy kis lépésekben haladj! Kezdj ma, ne várj! :)
### Mennyit ér 2,5M Ft az online magyar borpiacon?
URL: https://blog.fps.hu/mennyit-er-ket-es-fel-millio-forint-az-online-magyar-borpiacon/
Last updated: 2026-07-17T08:25:57.000Z
Mármint akkor, ha a márka éves kommunikációs stratégiája egyébként sem nálad, sem kész nincs. Jobb egyébként, ha kész van, de azért mutatjuk mit lehet kihozni belőle. Számok, tények és következtetések következnek.

![itt van pénz](https://media.giphy.com/media/3o7abGogJwT2eHXDKE/giphy.gif)

### TL;DR

Adott 10 millió forintnyi büdzsé, ebből médiára el kell mennie 7,5 millió forintnak, minden másra pedig (tartaloom és hirdetéskezelés) maradt 2,5 millió forint egy megszorításokkal teli piacon úgy, hogy a teljes ügynökségi arzenált – workshopok, évtervezések, stratégiai együttműködés, offline átkarolások és építkező szemlélet – most nem lehetett felvonultatni. Mutatjuk mit lehet belőle tanulni.

### Első lecke

Ha online is és alkohol is, akkor nem vagy könnyű helyzetben.

![spoiler alert!](https://media.giphy.com/media/3o6gDWvntdm16XezUA/giphy.gif)

Nyilván meg kell felelni a helyi szabályozásoknak (18 éven aluliaknak ne népszerűsítsd, hogy éljen az alkohol), másrészt a fő online marketing felületeken bizonyos értelemben meg van kötve a kezed.

A Facebook és a Google Adwords hirdetési rendszere is szigorú szabályozásokat ír elő az alkoholtartalmú italok népszerűsítésével kapcsolatban, aminek következménye, hogy bizonyos hirdetési technikákat és funkciókat nem lehet alkalmazni. Okoskodhatsz, de nem fog menni.

Ez a gyakorlatban azt jelenti, hogy bizonyos célzásokkal kapcsolatban nagyon könnyen elutasíthatják a hirdetéseidet, azaz az előre elképzelt marketingstratégiád szinte azonnal borul(hat). Bár az is előfordul, hogy egy-egy nem engedélyezett célzásnál meg átcsúszhat hirdetés, főleg a Google rendszerében, ahol emberek végzik az ellenőrzést, de azért ez még így sem egy stratégiai győzelem.

### Nézzük mi volt a feladat

![challenge accepted](https://media.giphy.com/media/3WPKHcTih1xwQ/giphy.gif)

Esetünkben a megbízó egy nagy (nagy) márka, több különálló almárkával, amik kezelhetőek lennének termékcsaládként is, de most kezeljük őket külön kisebb márkákként. Nem úgy, mint mondjuk a P&G és az Ariel, hanem, mint mondjuk a Soproniból a Démon meg a Duhaj. (Tudjuk, hogy izgibb lenne, ha tudnátok kinek az adatait tesszük közzé, de neveket sajnos nem használhatunk).

A címben említett 2,5 millió forintot tehát nem (nagy) márkabevezetésre, sem almárka bevezetésre nem használhattuk, a feladat az volt, hogy egy specifikus terméket (kizárólag online) népszerűsítsünk. (Ez építkezés nélkül, amúgy nem akkora ötlet, de most tényleg adott volt a helyzet, nincs mindig az az ideális állapot, hogy már előző évben kirakjátok az ügyféllel közösen a következő éves teljes integrált kampányos kommunikációs tervet).

Tehát kampánycél egy: Az adott borra gondoljanak másként az emberek, mint addig (újrapozícionálás, edukáció). Kampánycél kettő: vegyék is többen, mint addig (sales). Volt még kampánycél három, sőt négy is, de most vegyük a két nagy célt. Ha ráncolod a homlokod, értjük, ez kevés pénz egy kampányon belül több külön célra, nem szerencsés, aprózódik minden, főleg az eredmények, de a válasz újfent: van ilyen. Mindig is volt, és – reméljük egyre kevesebbszer, de – lesz is még, meg kell oldani.  
A kapott feladat leegyszerűsítve egy új oldal elkészítése, médiavásárlás, annak támogatása és az elkészült oldalra való forgalomterelés volt. Az oldalnak egyszerre kellett image feladatokat ellátnia eredeti kreatívval, érdekességeket és hasznos információkat szolgáltatnia, és egy játékot is le kellett rajta bonyolítani, különböző nyereményekkel.

### Szöszölés

![Gondol, gondol, gondol](https://media.giphy.com/media/rq6c5xD7leHW8/giphy.gif)

Először is kellett egy kreatív. Akkor is, ha nem lesz offline lába, és ha nincs éves terv, amibe illeszkedik, és pénz sincs, amivel az imidzs megoldásaidat népszerűsíted, akkor is kell a klasszikus kreatív, amit mondasz, akinek mondod, és ahogyan mondod. Insight-ok alapján, benchmarkok mentén, piackutatás után, heteken át dobálva ki az ötleteket el kellett jutni egy később a helyét több platformon is megálló alapkoncepcióig.

Ezután kellett a tartalom. A webed (bár vannak külön esetek), ha nem csak egy sima landingről beszélünk, hanem valami többről, akkor viszonylag komoly tartalommal kell megtöltened. Olyannal, ami a mini-integrációk során nemcsak mérhetővé teszi majd a teljesítményed és a piacod reakcióit, hanem nem üti agyon a korábban kitalált kreatívot sem.

Mi egy idő után arra jutottunk, hogy a tartalom a bor története és a gasztrokapcsolat lesz. A fő tartalom az image megoldások mellett a receptek, tippek, tanácsok, szokások voltak, amiket aztán nem csak a weboldalon használtunk fel, hanem a közösségi oldalunkon, és a vásárolt médiában is.

A terv az volt, hogy új megvilágításba helyezzük a terméket, miközben törekszünk arra, hogy a minőségi tartalom mellett szépen lassan megváltoztassuk az emberek viszonyát ehhez a fajta borhoz, mert ez a viszony egy kicsit poros. A legkirályabb az lett volna, ha egy webshopot is fejleszhetünk, és a tölcsér hirtelen sokkal teljesebb lesz, de újra emlékeztetnünk kell magunkat, most a helyzet adott volt, nem lehetett ilyen módon kibontakozni. A tartalomhoz kapcsolódóan igyekeztünk tehát népszerűsíteni a terméket, miközben a bor iránt közvetlenül érdeklődő embereket tereltük az oldalra.

### Eredmény

![számok, adatok, képletek](https://media.giphy.com/media/SabSYEpsVh0di/giphy.gif)

A közel 2 hónapos kampányidőszak alatt, több mint 45 000 felhasználó látogatott el az oldalra, akik több mint 80 000 oldalmegtekintéssel átlagosan 49 másodpercet (óriás szórással, mert a FB leadek 1,5 percet is elolvasgattak és elnézelődtek) töltöttek a weboldalon.

A látogatók 62,4% volt nő volt, a 35 év felettiek túlsúlyával, a férfiak 25 és 44 év közötti korosztályból érkeztek a legtöbben az oldalra.

Ez az adat azért érdekes, mert a megbízói becslés és igény a 18–70 év közötti igényes felnőtteket jelölte meg elérendő célcsoportként. Ilyen azonban nem létezik, sajnos el kell fogadni. Ha el is éred, nem fog működni a dolog egy kampányon belül.

Az oldalon töltött egész jó idő mellett, nagyon alacsony visszafordulási arányt értünk el, amit nem tudunk másnak betudni, minthogy a látogatók jó, a szokatlantól eltérő kreatívval és designnal (lsd. szöszölés 1.pont) és minőségi tartalommal (lsd. szöszölés 2\. pont) találkoztak az oldalon, és a promóció sem ütötte agyon az egészet.

Sőt. A főoldali kreatív után a nyereményjáték mozgatta meg leginkább az embereket (azért ezen mondjuk nem kell meglepődni) a forgalom innen főleg a promóciós aloldalra folyt.

A forgalmi forrásokkal kapcsolatban elmondható, hogy Adwords és Facebook hirdetésekből érkeztek a legtöbben az oldalra, és ebből a két forrásból történt a legtöbb oldal megtekintése is a weboldalon.

### Szóval pontosan mit csináltunk

![Ki az apád? És mit csinál?](https://media.giphy.com/media/BaM6S4Jm6xc40/giphy.gif)

Facebook-oltunk és Adwords-öltünk.

Na jó. Tehát csináltunk egy weboldalt, feltöltöttük tartalommal és a forgalmát Facebook és Adwords kampányokkal (Search és Display házon belül) bonyolítottuk le (médiavásárlással támogatva).

### Display

A Display kampányok esetében több célzást, több megközelítést is használtunk, a bannereken pedig a promóciót népszerűsítettük, ez dec. 23-ig tartott.

Mivel a fő (ügyfél)cél az elérés volt, ezért kezdetben elég tág célzásokkal próbálkoztunk, ami nem hozta a legjobb számokat, így később, a folyamatos optimalizálásoknak köszönhetően sikerült az átkattintási arányt majd’ háromszorosára emelni (2,5%-ről 8%-ra), míg a kattintásonkénti költséget átlagosan a felére csökkenteni (search: 194 forintról 68 forintra; display: 82 forintról 68 forintra) a kampány végére.

(Sose engedd meg magadnak, hogy nem optimalizálsz és minden megy az első beállításokkal. Senkinek sem mehet minden elsőre, és ha már online játszóterünk van, legalább ezt az előnyét használjuk ki.)

Érdekes megfigyelés volt, hogy a médiamegjelenések támogatására használt elhelyezés alapú hirdetések nem voltak túl sikeresek. A tézis az, hogy az ünnepek előtti megnövekedett reklámzaj és az adott oldalakon vásárolható bannerhelyeken kívüli csekély megjelenési lehetőség miatt volt mindez, de a lényeg, hogy nem sikerült jelentős eredményeket elérni.

### Search

A Search kampányok már máshogy néztek ki. Itt 2 megközelítést használtunk. Konkrétan a termékhez, borhoz kapcsolódó kifejezéseket (Forgalom), és az ünnepekhez, pezsgőhöz, receptekhez, ételekhez kapcsolódó keresésekre fókuszáltunk (Image).

Novemberben az image kampány hirdetési szövegei a koncepció alapján kerültek megírásra (lsd. szöszölés 1.pont), a forgalmi kampánynál pedig a promóció hirdetésén volt a fő hangsúly.

Ebben a hónapban a relevanciát kicsit el kellett engednünk (emiatt a kattintások árát is magasabban kellett tartanunk), mert igyekeztünk megfelelni az ügyfél kezdeti elképeléseinek: juttassuk el a dolgot minél több emberhez.

Decemberre annyi változás történt, hogy a search forgalmi kampányokban már (számokkal is alátámasztva) meg tudtuk győzni ügyfelünket, hogy minden jobb lesz, ha támaszkodunk a kezdeti munkára is (lsd. szöszölés) azaz a promóció hirdetését elhagyva a kampány koncepcióját felhasználva sokkal relevánsabb hirdetéseket futtattunk.

Így végül az történt, amit vártunk, a forgalmi search kampányok esetében sikerült a harmadára csökkenteni a kattintások költségét, és több mint 60%-kal növelni az átkattintási arányt. Nagy jee.

### Eközben a Facebookon

![Mark Zuckerberg kinyújtja a nyelvét](https://media.giphy.com/media/eLgL5KGf6pTsA/giphy.gif)

A Facebook hirdetéseknél CPC (forgalomterelő, kattintás alapú) és Boost (posztkiemelés) típusú hirdetéseket használtunk.

A CPC hirdetések esetében csak a promóciót hirdettük. Az oldalon található további tartalmakat a megjelent posztok kiemelésével juttattuk el a célközönségnek.

A CPC hirdetéseknél novemberben a bor, pezsgő, ünnepek, karácsony témakörök iránt érdeklődő embereket céloztuk. Decemberben ezt az egészet megdobtuk a hasonmás célközönség használatával (lookalike audience). Ez egy jó kis funkciója a Facebooknak, ennek a célközönségnek az alapját a novemberi eredmények szolgáltatták.

Olyan embereket céloztunk meg, akik Facebook tevékenységük és demográfiájuk alapján nagyon hasonlóak azokhoz az emberekhez, akik a novemberi hónapban a legtöbb időt töltötték a weboldalon, illetve akik aktivitást és/vagy elköteleződést mutattak az oldal Facebook tartalmai iránt, azaz sikerült teljesen új embereket elérni, akik viszont nagyban hasonlítottak azokra, akik korábban magasabb aktivitást mutattak a termék és a márka iránt.

Egyszóval kevésbé ment a levegőbe és a vaktába a költőpénzünk.

Érdekesség volt, hogy a kattintások költségében nem volt tapasztalható jelentős eltérés, ám az átkattintási arányoknál jelentősen jobban teljesített a hasonmás célközönségnek szánt kampány (2,5% vs. 0,5%).

Ha a posztok sikerességét nézzük (FB tartalom stratégia) az aktivitási arányszám lehet a legobjektívebb mutató. Az aktivitási arányszám azt mutatja meg, hogy az összes elérés tükrében mennyi volt az összes elköteleződés (like, share, komment, klikk) aránya.

Egy ilyen összehasonlításnál azonban célszerű lehet az organikus és a támogatott posztokat külön kezelni, ahogy mi is tettük, és úgy megnézni a hozzájuk tartozó aktivitási arányszámokat, mivel a támogatott posztoknál jelentkező nagyobb elérés torzíthatja az adott posztokra vonatkozó eredményeket, és így kicsit hülyeség az organikus elérésű posztokkal összehasonlítani őket.

A mi esetünkben elmondható, hogy a minőségi tartalom (lsd. szöszölés 1\. és 2\. pont) és a jó célzás miatt sikerült a piaci átlagnál magasabb aktivitást elérni akár a hirdetett, akár az organikus posztokat nézzük.

### Tanulság

![Mission accomplished!](https://media.giphy.com/media/84g6u2O3epwKA/giphy.gif)

Mivel integrált kampányt vittünk, amiben kimelten fontos volt, hogy ne csak edukáció kapjon szerepet, hanem a promóció is, ezért elengedhetetlen volt, hogy a forgalmat sikeresen tereljük az oldalra.

Az érdekes tapasztalat viszont az volt, hogy amíg a médiavásárlás során vásárolt felületeken (ezt már olvastátok, hogy az ügyfél kérésének megfelelően erre nagyjából 7 millió forint ment el) megjelent tartalomból nem érkezett jelentős forgalom a weboldalra, addig ugyanaz a tartalom általunk, azaz márkaként visszaosztva és meghirdetve az egyik legjobb forrásnak bizonyult az oldal forgalma szempontjából.

A média elérések bár jelentősek voltak, de a forgalomterelésben sokkal hasznosabb csatornáknak bizonyultak a Facebook és Adwords által biztosított hirdetési felületek. Röviden elmondható, hogy sokkal jobban szerepelt az online hirdetések saját kezelése, mint a médiamegjelenések eredményei.

**Nagyjából így állunk, köszi a figyelmet, kérdezzetek bátran!**
### Akadálymentes tervezés
URL: https://blog.fps.hu/akadalymentes-tervezes-poszterek/
Last updated: 2026-07-17T08:26:10.000Z
A brit [Home Office Digital](https://hodigital.blog.gov.uk/?ref=blog.fps.hu) a [Government Digital Service (GDS) Team](https://gds.blog.gov.uk/?ref=blog.fps.hu) – GOV.UK – támogatásával egyszerű és szép posztereket készített az akadálymentes tervezés népszerűsítéséhez. Ezeket a posztereket magyar nyelvre ültettük át és tettük elérhetővé mindenki számára.

A poszter csomag jelen pillanat 7 téma köré épül és tartalmaz hasznos tudnivalókat.

**Tervezési ismeretek**

- autizmus spektrumzavarral élők,
- képernyőolvasót használók,
- csökkentlátók,
- diszlexiások,
- testi fogyatékkal élők és mozgáskorlátozottak,
- siketek, vagy halláskárosultak,
- szorongással élők

számára.

Így néznek ki, lentebb le is töltheted:

![akadálymentes tervezés poszterek előnézet](https://blog.fps.hu/content/images/2018/01/akadalymentes-tervezes-poszterek-elonezet.png)

**Töltsd le a magyar posztereket PDF formátumban**, nyomtasd ki és tedd ki a faladra!

[Letöltöm a posztert (0 letöltés)](https://www.fps.hu/presentations/accessibility-posters-set%5Fhu-fps-agency.pdf?ref=blog.fps.hu "Letöltöm a posztereket PDF-ben") 

**Köszönjük, ha belinkeled és megemlíted a forrást, azaz minket.**

A csomagot különböző nyelveken – a poszt írásakor 14 nyelven – érheted el a [Home Office Digital github csatornáján](https://github.com/UKHomeOffice/posters/tree/master/accessibility?ref=blog.fps.hu).

*Köszönet az [Igazából angol blognak](http://igazabolangol.blog.hu/?ref=blog.fps.hu) a fordításban nyújtott segítségért.*
### Saját Android Lint szabály írása
URL: https://blog.fps.hu/egyedi-lint-szabalyok/
Last updated: 2026-07-17T08:26:20.000Z
Amikor új kódot írsz, majd tesztelsz, természetesen előfordulnak hibák. Ugyebár egy alkalmazást több API verzión érdemes megnézni. Továbbá, amennyire csak lehetőséged van, különböző gyártók készülékeivel is érdemes tesztelni.

Ebben nekem az a legidegesítőbb, amikor ugyanazt a problémát kell javítanom már megint, mert a kód írásakor nem gondoltam rá vagy más nem számolt vele a csapatban.

Erre példa a [beépített Android resource-ok megváltoztatása](https://twitter.com/mandybess/status/910555678476951552?ref=blog.fps.hu). Egyes készülékeken a beépített @android:color/transparent az fehér. Ekkor nyilván lehet átírni mindenhol, ahol ez használva van. Az ilyen jellegű szívást szerettem volna megspórolni saját Lint tesztek írásával.

A [statikus analízisről](https://blog.fps.hu/ghost/#/editor/5994202b8be87e1f12f3a560) írtam már, aminek fontos része volt a Lint. Ehhez egyedi szabályokat is lehet készíteni, hogy turkálj a res mappában lévő fáljaidban.

### Emlékeztető

A Lint tulajdonképpen a kód futtatása nélkül keres hibákat, de Androidra hegyezve. Több mint 300 szabályt tartalmaz jelenleg. A legújabb bétájában már minden Java/Kotlin kódon futtatható.

Egyik legnagyobb előnye, hogy nem csak programkódot vizsgál, hanem többfajta fájlt, akár egyszerre is:

- .xml, AndroidManifest
- .jpg, .png, .webp
- .class
- .kt, .java
- .cfg

Így például lehet ellenőrizni, hogy az XML-ben létrehozott felülethez megfelelő osztályokat használsz a forráskódban.

### Meglepetés

Használatakor el kell fogadni, hogy nincs dokumentáció. Ez azért van, mert az API nem végleges és folyamatosan változik.

A legjobb információkat blog postokban, [GitHub repoban](https://github.com/a11n/android-lint?ref=blog.fps.hu), vagy [előadásokban](https://youtu.be/p8yX5-lPS6o?list=PLQ176FUIyIUY6UK1cgVsbdPYA3X5WLam5&ref=blog.fps.hu) találni. Továbbá fejlesztés közben a forráskódban is érdemes turkálni, mert van komment a legtöbb helyen. Van egy [aktív lint-dev fórum](https://groups.google.com/forum/?ref=blog.fps.hu#!forum/lint-dev) is, ahol tudsz segítséget kérni, ha elakadsz.

Ajánlott a [meglévő szabályokra](https://android.googlesource.com/platform/tools/base/+/master/lint/libs/lint-checks/src/main/java/com/android/tools/lint/checks?ref=blog.fps.hu) építkezni az Android forráskódból. Ezek példát is nyújtanak, ha esetleg nem megy valami.

Meggondolandó Kotlin nyelven írni a szabályokat. A Lint egy része is ezen a nyelven van írva és ki lehet használni például plusz annotációkat. A lenti kódok egyébként Javaban vannak.

### Gyorstalpaló

Egy Lint szabály 4 nagyobb részre bontható fel:

- **Issue**  
Leírás a hibáról és szabályról.
- **Detector**  
Ez keresi a hibát. Hogy gyorsabb legyen egy detectorban több Issue-t is lehet keresni és specializált detectorok vannak. Például a ResourceXmlDetector Xml fájlokban keres.
- **Implementation**  
Itt kell megadni, hol keresed a hibát és mivel, azaz a használt detectort.
- **Registry**  
Egy nyilvántartás, lista az issue-król. Ez alapján fogja futtatni a szabályokat a Lint.

### Ugrás a vízbe

Egy példán keresztül mutatom meg, hogy épül fel egy Lint szabály. Ez a „ne használj beépített Android színeket” kezdetleges változata. A [githubon is eléred](https://github.com/fpshu/android-lintrules/blob/4cf5f1e79b6627f96c2762ade31e6afc18c7a30b/src/main/java/hu/fps/lintrules/ColorDetector.java?ref=blog.fps.hu) a lenti forráskódokat.

Egy külön modulba/projectbe kell pakolni a szabályokat, így könnyebben újrafelhasználhatóak. Először a [gradle.build fájl](https://github.com/fpshu/android-lintrules/blob/4cf5f1e79b6627f96c2762ade31e6afc18c7a30b/build.gradle?ref=blog.fps.hu) felépítését vizsgáljuk meg:

```java

apply plugin: 'java-library'

dependencies {
    compileOnly 'com.android.tools.lint:lint-api:26.0.1'
    testCompileOnly "com.android.tools.lint:lint:26.0.1"
    testCompileOnly "com.android.tools.lint:lint-tests:26.0.1"
    testCompileOnly "com.android.tools:testutils:26.0.1"
    testCompileOnly "junit:junit:4.12"
}

jar {
    manifest {
        attributes("Lint-Registry-v2": "hu.fps.lintrules.IssueRegistry")
    }
}

```

Elég a java-library plugint használni. Nem lesznek Androidos függőségek, fájlok és nem kell AndroidManifest.xml. Egy jar fájlt fog generálni a project, ami a Registry-re mutat. Ahogy említettem ott vannak felsorolva a szabályok, azaz issue-k.

A Lint 26.0.1-es verzióját érdemes használni. Ebben már lintChecks konfigurációval be lehet húzni a szábályt a project függőségei közé. A régebbi verzióknál lint.jar fájl kell másolgatni egy Gradle task segítségével.

Az IssueRegistry osztályra még később visszatérek. Először a szabályt kell létrehozni:

```java

public class ColorDetector extends ResourceXmlDetector {

```

A szabályoknak ki kell terjeszteniük a Detector osztályt és implementálniuk a Scanner interfészt. Ez a szabály a Lintbe beépített ResourceXmlDetector osztályt használja, ami kiterjeszti a Detector-t és implementál egy Detector.XmlScanner interfészt. Ez a beépített osztály XML fájlokat vizsgál.

```java

private static final Implementation IMPLEMENTATION = new Implementation(
            ColorDetector.class, //Ami keres
            Scope.MANIFEST_AND_RESOURCE_SCOPE); //Ahol keresünk

public static final Issue ISSUE = Issue.create(
            "AndroidColorDetector", //azonosító
            "Using Android color resources", //rövid leírás
            "Android color resources like android:color/white should not be used." +
                    " Manufacturers tend to overwrite them.", //leírás
            Category.CORRECTNESS, //kategória
            7, //prioritás
            Severity.ERROR, //súlyosság
            IMPLEMENTATION);
            

```

Létrehozod benne az issue-t és az implementációt. Az issue-ban lévő adatok megjelennek majd a riportban, ezért fontosak. A Severity (súlyosság) beállítására is oda kell figyelni. A Fatal, ami a legrosszabb, például megakadályozza az APK csomagolását.

Implementációnál megadod a Detector osztályt és azt, hogy hol folyik majd a hiba keresése. Az @android:color/ érték előfordulhat a manifestben és a resource mappában lévő xml fájlokban, ezért ott keresed majd.

Jöhet a vizsgálat, azaz mégse, mert tudsz [teszteket](https://github.com/fpshu/android-lintrules/blob/8f9b2616117d9a1926b1dd7d37a8fff7d923b3fc/src/test/java/ColorDetectorTest.java?ref=blog.fps.hu) írni és érdemes is:

```java

public class ColorDetectorTest extends LintDetectorTest {

```

A ColorDetectorTest osztály kiterjeszti a beépített LintDetectorTest-et. Ez JUnit 3, tehát minden metódusnak „test”-el kell kezdődnie, nincsenek annotációk.

```java

@Override
protected Detector getDetector() {
    return new ColorDetector();
}

@Override
protected List getIssues() {
    return new IssueRegistry().getIssues();
}

```

Ezek a metódusok kötelezőek. Egyik a Detectort másik az Issue-t adja vissza.

```java

 public void testShouldDetectNoWarning() {
    lint().files(
            manifest("android:icon=\"@mipmap/ic_launcher\"")
    ).allowMissingSdk()
    .run()
    .expectClean();
}

public void testShouldDetectWarning() {
    lint().files(
            manifest("android:icon=\"@android:color/white\"")
    ).allowMissingSdk()
    .run()
    .expectErrorCount(1)
    .expect("");
}

```

DSL teszt API van Linthez, ami megkönnyíti a tesztelést, természetesen dokumentáció nélkül teszi mindezt. Egyik tesztben sikeres eredményt várunk el, míg a másikban sikertelent.

Az elvárt eredményt is meg kell adni hibás esetben, amit addig nem lehet tudni, míg nem írod meg. Ha ezt megírjuk, akkor a teszt futtatása után látni lehet majd és csak át kell csak másolni a tesztbe. Szóval ez nem gond.

A fenti kódban a manifest nagy része nincs benne, de [githubon megtekintheted](https://github.com/fpshu/android-lintrules/blob/8f9b2616117d9a1926b1dd7d37a8fff7d923b3fc/src/test/java/ColorDetectorTest.java?ref=blog.fps.hu).

Ha megvannak a tesztek, akkor lehet írni a szabályt a ColorDetector osztályban:

```java

@Override
public Collection getApplicableAttributes() {
    return ALL;
}

@Override
public void visitAttribute(XmlContext context, Attr attribute) {
    if (attribute.getValue().contains(SdkConstants.ANDROID_COLOR_RESOURCE_PREFIX)) {
        context.report(ISSUE, attribute, context.getLocation(attribute), "Using Android color resources are not recommended. Manufacturers are overriding them with other colors.");
    }
}

```

A vizsgálat 2 részből áll. A getApplicableAttributes() metódussal megmondod, melyik attribútumokat szeretnéd vizsgálni, majd a visitAttribute() metódusban megvizsgálod ezeket.

Mivel túl sok attribútum van, ahol szín szerepelhet, ezért nem lettek felsorolva. Az attrs.xml fájlba kell beleírni, hogy egy view attribútuma mit tartalmazhat. A [beépített attrs.xml](https://raw.githubusercontent.com/aosp-mirror/platform%5Fframeworks%5Fbase/6c7776ffe2f2e2d95e5c6794e97016b40dd3f946/core/res/res/values/attrs.xml?ref=blog.fps.hu) hatalmas. Bármelyik elem, amelyik color vagy reference lehet azt vizsgálni kéne. Ha nagyon fontos a sebesség, akkor még a leggyakrabban használtakat elég lenne ellenőrizni.

A visitAttribute() metódusban van a vizsgálat. Ha az attribútum értéke tartalmazza az **@android:color/** Stringet, akkor jelentünk egy hibát. „Jelentünk” a megfelelő szó, mert ez lehet egy tooltip lesz az Android Studio-ban, vagy a generált HTML jelentésben lesz csak benne. A hívásnak átadjuk az Issue-t, a hiba hatáskörét jelző attribútumot, annak helyzetét és a hiba leírását.

Ahhoz, hogy megtalálja a Lint ezt a szabályt, kell egy Registry:

```java

public class IssueRegistry extends com.android.tools.lint.client.api.IssueRegistry {
    @Override
    public List getIssues() {
        return Arrays.asList(
                ColorDetector.ISSUE
        );
    }
}

```

A Lint IssueRegistry osztály getIssues() metódusát írjuk felül. Itt adod meg a szabályok listáját. Ennek az osztálynak kell szerepelnie a build.gradle fájlban is.

### Használat

Ezután a lintChecks konfigurációval lehet berakni a függőségek közé. Én felraktam GitHubra majd JitPack segítségével hivatkoztam rá a projectünkben:

```java

buildscript {
    repositories {
        maven { url "https://jitpack.io" }
    }
}

dependencies {
    lintChecks 'com.github.fpshu:android-lintrules:master-SNAPSHOT'
}

```

Így bármelyik projektbe be tudom könnyen illeszteni.

### Zárás

Ez a kis szabály nem teljes, ugyanis kódban és styles.xml-ben nem keres. A fentiek alapján viszont könnyen kiegészíthető és építhetőek rá más szabályok.

Már írtam is hozzzá egy másik fájdalmasat, ami a drawable xml fájlokat vizsgál. Minden shape típusú drawable fájlnak kötelező hátteret adni <solid> taggel, kivéve, ha gradiens. Ha nem teszed, akkor a gyártó által megadott alapértelmezett hátteret fogja használni, ami lehet fekete, átlátszó vagy bármi.  
Ez már segített is felfedezni egy hibát anélkül, hogy futtatni kellett volna az alkalmazást, így biztosan megérte.
### VS Code, az új kedvenc
URL: https://blog.fps.hu/az-idealis-kodszerkeszto-visual-studio-code/
Last updated: 2026-07-17T08:26:31.000Z
Ha kódolásra adod a fejed, elkerülhetetlen, hogy valamilyen kódszerkesztőt vagy IDE-t használj. A minimalista szerkesztőtől a robosztus fejlesztői környezetig széles a paletta, ami ráadásul folyamatosan változik, így mindig jön valami új, ami esetleg jobb vagy másabb az előzőek tekintetében. Személy szerint azt vallom, hogy érdemes mindig kipróbálni az új lehetőségeket is, sosem tudhatjuk, mikor találunk egy jobb eszközt, mint az aktuálisan használt.

### Az IDEális kódszerkesztő

Ha a szépség relatív, akkor a tökéletes editor is. Ahány ember, annyi feature-request. De inkább hanyagoljuk is a kliséket. Számtalan paraméter határozza meg, hogy melyik a számodra megfelelő fejlesztőkörnyezet. Programnyelv, verziókezelő rendszer, külső függőségek, miegymás. Továbbá ott van a szubjektív megítélés, én személy szerint nagyon vártam anno az Atom megjelenését, ám amikor feltettem, lomhának éreztem, az egyik gyakran használt speciális karakter billentyű-kombinációjára rákötöttek valamit és annyira balul sült el az „első találkozás”, hogy azóta is hanyagolom. Pedig biztosan nagyon jó és nem véletlenül felkapott, mégsem erősítem az Atom-felhasználók táborát.

### Verébre ágyúval, ágyúra verébbel…

Számtalan esetben látom, akár kollégáknál is, hogy egy PHP fájlban egy érték átírásához megnyitja a PHPStorm-ot (a társított program miatt), kivárja, amíg az teljesen betölt, átírja az adott értéket, majd bezárja. Én ilyenkor rendszerint feszengek magamban, hogy miért is kellett ennyi idő és energia egy egyszerű művelethez. Az egyszerű feladatok, kis projektek esetén talán nincs mindig szükség a robosztus IDE megszámlálhatatlanul sok funkciójára, ugyanakkor a memóriát lefoglalja nekik. Az elmúlt 15 évben nem is tudom mennyi szoftvert használtam kódszerkesztésre, egy dolog azonban fix volt: a notepad++. A mai napig előszeretettel használom, és alapértelmezett szerkesztőként van beállítva.

Másik érdekes véglettel is szoktam találkozni, amikor valaki felsorolja a kódszerkesztője minden tudását, majd amikor szóba kerül, hogy mikor is használta utóljára, már kevésbé lelkes. Menő, hogy mindent (is) tud, de front-end fejlesztőként az a PHP ikon kihasználatlanul vár az eszköztáron arra, hogy megnyomja valaki véletlenül.

### Szerintem

Szeretem a moduláris dolgokat, szerintem logikus az elképzelés, hogy legyen egy váz, ami mindenkinek megfelelő és saját íze szerint alakíthatja azt olyan kiegészítők használatával, ami neki végül a legmegfelelőbb lesz. A könnyű bővíthetőség kulcsszempont és ha az alapok jók, a felhasználók szeretni fogják és motiváltak lesznek a bővítmények gyártására. Jó példa erre a Google Chrome is akár, ahol egy-egy Chrome Extension percek alatt összeállítható és minimális erőfeszítéssel bárki elkészítheti a sajátját.

### VS Code, az aktuális befutó

A Microsoft az elmúlt években igyekezett megválni a régen róla kialakult eltúlzott negatív képtől. Hiszen, amellett, hogy végre kiadott egy böngészőt, jelentősen nyitott az Open Source megoldások felé. Maga a Visual Studio is kedvelt szerkesztő, viszont amikor megjelent a kistestvére, a Visual Studio Code kifejezetten megörültem a dolognak és a többivel ellentétben, azonnal megszerettem azt. Feleslegesnek tartom felsorolni a [feature listát](https://code.visualstudio.com/docs/editor/whyvscode?ref=blog.fps.hu) vagy leírni ugyanazt, amit előttem már sok-sok cikkben megtettek, hogy ez miért is olyan nagyszerű.

Azt érzem, hogy amikor a VS Code készült, valóban figyelembe vették a fejlesztői igényeket. És mivel minden fejlesztő máshogy kódol, talán az okos univerzalitás lett a megoldás. Open source, ami dicséretes. Nem zabálja a memóriát és nem indexel be minden megnyitott fájlt feleslegesen és nincs tele olyan funkciókkal, amiket biztos, hogy sohasem fogok használni. Ugyanakkor eszméletlen sok kiegészítő készül hozzá, érthető és könnyű bővíthetőségéből adódóan. A kiegészítők által kényelmesen belőhetjük azt az állapotot, amikor már nem sima editor, de még nem is IDE amit használunk és minden a helyén van.

A kollégáim jórésze rábeszélés nélkül áttért már és függetlenül attól, hogy back-end vagy front-end fejlesztő, hatékonyan használja a mindennapokban. És még az Arduino-t is szereti:)

### Zárásként

Úgy gondolom, nem tudok és nem is akarok meggyőzni senkit arról, hogy mit használjon, hiszen olyan sokféle igény van és mindenki mást szeret. Ugyanakkor **nem egészséges, ha az eszköz határozza meg a munkafolyamatunkat és nem fordítva**.
### Kezdjük a Figmával!
URL: https://blog.fps.hu/figmaval-szep-az-elet/
Last updated: 2026-07-17T08:26:40.000Z
[Előző posztomban még csak kelesztettem,](https://blog.fps.hu/igy-neveld-a-kovaszod/) most gyúrok is kicsit a tésztán.

Valamikor a 2000-es évek elején nyitottam meg először az akkori tervezőgrafikusok legnépszerűbb programját, a QuarkXPress-t, hogy aztán fél óra múlva dühösen zárjam be, és töröljem is egy életre. Mi az, hogy addig nem tudok színt adni egy objektumnak, amíg nem adok nevet a színnek?! Nevet adni a színnek?! Van neki. C 0, M 64, Y 100, K 0… És így, továbbpuffogtam magam spirálisan az első perctől a bezárás pillanatáig.

Több mint 15 éve történt, ám még most is emlékszem rá, ahogy ez lenni szokott velem, amikor nagyon magabiztos és okos vagyok, a végén pedig kiderül, hogy a hülye is jómagam voltam. A katartikus csalódásokat és a lassú felismeréseket nehezen felejtem. Senki nem mondta el, hogy az én érdekem az elnevezés, hogy így tudok egységes maradni, és nem húsz pirossal dolgozni, fejben tartani, félreütni, újra és újra átnézni, és aztán előröl kezdeni egy másik munkán az egészet.

![quark-screen-2](https://blog.fps.hu/content/images/2017/11/quark-screen-2.jpg)  
*A képen, egy 2000-es évek elején népszerű tördelőprogram, a QuarkXPress 4.1-es felülete látható.*

Ha rendszert építesz, akkor megérted a korlátokat, és elfogadod, mert tudod, hogy a gridek, a színek, ikonok, azok csak alrendszerek, amelyek együttesen alkotnak majd egy egészet. A szabályok pedig, amiket a rendszerek környezete is alakít, nem felülírható, bosszantó dolgok, hanem iránymutató világítótornyok. Ezek segítenek a tervezés folyamatában, és ha követed őket, akkor növelik a projekt hatékonyságát és az elkészítés sebességét. Az újbóli felhasználhatóság és a konzisztens tervezés olyan gondolkodást alakít ki, ami a későbbiekben lehetővé teszi számunkra, hogy jobb digitális termékeket alkossunk. Hatékony felhasználás esetén projektjeink skálázhatók és könnyebben átláthatók lesznek.

Ám ahogy előző posztomban is említettem – most is csak megerősíteni tudom –, itt most nem arról lesz szó, hogy mi a [design rendszer,](https://medium.com/eightshapes-llc/a-design-system-isn-t-a-project-it-s-a-product-serving-products-74dcfffef935?ref=blog.fps.hu) [miért lesz szükséged rá,](https://medium.com/@marcintreder/design-systems-sprint-0-the-silver-bullet-of-product-development-8c0ed83bf00d?ref=blog.fps.hu) [hogyan építs csapatot köré,](https://medium.com/eightshapes-llc/designing-a-systems-team-d22f27a2d81d?ref=blog.fps.hu) [miért beszél mindenki erről,](https://www.designbetter.co/design-systems-handbook?ref=blog.fps.hu) hanem sokkal inkább arról, hogy van egy jó eszközünk, a Figma, ami segít ennek a gondolkodásnak az elsajátításában és használatában. Habár ahogy a Quark is csak egy eszköz volt, a Figma is csak az marad, és inkább a korszellem határozza meg, hogy miben építkezel. A lényeg mindig ugyanaz marad: *lásd az elejétől a rendszer születését, a folyamatot, a változtatásokat, és *merd kidobni az egészet, majd újrakezdeni,* ha szükséges.*

### Alapok

Ha nem ismered még annyira a Figmát, az se baj, mert könnyen bele lehet jönni, főleg ha láttál már előtte hasonló felülettervező programot. [Itt nagyon könnyen emészthető videók](https://help.figma.com/?ref=blog.fps.hu) magyarázzák el a program működését és a benne rejlő lehetőségeket. Ezeket érdemes végignézned mielőtt elkezded, de a továbbiakban is fogsz találkozni innen belinkelt tartalommal, mert olyan jól írták meg a saját helpjüket, hogy azon felül felesleges többet magyarázni.

#### Leltár

Mit leltározzak?! Most épül a rendszer!

OK, akkor csak kezd el összeírni mire van szükséged. Mik azok, amiket majd használni fogsz? Csak készítsd el a listádat, hogy mikre lesz szükséged a következő projektedhez, miket használtál már eddig, és szoktál használni a munkád során. Ezek azok a részek, amikor az elkészítés folyamatát és menetrendjét határozod meg.

Tipp: Sose spórold ki ezt a lépést, mert ahányszor rájössz, hogy valamit elfelejtettél, annyiszor fog anya leküldeni a boltba. Ezen felül ez a ráhangolódás időszaka, amikor még minden lehetséges. Élvezd ki ezt az állapotot!

Mi a leltárhoz sokszor a [Checkvistet](https://checkvist.com/?ref=blog.fps.hu) használjuk, mert gyors, egyszerű és átlátható, de ha inkább táblázatos vagy, akkor ott a jól bevált Spreadsheet.

#### Elnevezések

A szokásos elnevezési kérdés. Nagyvonalúan beszélek róla, de a mai napig nekem is nehézséget jelent megtalálni a magyar, a hunglish, az angol között a csapásirányt. Ha biztosra mész, egyeztetsz a leendő fejlesztővel, hogy amikor exportokat készítesz, már ne legyen több dolgod, csak a kimeneti beállítások megadása.

Minta: **form-input-select-open** *azaz* **alrendszer neve - elem típusa - elem tulajdonsága - elem állapota**

Tipp: Én előszeretettel használom a kötőjelet, de a mobilosok az aláhúzást kedvelik, mások pedig inkább a per jelet részesítik előnyben.

### Grid, az első alrendszer

Ez a te kockásfüzeted. Komolyan. Ritmust ad, segíti az igazodást, és meghatározza a leendő elemek elhelyezkedését, viszonyát és még a kinézetét is. Egyszóval segít, hogy ne csak a levegőbe rajzolgassunk a tizedik képernyő után.

#### Keret

Ahhoz, hogy legyen majd egy gridrendszered, először ki kell választani, mire tervezel.

Korábban, még a leltár fázisa előtt már kikutattuk, felmértük és meghatároztuk – így az egyszerűség kedvéért most csak egy mobilapp lesz a projekt végkimenetele. Szűkítsük ezt is tovább. Csak álló megjelenés és nem kell tablet verzió. Android a fő felhasználási csoport, azon belül is a tavalyi év nagy nyertese a Huawei P8 Lite felhasználóit célozzuk meg. Így máris van egy képméretünk 720×1280 pixel. Ennek csak a felét fogjuk beállítani [**a frame méretének,**](https://help.figma.com/editor/1322329-toolbar/frame-tool?ref=blog.fps.hu) mert majd a későbbi exportok során lehetőségünk lesz *0,5x-, 0,75x-, 1x-, 2x-, 3x-, 4x-es* méretek kimentésére is.

Tipp: Mindig egyeztess a fejlesztővel, hogy mire van szüksége a munkájához, mert az exportok beállításait könnyebb neked elvégezni.

Nevezd el, a keretet is. Legyen a neve: *UI-grid-mobile.* Ezután jöhet a belső szerkezetet. Margók, oszlopok, sorok. Olyan ez, mint a tördelés. Mielőtt belemennél a technikai részletekbe, ismét egy döntést kell hoznod. Milyen típusú rácsszerkezetet fogsz használni? [8 pontosat,](https://builttoadapt.io/intro-to-the-8-point-grid-system-d2573cde8632?ref=blog.fps.hu) [reszponzívat](https://medium.com/re-write/designing-a-responsive-grid-in-2016-58e4db6db786?ref=blog.fps.hu) vagy [flexibiliset?](https://aerolab.co/blog/flexbox-grids/?ref=blog.fps.hu) A lényeg, hogy tájékozódj, és készülj fel a későbbi méretekből, hogy ne érjenek meglepetések.

Tehát 360×640 pixel a méretünk. Én a 8 pontos rácsszerkezettel kezdem el a munkát, hisz Androidos mobiloknál ez könnyebbségnek számít.

- 4 oszlopos elrendezés
- 16 pixeles közökkel
- 16 pixeles margók
- automatikusan 70 pixeles oszlopszélességek jönnek ki

![ui-grid-mobile-1](https://blog.fps.hu/content/images/2017/11/ui-grid-mobile-1.gif)

Tipp: Olvasd el [a Help ide vonatkozó részét,](https://help.figma.com/properties-panel/layout-grids?ref=blog.fps.hu) ahol jól összeszedték, hogyan használd, és mik a lehetőségek a rácsokkal kapcsolatban.

*folyt. köv.*

*A jövő heti cikkben:*  
Annyira elment az idő a novemberben megjelent design system cikkek és tanulmányok olvasásával, hogy a színekről inkább a következő posztban lesz szó, a tipográfiával és a komponenskezeléssel együtt.
### Nyelv- és régióválasztók tervezése
URL: https://blog.fps.hu/nyelv-regiovalasztok-tervezese/
Last updated: 2026-07-17T08:26:50.000Z
Egy korábbi projektünk nyelvesítése során felmerült az igény, hogy tervezni kell egy nyelvválasztót a meglévő oldalra. Az igények pontosítása után régióválasztó lett a vége. Ennek apropójából összegyűjtöttem a fő szempontokat, melyek felmerültek a tervezés során és neked is segítségedre lesz, ha hasonló feladat előtt állsz.

### A különbség nyelv- és régióválasztó között

Nyelvválasztóra van szükség, ha az oldal tartalma több nyelven is elérhető úgy, hogy az országspecifikusan nem változik. Tegyük fel, ha egy szolgáltatás több országban is jelen van és a weboldaluk tartalma országtól függően változik, akkor régióválasztóra van szükség. Ha egy területre vonatkozó tartalmat több nyelven is elérhetővé teszel, akkor pedig mindkét funkcióra szükséged lesz.

Abban az esetben, ha a szolgáltatás egy nemzetközi webshop, akkor akár egy adott területen preferált valuta kiválasztását is érdemes lehet integrálni.

### Átirányítás egy kezelhető nyelvre

Sok esetben fel sem tűnik, ha egy nemzetközi oldalra tévedsz, mert már egy számodra érthető nyelvű változatot böngészel.

Ez megoldható a felhasználó böngészője nyelvének detektálásával. A böngésző a telepítés során az eszköz OS nyelvét veszi alapértelmezettnek, ami egy jó kiindulási pont. Felmerül viszont az a helyzet, amikor valaki külföldön egy kölcsön kapott vagy nyilvános eszközön böngészik.

Az automatikus átirányításnál érdekes szituáció, amikor egy olyan nyelvű változat töltődik be a böngésző alapján, ahol csak limitált funkciók és tartalom érhető el. Ilyen esetben érdemes informálni a felhasználót, hogy a teljes tartalmat az adott nyelveken éri el. Így, ha nem is beszéli a nyelvet, egy Google fordító segítségével ha fapadosan is, de gyorsan érthetővé válik számára a tartalom.

**Ez okból mindig biztosítani kell a felhasználónak, hogy beállíthassa saját preferált nyelvét!**

### Fontos az elérhetőség

A nyelv- és régióválasztó ideális esetben rögtön az oldalra érkezéskor elérhető, mivel amíg nem választották ki a megfelelő nyelvet vagy területet, addig a releváns tartalmak száma igen csekély. Véleményem szerint célszerű a fejlécen elhelyezni, azon belül is a jobb felső sarokban vagy első menüpontként.

![nyelvválasztó oldal az Ikea kezdőlapján](https://blog.fps.hu/content/images/2017/10/kep7-3.png)

*részlet az Ikea kezdőlapjáról*

Nagyobb nemzetközi oldalaknál, mint például az [Ikea](http://www.ikea.com/?ref=blog.fps.hu) jól működik, hogy a látogatók kezdésként egy nyelvválasztó oldalra érkeznek, ahol kiválaszthatják a számukra releváns területet és nyelvet.

### A megfelelő kialakítás kiválasztása

Hogy hogyan jelenjen meg egy funkció az oldalon az mindig az adott kontextustól és stratégiától függ. A listázandó nyelvek/területek darabszáma viszont jó kiindulási pont lehet.

- Rövid lista esetén az összes linket kiteheted az oldalra, anélkül, hogy az zavarná a fő tartalmat. ISO kódok (lásd lejjebb bővebben) segítségével minimálisra csökkentheted a nyelvválasztók helyigényét. Ha stratégiailag fontos a nyelvválasztó, akkor hosszabb lista is megjelenhet teljes terjedelmében az oldalon. (Pl.: [Wikipedia](http://hu.wikipedia.org/wiki/Kezd%C5%91lap?ref=blog.fps.hu))
- Hosszabb lista esetén egy lenyíló menü működőképes lehet. Sok hely nyerhető vele, viszont a lista tartalma így (egy kattintásnyira) rejtve marad a felhasználótól. Lenyíló menü esetén zárt állapotban mindig az aktuálisan kiválasztott nyelv látható, ami bizonyos esetekben nem mindig érthető vagy utal a nyelvválasztó funkciójára. Ebben az esetben egy jól megválasztott ikonnal egyértelművé tehető a helyzet.
- Nagyon hosszú lista esetén egy görgetést igénylő lenyíló menü nagy mértékben nehezíti az átláthatóságot és a kiválasztást, így ebben az esetben célszerű egy külön oldalon kezelni a nyelv- illetve területválasztást. Területválasztóknál könnyítheted a lista átláthatóságát földrészek vagy régiók szerinti csoportosítással. (Pl.: [Apple](http://www.apple.com/choose-your-country/?ref=blog.fps.hu), [Adidas](http://www.adidas.hu/country-selector.html?ref=blog.fps.hu), [Nike](http://www.nike.com/language%5Ftunnel?ref=blog.fps.hu))

### Listázás

Nem szerencsés egy-egy nyelv vagy ország kiemelése a listán belül. Célszerű minden listaelemet azonos prioritásúként kezelni és ABC sorrendet alkalmazni. Így a lista kiszámíthatóvá és könnyen átláthatóvá válik.

![a Burton és a 3M régióválasztója](https://blog.fps.hu/content/images/2017/10/Frame-2.9-2.png)

*az ábrán balra a Burton és jobbra a 3M régióválasztója látható*

Fontos, hogy minden országot és nyelvet a saját nyelvén jeleníts meg! Így mindenki a számára érthető formulával találkozik. Például nyelvek esetén „Deutsch, English, Magyar”, országoknál „Deutschland, England, Magyarország”.

Országválasztónál célszerű egyesével kilistázni az adott országnál elérhető nyelvváltozatokat. Így például Svájc esetében „Schweiz - Deutsch; Suisse - Français; Svizzera - Italiano; Switzerland - English”.

### Legyen felismerhető

![a földgömb ikon alkalmazása nyelv- és területválasztó jelölésére](https://blog.fps.hu/content/images/2017/10/Frame-2.8A.png)

A felső vagy az alsó sorban találod meg hamarabb a nyelvválasztót?

Egy jól megválasztott ikonnal nagy mértékben segíthető a funkció megtalálása az oldalon. Annak ellenére, hogy a földgömb ikon inkább helyzetre utal, gyakran alkalmazzák egyaránt nyelv- és területválasztó jelölésére is. Voltak törekvések [egyezményes nyelvválasztó ikon](http://www.languageicon.org/?ref=blog.fps.hu) tervezésére, ám nem sok oldalon lehet találkozni vele.

### ISO kódok

Ha egy nyelvet vagy országot rövidítve szeretnél kilistázni, akkor célszerű az egyezményesen elfogadott ISO kódokat alkalmazni. Külön kódlista érhető el a [nyelvek](http://hu.wikipedia.org/wiki/ISO%5F639-1%5Fnyelvk%C3%B3dok%5Flist%C3%A1ja?ref=blog.fps.hu) és az [országok](http://hu.wikipedia.org/wiki/ISO%5F3166-1?ref=blog.fps.hu) számára. Fontos, hogy ne keveredjen a két lista, ugyanis vannak egyező karakterkódok, melyek különböző tartalmat takarnak. Például „CA” Kanadát jelöli, míg „ca” a katalán nyelvet.

Országok esetében csupa nagy, míg nyelvek esetében csupa kis betűvel írandók. Ha egy adott országhoz nyelvet is szeretnél csatolni, akkor előbb a nyelv, majd az ország ISO kódját kell megadni. Például az amerikai és a nagy-britanniai angol esetében en-US, en-GB.

### Zászlók használata

Gyakran felmerül a kis zászló ikonok használata a lista hangsúlyozása érdekében. Nyevválasztó esetén ez nem lehetséges, ugyanis egy nyelvet nem minden esetben lehet reprezentálni egy zászlóval. (Pl.: ha a német nyelv esetén Németország zászlaja kerül ki, az nem biztos, hogy elsöprő sikert arat Ausztriában vagy Svájcban.) Emiatt szerencsésebb a pusztán szöveges listánál maradni.

Országválasztók esetében már más a helyzet, ugyanis itt a zászlók használata releváns (egyenesen köthetők egy országhoz) és segíthetnek a funkció megértésében. Fontos, hogy a zászlók mellett mindig jelenjen meg a szöveges kiírás is. Sokan nem ismerik eléggé a zászlókat és a kis ikonok mérete is nehezítheti a megértést.

![magyar és osztrák zászlók színesen és protanopia esetén](https://blog.fps.hu/content/images/2017/10/Frame-2.3-2.png)

A színvakok és színtévesztők számára pedig kisebb kihívás szöveges segítség nélkül megkülönböztetni egymástól példaként a magyar és osztrák zászlót.

![Stilizált zászlós országválasztó a Burton oldalán](https://blog.fps.hu/content/images/2017/10/Frame-2.2.png)

Stilizált zászlók országválasztók esetén időnként jól működhetnek ikonként, ahogy a Burton oldalán is látható.

### Összegzés

A funkció tervezése minden esetben kontextus és projektfüggő, így a felsorolt szempontok inkább gondolatébresztőként szolgálnak a körbejárandó kérdésekkel kapcsolatban.
### Static is the new dynamic
URL: https://blog.fps.hu/static-is-the-new-dynamic/
Last updated: 2026-07-17T08:27:01.000Z
Réges régen, úgy a nyolcvanas évek vége felé elindult valami, ami teljesen felforgatta a világot. Úgy hívjuk, a Világháló. Eleinte egyszerű HTML dokumentumok laktak a szervereken, amiket a kliensek letölthettek a böngészőjükkel és elolvashatták a beléjük hardcode-olt tartalmakat. Aztán felmerült az igény, hogy a távoli szervereken a hozzájuk kapcsolódó kliensek mindenféle szerveroldali programokat futtathassanak. Tudjanak keresni, bejelentkezni, kommentelni. A weboldalak üzemeltetői is rájöttek, hogy a tartalmakat nem érdemes HTML doksikban tárolni. Megszületett a dinamikus web. A statikus HTML fájlokat Perl scriptek váltották le, amelyek dinamikus válaszokat generáltak a bejövő kérésekre. A scriptek adatbázisokhoz kapcsolódtak, ahol az adatokat tárolták.

Egészen jól működött a dolog, de kiderült, hogy mindez elég sok számítási kapacitást igényel. A szerverek nem bírták, a web belassult. Ezért elkezdtek gyorstárazni. A webszerverek gyorstárazták a scriptek kimeneteit, azok pedig az adatbázis-lekérdezések eredményeit, így sokkal gyorsabbá vált a dokumentumok generálása és a számítási kapacitás problémaköre is megoldódni látszott. Igaz, nem mindent lehetett gyorstárazni, de azért összességében így is nagy előrelépés volt. Közben megjelent a JavaScript, ami lehetővé tette, hogy bizonyos dinamikus funckciókat megvalósító scriptek ne csak a távoli szervereken, hanem a böngészőkben is futhassanak. A kétezres években elterjedtek a tartalom elosztó hálózatok, amelyek tovább gyorsították a tartalmak elérését.

A webes technológiák hatalmas fejlődésen mentek keresztül ezt követően is, kliens- és szerveroldalon egyaránt. Alapjaiban azonban a weboldalak jelentős része ma is így működik.

![old-stack](https://blog.fps.hu/content/images/2017/10/old-stack.png)

### Mi a baj a mai tartalomkezelő rendszerekkel?

A hagyományos tartalomkezelő rendszerek használatának elsődleges oka a tartalom egyszerű változtathatóságának az igénye.

Ehhez először is kell egy admin felület, ahol a szerkesztő fel tud tölteni egy új blogbejegyzést. Az admin felületen keresztül az adatok bekerülnek az adatbázisba. Amikor valaki meglátogatja a weboldalt, a szerveren generálunk egy HTML dokumentumot az adatbázisban található adatok alapján. Így működik például a WordPress, de majdnem minden CMS.

#### Teljesítmény

A probléma a következő: Ha öten olvassák el az adott bejegyzést, akkor ötször állítjuk elő nulláról ugyanazt az oldalt, egymillió megtekintés esetén egymilliószor. Ezzel feleslegesen égetjük egyrészt a számítási kapacitásunkat, másrészt a látogatók idejét, mivel mindig meg kell várniuk, amíg az általuk kért oldalt legeneráljuk.

Erre az szokott lenni a válasz, hogy erre való – többek között – a page caching. WordPresshez is van egy csomó plugin, ami out-of-box megvalósítja ezt, szinte csak telepíteni kell. A sebesség valóban növelhető így, de ha belegondolsz, lényegében egy túlbonyolított kerülőúton keresztül jutunk el oda, hogy lesz egy static site generatorunk, amit egy olyan CMS-re építettünk, ami nem erre lett kitalálva. Ráadásul nem lehet minden aloldalt gyorstárazni, ezért csak félmegoldás.

#### Biztonság és fenntarthatóság

Biztonságos weboldalakat fejleszteni komoly szakértelmet igénylő, embert próbáló feladat. A hagyományos CMS-ek túlságosan nagy támadási felületet adnak a támadónak, mivel majdnem minden a szerveren, dinamikus feldolgozás mellett történik. Minél komplexebb a rendszer és minél nagyobb a támadási felület, annál nehezebb mindenre gondolni, átlátni az egészet, tehát könnyebb hibázni.

Egy komplex rendszert értelemszerűen üzemeltetni is nehezebb. A hagyományos CMS-ek esetében ez a feladat kifejezetten fájdalmassá válhat jelentősebb terhelés esetén. Mivel a gyorstárazás nem minden esetben oldja meg a teljesítménnyel kapcsolatos problémákat, a szerveroldalon jelentős számítási kapacitásra van szükség. Ugyanakkor a sessionökre épülő, tehát nem-állapotmentes felépítésű rendszerek nehézkesen skálázhatóak.

### A megoldás: JAMStack

Egy modern architektúra, amely azzal a céllal jött létre, hogy ezeket a problémákat felszámolja. Egy szemléletmód, egy megközelítés. Nem egy konkrét framework, nem konkrét technológia, csak egy iránymutatás, amely három fő alapelv mentén segít jobb weboldalakat fejleszteni.

![jamstack-1](https://blog.fps.hu/content/images/2017/10/jamstack-1.png)

#### 1\. JavaScript

Minden, ami dinamikusan történik, az történjen a böngészőben! Használhatsz bármilyen JavaScript frameworköt, a lényeg, hogy a dinamikus funkciók kliensoldalon valósuljanak meg, ne a szerveren. Érdemes valamilyen reaktív keretrendszerben gondolkodni, ami képes gyorsan renderelni, mint például a személyes kedvencem, a Vue.

#### 2\. API(s)

A kliensoldalon futó szkriptek támaszkodjanak mikroszolgáltatásokra. Onnan töltse be a kommenteket, azon keresztül lehessen hozzászólást írni, oda küldje be a webshop a rendelést, azon keresztül valósuljon meg a webhelyen belüli keresés, és így tovább.

Maga a tartalom is jöhet egy API-tól. Ehhez egy headless CMS-re lesz szükséged. Ezek olyan tartalomkezelő rendszerek, amelyek a hagyományos társaikhoz hasonlóan rendelkeznek admin felülettel, ahol validálnak, letárolnak, feldolgoznak, szóval a szokásos. Amiben viszont különböznek, hogy nem mondják meg, hogy hogyan kell megjelenítened az ott felvitt tartalmakat. Egy API-n keresztül teszik elérhetővé számodra, innentől azt csinálsz az adatokkal, amit akarsz. Nem kell hackelned.

Backenden általában csak annyi dolgod van, hogy megmondd, hogyan épül fel a tartalom. Milyen mezőkből áll egy blogbejegyzés, hogyan kell validálni ezeket a mezőket. Minden mást megoldanak helyetted.

Egy ilyen eszközzel minden projektnél célspecifikus admin felületet tudsz kialakítani, ahol a szerkesztők ugyanolyan egyszerűen vihetik fel a tartalmakat, ahogyan eddig is tehették például WordPress alatt (sőt, akár annál egyszerűbben, célspecifikusabb felületen). Külön cikket érdemelne a téma, a lényeg, hogy a fejetlenség ebben az értelemben nagyon jól jön nekünk.

Ezeket nem kell feltétlenül neked hosztolnod, kommentekre például használható a Disqus, keresésre a Google Custom Search vagy az Algolia, tartalmak kezelésére a Contentful.

#### 3\. Markup

A site aloldalai legyenek előre legenerált statikus fájlok a szerveren. Sőt, ha már statikusak, mehetnek egyből a CDN-re. Erre a célra érdemes valamilyen SSG-t (Static Site Generatort) használni. Jekyll, Hugo, Hexo és társaik.

Ezek az eszközök arra lettek kitalálva, hogy – ahogy az elnevezésükből már gyanús lehet – statikus weboldalakat generáljanak tartalmakból és egy sablonból. Technikailag az egész nem nagyon különbözik attól, amikor egy hagyományos CMS agresszív page cachinget használ. A végeredmény ugyanaz: lesz egy teljesen statikus weboldalad, azzal a különbséggel, hogy ezek a rendszerek direkt erre a célra lettek kifejlesztve.

A tartalom, ahogy már említettem, jöhet egy API-tól, de bizonyos projekteknél az SSG világban megszokott hagyományos, fájlrendszerben tárolt markdown fájlos megoldás is szerencsés lehet, vannak előnyei. Azonban ha egy projekt megköveteli, hogy a webfejlesztőkön kívül mások is tudjanak módosítani a tartalmakon, ez utóbbi lehetőség nehézkes lehet, ugyanakkor van még valami, ami az API mellett szól: az izomorf renderelés lehetősége (isomorphic rendering).

Az isomorphic rendering lényege, hogy egyszerre renderelünk kliensoldalon és szerveroldalon, így ötvözve a kettő előnyeit.

Dióhéjban a szerveroldal mellett szólnak a következők:

- Time-To-Content. A kattintástól a tartalom megjelenítéséig eltelt idő rövidebb, mivel a dokumentumban ott van egyből a tartalom is. Kliensoldali renderelés esetén a lapletöltés után még külön le kell kérdezni a tartalmat is.
- SEO. A keresőrobotok még 2017-ben sem várják meg, hogy az aszinkron szkriptjeid lefussanak.

A kliensoldal mellett pedig ezeket tudom felhozni:

- Alacsonyabb sávszélesség igény. A második lapletöltéstől kezdve gyakorlatilag már csak a tartalmat kell cserélgetni a böngészőbe már betöltött weboldalon, a kód többi részét tehát nem kell újra letölteni.
- Lazy Loading. Elég a tartalomnak csak azt a részét letölteni, amire az adott szituációban valóban szükség van.
- Felhasználói élmény. Két blogbejegyzés között nem tölt újra az oldal, lehetőséged nyílik átvezetésekre, animációkra, azonnali visszajelzésre, hogy valami történik. [A gyors működés illúziója.](https://blog.kolboid.eu/gyors-mukodes-illuzioja-sebesseg-erzet/?ref=blog.fps.hu)

Ezek alapján látható, hogy sebesség szempontjából az lenne az ideális, ha az első lapletöltéskor egy szerveren renderelt dokumentumot kapnának a kliensek, a további „lapletöltések” esetén viszont már kliensoldalon jelenítenénk meg a tartalmat. Az egyetlen programnyelv ma, ami erre képes, az a JavaScript.

A jó hír az, hogy szinte minden népszerű framework esetén van hová nyúlni. Angular -> Universal. React -> Next. Vue -> Nuxt. A JAMStack azonban azt is előírja, hogy az on-the-fly szerveroldali renderelés kerülendő, tehát nem történhet valós időben. Szerencsére ezek az eszközök képesek arra is, hogy statikus weboldalakat generáljanak a JavaScript kódunkból.

### Hogyan segít mindez?

Könnyen beláthatjuk, hogy a statikus weboldalakat sebesség szempontjából nem lehet felülmúlni. Talán csak egy olyan statikus site lehet rá képes, ami izomorf megjelenítést használ.

A weboldal statikus mivoltának és a szerveroldali dinamikus folyamatok mikroszolgáltatásokba történő becsomagolásának köszönhetően a támadási felület lényegesen kisebb, mint egy hagyományos, „monolitikus” felépítésű tartalomkezelő rendszer esetében. Az egyszerűbb felépítés egyszerűbb üzemeltetést tesz lehetővé, tehát kisebb a hiba lehetősége is.

Az egyszerű architektúra fenntarthatóság szempontjából is szerencsés. Bármeddig szabadon és könnyedén skálázható, nem tudod kinőni. A hagyományos felépítésű rendszerekhez képest lényegesen kisebb erőforrásigényű és kevesebb szakember kell hozzá, így olcsóbb.

Egy ilyen weboldalt fejleszteni is könnyebb, mert sokkal fókuszáltabb fejlesztést és tesztelést tesz lehetővé. A frontend teljesen leválik a backendről, az API-k újrafelhasználhatóak. Könnyen le tudod cserélni fölötte a frontendet, ha akarod. A headless CMS nem szab gátat semmilyen elképzelésnek, nem üti bele az orrát a frontendhez tartozó feladatokba.

### Végszó

Egy meglehetősen új dologról beszélünk, amely még épp csak a szárnyát bontogatja, mégis – és ez a szubjektív véleményem – nehezen tudom elképzelni, hogy ne ez legyen a következő paradigmaváltás a jó öreg World Wide Web történetében. Ehhez arra van csak szükség, hogy mi, fejlesztők legyünk nyitottak rá és állítsuk át az agyunkat erre a megszokottól kissé eltérő gondolkodásra.

Ha szeretnél komolyabban elmélyülni a témában, a következő linkeket ajánlom a figyelmedbe:

- [JamStack.org](https://jamstack.org/?ref=blog.fps.hu)
- [Mathias Biilmann: The New Front-end Stack.](https://vimeo.com/163522126?ref=blog.fps.hu)
- [Top Open-Source Static Site Generators](https://www.staticgen.com/?ref=blog.fps.hu)
- [Content Management Systems for JAMstack Sites](https://headlesscms.org/?ref=blog.fps.hu)
- [Why Client-side Rendering Won](https://medium.freecodecamp.org/heres-why-client-side-rendering-won-46a349fadb52?ref=blog.fps.hu)
- [How to Bundle Cockpit CMS & Nuxt.js in a full JAMstack](https://snipcart.com/blog/cockpit-cms-tutorial-nuxtjs?ref=blog.fps.hu)
- [The New Dynamic](https://www.thenewdynamic.org/?ref=blog.fps.hu)
### Így neveld a kovászod
URL: https://blog.fps.hu/igy-neveld-a-kovaszod/
Last updated: 2026-07-17T08:27:11.000Z
*1906\. április 18-án percekkel a hajnali nagy földrengés után, Marie Louise Boudinnak sikerül kimentenie az anyakovászt a már lángokban álló pékségéből. Azt a kovászt, amit ekkor már 57 éve óvtak, ápoltak és növesztettek, hogy olyan kenyeret süssenek, amiről még én is hallottam itt a világ túl felén. A mai napig ebből a kovászból sütik a kenyereket a San Franciscó-i pékségben…*

2017 elején, céges szinten tértünk át a Figmára, előnyével és – inkább – kellemetlenségeivel, mint hátrányaival. Az eddigi használat során új gondolkodás is jött, és ha még nem is oldódott meg [a pont egy évvel írt posztomban](https://blog.fps.hu/hogyan-segitsd-a-fejlesztot-1/) felsoroltak mindegyike, de legalább jöttek mellé újabb kihívások.

A [céges változások](https://blog.fps.hu/hazassag-fps-webugynokseg-virgo-creative-magyar-digitalis-piac-fps-ugynokseg/) miatt elengedhetetlen volt számunkra a szorosabb és könnyen átvehető–, folytatható munka, így tettük le a voksunkat a Figma mellett, de ki tudja, lehet, hogy belekóstolunk majd az InVision Studiójába is jövőre.

Innentől bármennyire is igyekszem, kénytelen leszek angol kifejezéseket is hasznáni, mert oly gyorsan jönnek, terjednek és kopnak ki az itt használt fogalmak, hogy a magyar nyelvben megtapadni sincs idejük.

### Volt egyszer egy UI Kit

Már style guide, de még nem design system.

Én annak az „iskolának” vagyok a képviselője, akik szerint a tervezési rendszer nem csak felületi elemek dokumentált rendszere, hanem az, ahogy egy csapat képes együtt dolgozni. Ahol közös a fogalomtár, és mindenki érti, hogyan épül és működik a termék. Ezt a közös tudást pedig később képes átültetni egy másik produktumba is. No, az már rendszer! A témában [Nathan Curtis írásai](https://medium.com/@nathanacurtis?ref=blog.fps.hu) motiválnak leginkább.

Azért szögezzük le, hogy mostanság nagy a kavarodás, hogy mit hívunk **pattern library**\-nek, **style guide**\-nak, **design system**\-nek. Erre [itt találsz egy érthető és rövid írást,](https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/?ref=blog.fps.hu) a végén egy e-bookkal.

Így mindig egy egészséges távolságtartással nyitom meg a design system kifejezést tartalamzó cikkeket. Olykor nincsen mögötte valódi rendszer, csak szép komponensek és következetes grafika. A Figma – viszont nem is olyan rég – elindította az [1.0-ás Team Library-jét,](https://blog.figma.com/team-library-1-0-d1427092323a?ref=blog.fps.hu) amit egyesek tévesen már a design system küszöbeként aposztrofálnak. Szó se róla, nagyon meg fogja könnyíteni a tervezők dolgát, de a rossz hírem az, hogy ehhez meg kell dolgozni.

Azért csak eljutok oda, hogy miről is akar majd szólni ez a posztsorozat. Egy tweet hosszúságában elmondva: **Hogyan építsem fel és bővítsem az elemkészletemet, hogy a végén összeálljon egy rendszerré? Tippek és trükkök Figmához.**

### Ezek még csak összekötögetett komponensek

> Az nem úgy van, hogy megnyitod, átveszed és elolvasod (ha van mit). Ha nem te tervezted, építetted, formázgattad, akkor pont ugyanannyi a munkád vele, mintha nem lenne benne rendszer.

Azt szoktam mondani, hogy **egy jó style guide tervezése befektetés.** Befektetés, de megéri?Jöjjenek is a kérdések.

##### **Mekkora projektnél érdemes elkezdeni?**

Inkább fordítsuk meg. Mikor fog beérni, ha lesz egy olyan gondolkodással épített rendszered, amit bármelyik projektnél elővehetsz és utána csak testre kell szabnod? Ha egy terméket fejlesztesz, mindenképp. Ha több, különböző, de hasonló tematikájú és súlyú projekten dolgozol, akkor is. Ez utóbbinál inkább starter kitet fogsz építeni.

##### **Nem lesz sablonos?**

Csak amennyire hagyod, hogy az maradjon, hisz a material design kismillió változata létezik, de azon felül is találsz egyre több rendszert (pl.: [Carbon design system,](http://carbondesignsystem.com/?ref=blog.fps.hu) [Lightning design system](https://www.lightningdesignsystem.com/?ref=blog.fps.hu))

##### **Mennyi időt tudok vele spórolni?**

Semennyit. A felszabadult időt úgyis azzal fogod tölteni, hogy „csinosítgatod, pimpeled, animálod” a terméket. Ugye?

##### **Miért jó nekem, ha van egy nagy adag összekötögetett komponensem?**

Gondoltam ide írok majd egy hosszú bekezdést, de épp ma jött velem szembe [ez a cikk,](https://thenextweb.com/artificial-intelligence/2017/10/25/airbnb-ai-sketches-design-code/?ref=blog.fps.hu) ami tökéletesen elmondja, miért lesz jó neked. Majd. Egyszer. A köztes állomásokat meg gondold hozzá.

Tehát a jó kenyérhez 3 dolog kell. Víz, liszt, kovász.

> A kovász előtészta, amely liszt és víz felhasználásával, természetes élesztőgombák és tejsav-, ecetsavbaktériumok felszaporításával készül. Aktívnak nevezik a kovászt, amikor etetés után „dolgozni kezd”, vagyis akár duplájára is nőhet, és jól megbuborékosodik. Ekkor lehet vele szép kenyeret sütni.

Így vagyunk ezzel a design rendszer építéssel is. Kelesztgetni kell. Hol elvenni, hol hozzáadni, ám ami biztos, hogy rendszeresen foglalkozni kell vele. A legenda szerint Marie Louise Boudin a lángokban álló pékségéből kimentett kovászból már másnap sütötte a kenyeret, és rakta félre a maradékot a következő sütéshez, ahogy teszik ezt azóta is a Boudin pékség pékmesterei.

*Előzetes a következő cikkből:*  
Azt fogom bemutatni, hogyan építem fel a saját rendszerem, mik azok az apró trükkök, amik segítik, hogy egységes maradjon a terv. A kulcsszavak pedig: alapok, gridek, színek.

Ahonnan a jó sztorikat és az ötleteket vettem:

- [A Boudin pékség honlapja](https://boudinbakery.com/our-story/our-bread/?ref=blog.fps.hu)
- [Egy jó cikk, ami elindította a gondolatfolyamot.](https://mno.hu/migr%5F1834/kovasz-friscoban-468961?ref=blog.fps.hu)
- [Segít megérteni, a kenyér, a kovász, a sütés miértjét.](http://www.foodandwine.hu/2013/02/22/a-kenyersutes-biokemiaja-a-feher-haz-inasa-1887/?ref=blog.fps.hu)
- [Egy jó recept egy aktív kovászhoz.](http://www.nosalty.hu/recept/elesztomentes-kovasz-kenyerlisztbol?ref=blog.fps.hu)
### „Huncut kis álláshirdi volt” – és elég frusztrált 116 itthoni reklámos, ezt tudtuk meg.
URL: https://blog.fps.hu/reklamugynokseg-allashirdetes-kerdoiv-tapasztalatok/
Last updated: 2026-07-17T08:27:20.000Z
*(valós user idézet)*

Két hete érdekes álláshirdetést adtunk fel, mert reklámügynökségi részleget alapítunk Pesten, és ehhez grafikust keresünk. Jó embert viszont nehéz találni, szóval, bár nem elsőre, de eszünkbe jutott, hogyan kutassuk fel új kollegánkat. Természetesen trükköztünk, jöjjön a tanulság, ez itt a kert.

### Hosszú lesz, ezért elnézést, de kezdjük az elején.

Néhány hónapja nagy álmokkal érkezett hozzánk pár ember. Megszerettük őket, reklámos vénával jöttek, és mivel már bennünk is volt egy afelé nyiladozó szándék, hogy bővüljünk, és még jobban tudjuk segíteni a partnereinket, nagyon hamar megérett bennünk az elhatározás, hogy akkor innentől szeretnénk klasszikus reklámügynökséget is vinni.

Igen, nemcsak [fúzió](https://blog.fps.hu/hazassag-fps-webugynokseg-virgo-creative-magyar-digitalis-piac-fps-ugynokseg/), de még ez is. Egyrészt az ügyfeleink miatt, másrészt magunk miatt. Azt látjuk, hogy ezen a területen is elférne az, amit az fps ügynökség képvisel. Ehhez már csak az új grafikusunk hiányzott.

### Hibáztunk.

![Yeah, man.](https://media.giphy.com/media/x4byfQcJyFYR2/giphy.gif)

Azt csináltuk, amit már réges-régen megtanultunk, hogy ne csináljunk, és amit tanítunk és gyakorlunk, és nemcsak mi, de minden valamire való szakember is csinál és tanít, és amiről (is) szól minden workshopunk:

Hát csaknem gondoltuk végig, hogyan is kéne nekiállni a dolognak. Mert ugye, ahogy BÁRMILYEN PROBLÉMÁNÁL, elcsépelt, de mégiscsak illett volna használni a design thinking alapokat, nem?

Szóval hibáztunk, feladtunk egy sima álláshirdetést, mert ember kellett és kész. Tudjátok, amit mindenki csinált volna. Aztán jól nem is működött.

### Mit akartunk?

Természetesen azt, ha jó gyorsan, jó megoldást találunk volna. Hogy MEGFOGALMAZZUK A CÉLUNKAT (kell ember!) mondjuk hétfőn, FELADJUK a hirdetést (hé! ember kell) mondjuk szerdán, és akkor például péntekre MEGTALÁL minket az ÁLOM EMBER, és akkor hétfőn MÁR VÁLTHATJUK IS MEG A VILÁGOT.

Aztán mi lett? Jó, persze túlzunk, nem pont ezt hittük, de azért azt se, hogy se nem gyorsan, se nem talál ránk egyáltalán az emberünk.

### Amit kifelejtettünk?

Megkeresni az igazi feladatot. Arra mondjuk egész hamar rájöttünk, hogy mivel eddig nem voltunk reklámügynökség (is), és nem is szóltunk senkinek, hogy most már de, ezért, csak úgy maguktól nem fogják tudni a szakemberek, hogy akkor ide most már lehet jönni reklámosnak is, nemcsak a szuperjó designereinkhez és fejlesztőinkhez.

De azért mégis meglepődtünk, hogy mennyire nem működött a sima – egyébként részletes, ám ezekszerint mégiscsak – gyengécske álláshirdetésünk.

### Szóval hibáztunk.

![Trambulin fun](https://i.giphy.com/media/U1NlfCLSFBV2U/giphy.webp)

1. Azt hittük, hogy leendő szakemberünk már eleve követ minket, és vár ránk, nekünk csak szólnunk kell (ezt ugye az előbb kifejtettük, hogy miért volt hülyeség.)
2. Azt hittük, ha véletlen nem is követ minket, de majd jól behirdetjük az álláshirdetéses posztunkat, akkor minden meg van oldva, mert így majd biztos látni fogja VALAHOGY (és ha így is lesz, nem fogja furának találni olvasott szakemberként, hogy reklámost keresünk, miközben nem vagyunk reklámos cég.)
3. Azt hittük, hogy majd az idő múlása, vagy esetleg még több pénz segít. (őszintén, egy elhibázott dolognál ez mikor segített bárkinek is.)

Összefoglalva, az amúgy elég alap 5 dolog közül:

- értsd meg
- fogalmazd meg normálisan
- gyere elő valami használható megoldással
- csinálj belőle valami gyorsan tesztelhetőt
- aztán teszteld

Kihagytunk vagy hármat, pedig úgy illett volna, mint MINDIG, hogy most is hátrébb lépünk egyet, és

### Empathise. Define. Ideate. Prototype. Test.

![1, 2, 3, 4, 5](https://i.giphy.com/media/l1J9Bgwp3XByuePpS/giphy.webp)

Miután rájöttünk, hogy elég sok alapfeltételezésünk hibás volt, nekiálltunk rendesen DOLGOZNI RAJTA.

Akit kerestünk, az egy tehetséges, kreatív és elszánt reklámügynökségi grafikus volt, aki szívesen eljön hozzánk tolni a biciklit, meg aki kicsit olyan, mint mi.

**MEGÉRTETTÜK**, hogy a problémánk nem az, hogy csak nem akar megérkezni az új kollegánk, hanem, hogy nem érjük el, mert mégcsak a radarján sem vagyunk rajta. Kicsi persona állítás után **MEGFOGALMAZTUK**, hogy nekünk az kell, aki pont annyit dolgozott már reklámügynökségen, hogy van elég tapasztalata megoldani sokféle kihívást, de már van benne igazi – jó szándékból, és tenniakarásból fakadó – frusztráció is, amiről szívesen beszél, vagy ami miatt esetleg váltana is. **ARRA GONDOLTUNK**, hogy fontos lehet, hogy ő akarjon beszélni erről, mert akkor meg is tudjuk szólítani, és ha már beszélgetünk, az fél siker. Szóval **MEGCSINÁLTUK** azt a nagyon alap prototípust, ami mindezt tudja – ez volt a grafikusokra, art direktorokra és designerekre célzott ügynökségi frusztrációkat firtató kérdőív(nek álcázott álláshirdetés), amit aztán gyorsan **NEKIÁLLTUNK HASZNÁLNI**, hogy lássuk, igazunk volt-e.

### Igazunk volt.

![Nevető hölgy](https://i.giphy.com/media/3o72ETx0Md2qEC1cB2/giphy.webp)

Két hét alatt több mint 120 szakember tisztelt meg minket a válaszával, és rengetegen jelentkeztek hozzánk! És nem ilyen himi-humi válaszokkal, mint amikor muszájból töltöd ki a drive-os kérdőívet szerda este, mert a barátnőd barátnője megkért a szakdolgozatához, te meg csinálod, mert különben a csajod csúnyán néz rád.

Mi most igazi válaszokat kaptunk. A 13-szor közel 120 kifejtős válasz pedig sokkal több, mint amire számítottunk. **Elég sok mindent megtudtunk, ezért a bejegyzés végén megmutatjuk a kérdőív kivonatát**, az összes választ, és most addig az előzetest is:

a fizu – vicc  
a kihívás – keskeny  
az idő – kevés  
szakmaiság – nincs  
WC-ben sírás – van

### Tanulság?

1. Gondolkodni (még a legegyszerűbbnek tűnő dolgok esetében is) megéri.
2. Érdekes volt látni magunkon, hogy milyen könnyen elfelejti az ember, amihez egyébként ért, sőt, a szakmája.
3. Az ügynökségi piacon sok a gond, sokan szenvednek, és ha nem is az összes probléma, de sok közülük igazából orvosolható.
4. Úristen, micsoda csoda szakemberek jelentkeztek!
5. Tényleg ideje megalapítanunk a saját reklámügynökségi részlegünket.

### Statisztika

A Facebookon 2017\. október 2-től 14-ig futtatott „kérdőív” során 125-ből 116-szor komolyan vehető válaszokat kaptunk, 58-an azt mondták, hogy simán jönnének hozzánk (azt a lehetőséget választották, hogy „VÁÁ, király!”), és mindennek az lett a vége, hogy a sprint végén 6 olyan szakember jött el interjúzni, akikbe csapatostul beleszerettünk.

**Ezúton is köszönjük a bizalmat, ne feledjétek, a kérdőív nem volt reprezentatív, magunknak készült, hogy jól tudjunk belőle továbbdolgozni, de szívesen megosztjuk veletek itt lent.**

![Le, le, le](https://i.giphy.com/media/LkuPxRS0F6gmc/giphy.webp)

### Íme a kivonat

Ebben a [táblázatban az összes választ megtalálod](https://docs.google.com/spreadsheets/d/1oWB33TqHNLHz6btfTrndaHdL4NHsa2WENNgibpukhJc/edit?ref=blog.fps.hu#gid=566943319).

Tudjuk, hogy nagyon hosszú lett ez a bejegyzés, ezért a kivonatban csak a két legfontosabb kérdéssel foglalkozunk, a válaszokat arányosan, ömlesztve látjátok, vesszővel elválasztva:

#### 1\. Ki mit utál a reklámszakmában?

*(ezt három különböző formában is megkérdeztük, mindig voltak újabb és újabb utált dolgok)*

értelmetlen projektek, tehetségtelen főnök, haszonállatként bánnak velem, egy kibaszott versenyló vagy, álszent közeg, basztak időre fizetni, ASAP szó indokolatlan használta, deal with it hozzáállás, a gépi kávét, bátortalanság, bullshitre épített projektek, introvertált beletörődés, szolga vagy, 0–24 készenlét, sosem a kreatív csapatnak van igaza, hanem mindig az accountoknak, wordbe ágyazott jpg-t logó, folyamatos éjszakázás és hétvégézés, folyamatosan védekező pozícióba kényszerülés az ügynökségi oldalon, v25, v26, v27…lebaszások, pöcslobogtatás, kiscica harcok a marketinges és a grafika közt, határidők, kapkodni kell, az accounttól kapom a reakciót, hogy szar, „ezt másold má' le, de ne legyen ugyanolyan”, kevés a zsé, anyagi biztonság hiánya, főnök felesége, futószalag, igénytelenség, dicséret hiánya, fröccsöntött értékrendek (a lista nem teljes, a csúnya szavakért elnézést kérünk, de a hitelesség nem sérülhetett).

#### 2\. Mi a helyzet a kreatív igazgatókkal?

*(gifeket is meg lehetett adni)*

ideülök melléd 5 percre jó? (1–3 óra), töketlen, beképzelt, iskolázatlan, telhetetlen, kreatívtalan, elég a diplomáciai érzék, de vezetői skill alig van…, seggfej, nemannakvaló, [http://bit.ly/2zav0Ye](http://bit.ly/2zav0Ye?ref=blog.fps.hu), alkalmatlan, támogató, tapasztalt, álmodozó, partner, cuki, kiöregedett multis róka, a 90-es években volt pár jó húzása valami betörő világmárka marketingeseként, kihasználós, [http://bit.ly/2hf6RVQ](http://bit.ly/2hf6RVQ?ref=blog.fps.hu), első évben minőségre törekszik következő 10 évben leszarja az egészet, fingom nincs ki az, baszik ránk, baszik mindenre, sosincs jelen, vele nincs baj, ánusz, az a baj vele hogy nincs, mindenki összevissza mondja a magáét, jófej az accountokkal vannak gondok, más bolygón él, langyos viz, teljesen jó arc, zseni, :D, meh, szervilis pöcs, sztereotipikus, trendi, teknős, izzadós tenyerű, fásult, …van pénze, tehát szakember, nincs, hogy kivel?, színvak, [http://bit.ly/2dqBfZk](http://bit.ly/2dqBfZk?ref=blog.fps.hu), névleges, még vasárnap este is zaklat, fasz, világfájdalom, semmirekellő, egy pöcs, „Oldd meg”, asshole, papucs, idióta :D  
tökéletes, kokain. (továbbra is elnézést a csúnya szavakért, nagyon őszinte volt velünk mindenki, és ezt tiszteletben tartjuk).

**Az [egész kérdőívet megnézhetitek](https://docs.google.com/spreadsheets/d/1oWB33TqHNLHz6btfTrndaHdL4NHsa2WENNgibpukhJc/edit?ref=blog.fps.hu#gid=566943319), benne pedig tényleg mindent elolvashattok, és választ kaptok olyan kérdésekre is, hogy hol milyen egy átlagos ügynökségi nap, hogy mik a kedvenc reklámok, és arra, hogy hányan akarnak alpakkát tenyészteni délen. (Megéri böngészni)**

![Várjá, várjá, várjá](https://i.giphy.com/media/v4kV0CNXc8jXa/giphy.webp)

### Utószó

1. a kérdőívből kiolvasható egy szabadvers (összeolvasva az egyik sor pár válaszát, ezt találtuk, és nem értjük, de mégis értjük.)  
*Lid cry bin watching prints earn me bed less*  
*Anna llc sec bill push being watch*  
*Love arc bin puts chunk*  
*Kalamazoo monolithic*  
Sziv
2. van, aki szerint jézus él
3. Nagyon sok szívecskét kaptunk, rengetegen imádták, hogy így keresünk embert, mindenkinek köszönjük!

Akinek pedig mi küldünk pár szívecskét, mert úgy érezzük ráfér, az az a válaszadónk, aki arra a kérdésre, hogy mit utált meg az ügynökségén azt a választ adta, hogy

Az emberiséget. Igen. Az egészet.

<3

**Köszönjük a megosztást, köszönjük a figyelmet, és bocs, hogy tényleg hosszú volt. Sziasztok.**

![Puszi, csók, szia, szevasz](https://i.giphy.com/media/A1etPWqtba6je/giphy.webp)
### A gépi tanulásról érthetően
URL: https://blog.fps.hu/neuralis-halozatokrol-erthetoen/
Last updated: 2026-07-17T08:27:29.000Z
Mostanában a csapból is az folyik, hogy mesterséges intelligencia meg tanuló algoritmusok, arról azonban nem nagyon esik szó, hogy mégis mi ez az egész, mire jó és milyen elven működik. Nem véletlenül: elképesztően bonyolult témáról van szó. Ennek ellenére a cikkem célja az, hogy akár teljesen laikusként legyen némi rálátásod a területre.

A médiában a „mesterséges intelligencia” és a „tanuló algoritmus” kifejezések majdnem mindig a mesterséges neurális hálózatokat takarják. A cikkben ezekről lesz szó.

Azért kapták ezt a jól csengő nevet, mert a biológiai neurális hálózatok, főleg az emberi idegrendszer ihlette őket. A hagyományos szoftverekkel szemben ezek anélkül képesek megoldani egy problémát, hogy a megoldás konkrét lépéseit megmondanánk nekik. Nem előre lekódolt utasításokat hajtanak végre, hanem „rájönnek", hogyan kell megoldani a problémákat.

Tanulnak. Ez alatt azt értjük, hogy a korábbi tapasztalataikat felhasználva egyre jobban és jobban tudják végrehajtani az adott feladatot egészen addig, amíg végül képesek lesznek magabiztosan egy elfogadható hibahatáron belül teljesíteni.

### Hogyan tanulnak az emberek?

Először azt kell megértened, hogy te hogyan tanulsz. Nagyon leegyszerűsítve ezt a következőképpen tudom összefoglalni:

Az agyadban található neuronok az idegrendszered legfontosabb feldolgozó egységei. Van bemenetük (dentrit) és kimenetük (axon), amelyeken keresztül más neuronokkal állnak kapcsolatban. Egymáshoz össze-vissza csatlakozva bonyolult hálózatot alkotnak.

Amikor kisbaba voltál, az agyad még csak negyedakkora volt, mint most, de már csaknem az összes neuront tartalmazta, amelyeket azóta is használsz. A tanulás során a neuronok között kapcsolatok (szinapszisok) jönnek létre vagy szűnnek meg. Ezért érdemes [folyamatosan képezned magad](https://blog.kolboid.eu/miert-tanulj-folyamatosan-eleten-at/?ref=blog.fps.hu).

Valójában persze sokkal bonyolultabb a dolog, de a lényeg így is látszik: a tanulás előtti és utáni állapotok között a legfontosabb különbség **nem magukban az idegsejtekben, hanem a köztük kialakult kapcsolatokban rejlik**. Felfoghatod úgy is, hogy minden, amit valaha megtanultál, leírható ezekkel a kapcsolatokkal.

### Hogyan tanulnak a gépek?

Kis túlzással ugyanígy. Gépi tanuló algoritmusok fejlesztésekor is neuronokból építkezünk, amelyeket egymással összekötünk, majd a tanulás során ezeket a „szinapszisokat” úgynevezett [közelítő megoldások](https://hu.wikipedia.org/wiki/K%C3%B6zel%C3%ADt%C5%91%5Fm%C3%B3dszerek?ref=blog.fps.hu) alapján folyamatosan módosítjuk. Az a cél, hogy úgy drótozzuk át a neuronok hálózatát, hogy az minél pontosabban legyen képes végrehajtani az adott feladatot.

Úgy gondolom, egy konkrét példán keresztül egyszerűbben megérthető ez az egész. Nézzük meg, hogyan képes egy algoritmus megtanulni a XOR függvényt!

A XOR (kizáró vagy) két paramétert kap, amelyek lehetnek igazak (1) vagy hamisak (0). Ha a két paraméter különbözik, akkor 1 lesz az eredmény, egyezés esetén pedig nulla. Tehát:

XOR(0,0) = 0  
XOR(0,1) = 1  
XOR(1,0) = 1  
XOR(1,1) = 0

### A hálózat felépítése

A hálózatunk tehát neuronokból és kapcsolatokból áll. A neuron gyakorlatilag egy függvény: van bemenete, van kimenete, a kettő között pedig csinál valamit a kapott adatokkal.

A mi neuronjaink [a logisztikai szigmoid függvényt](https://en.wikipedia.org/wiki/Logistic%5Ffunction?ref=blog.fps.hu) fogják használni.

Maga a hálózat három rétegből épül fel:

- egy bemeneti réteg, amelyben két neuron kap helyet a két bemeneti értéknek
- egy rejtett réteg három neuronnal
- egy kimeneti réteg egyetlen kimeneti neuronnal

![network-1](https://blog.fps.hu/content/images/2017/09/network-1.png)

Ahogyan a fenti ábrán is látható, minden réteg összes neuronját összekötjük a következő réteg összes neuronjával (ezt nevezzük előrecsatolásnak). Az így létrejött kapcsolatoknak súlyokat adunk, amelyeket először random számokkal inicializálunk.

Maga a network ezzel már majdnem készen van, csak egyelőre nem nagyon működik. Még nem tudja, hogy mit várunk tőle. Meg kell neki tanítanunk, vagyis a kapcsolatok súlyait úgy kell beállítanunk, hogy a várt működést elérjük.

### A hálózat tanítása

Mivel meg tudjuk mondani, hogy egy adott bemenetre milyen kimenetet kell kapnunk, úgynevezett felügyelt tanítási módszert fogunk alkalmazni. Szükség lesz egy tanítási adathalmazra (training set). Esetünkben ez a XOR függvény négy lehetséges bemenetét és a hozzájuk tartozó kimeneteket jelenti.

A tanítás kezdetén egyből a mély vízbe dobjuk a hálózatot. Adunk neki egy mintát, aztán megnézzük, hogy mekkorát tévedett a várt kimenethez képest. A tévedés függvényében állítunk egy kicsit a súlyokon, majd ezt ismételjük egészen addig, amíg úgy nem döntünk, hogy a hálózatunk már elég okos. Esetünkben akkor döntünk így, amikor a meghatározottnál kisebb hibával sikerült eltalálnia a várt kimenetet. Nézzük meg egy kicsit közelebbről!

#### Az eredmény kiszámítása

Tehát a hálózat súlyait korábban már random számokkal inicializáltuk (az egyszerűség kedvéért legalábbis közelítsük meg így). Tegyük fel, hogy mindegyik kapcsolat súlya 0.5 lett.

Veszünk egy mintát (például 0 és 1 a bemenet, a várt kimenet pedig 1). Ezt a mintát betoljuk a hálózatunkba az input rétegen keresztül, amely két neuront tartalmaz. Ezek kimenete így 0 és 1 lesz.

A középső, rejtett rétegünk neuronjai csatlakoznak a bemeneti réteg két neuronjához. Fogjuk az első neuron első kapcsolatát, majd a kapcsolat súlyát megszorozzuk a kapcsolódó bemeneti neuron kiemnetével (0 \* 0.5 = 0). A második kapcsolatnál ugyanígy járunk el (1 \* 0.5 = 0.5), majd a két számot összeadjuk (0 + 0.5 = 0.5). Az eredményt átengedjük a neuron „sejtmagján”, a logisztikai függvényen (1 / (1 + exp(-0.5)) = 0.62). Így járunk el a további két rejtett neuron esetében is.

Az utolsó, kimeneti rétegben hasonlóképpen számolunk, ezzel megkapjuk a hálózatunk tényleges eredményét. Nem vezetem le, mert annyira nem érdekes, de először a hálózat kimenete valahol 0.5 környékén lesz.

#### A súlyok igazítása

A hálózatunk által produkált kimenetet összevetjük azzal az eredménnyel, amit kapnunk kellett volna, majd a hibát visszavezetjük a hálózatba (ezért nevezzük backpropagation-nek). Úgy is mondhatnám, hogy levonjuk a konklúziót és ennek függvényében változtatunk egy kicsit a súlyokon.

Ezúttal visszafelé haladunk a rétegeken. Először is minden egyes neuron esetében meg kell határoznunk a hiba mértékét. Ehhez az [átlagos négyzetes hibafüggvényt](https://en.wikipedia.org/wiki/Mean%5Fsquared%5Ferror?ref=blog.fps.hu) hívjuk segítségül. Minél ügyesebb volt a hálózatunk, annál kisebb lesz a hibafüggvénnyel kiszámolt eredmény, tehát annál kisebb változtatásra lesz szükség.

Már csak a „szinapszisok” finomhangolása van hátra. De honnan tudjuk, hogy az adott kapcsolat módosítása hogyan fog kihatni a hálózatunk működésére? Pontosabban: melyiket hogyan kell módosítanunk a pontosabb eredmény érdekében? A választ az [általánosított delta szabály](https://en.wikipedia.org/wiki/Delta%5Frule?ref=blog.fps.hu) alkalmazásával kapjuk meg. Röviden összefoglalva arról van szó, hogy minden egyes kapcsolat súlyát a hiba létrehozásában játszott szerepükkel arányosan változtatjuk.

A következő körben így egy kicsivel pontosabb lesz a számítás, így előbb-utóbb a hálózat a várt működést fogja mutatni.

### Vizualizáció

Arra gondoltam, hogy mindezt könnyebben megértheted, ha a saját szemeddel látod, hogyan lesz súlyok módosítgatásából tanulás. Ez adta az ötletet egy olyan microsite fejlesztéséhez, amely mindezt lehetővé teszi. [Itt nézheted meg](http://neural.fps.hu/?ref=blog.fps.hu).

Amit látsz: a fenti példában vázolt egyszerű hálózat felépül és megtanulja a XOR függvényt néhány másodperc alatt. Minden tizedik epoch (1 epoch = a teljes tanítási adatkészletet végigpörgettük a hálózaton, esetünkben ez 4 iteráció) után készül egy „pillanatkép” a hálózat aktuális állapotáról.

A folyamatot vissza tudod játszani az alsó csúszka mozgatásával, így láthatod, hogyan alakultak át a hálózat kapcsolatai és milyen eredmények születtek. Mivel az elején véletlenszerűen inicializált súlyokkal jön létre a hálózat, az eredmény mindig egy kicsit más lesz.

A [site forráskódja is elérhető](https://github.com/sjozsef/neural-network-visualized?ref=blog.fps.hu).

*Megjegyzés: a vizualizáció során úgynevezett [biased neuronokat](http://galaxy.agh.edu.pl/~vlsi/AI/bias/bias%5Feng.html?ref=blog.fps.hu) használtam, amelyek a hálózat optimálisabb (esetünkben gyorsabb) működését teszik lehetővé. Enélkül is működne, így az egyszerűség kedvéért ezek az értékek nem jelennek meg.*

### Írd meg a saját hálózatod!

Szóval arra bíztatlak, ha érdekel ez a világ, vágj bele és próbálj meg összedobni valamit még akkor is, ha elsőre túlságosan bonyolultnak tűnik az egész. Minden szépen ki fog tisztulni, ahogy az lenni szokott. :)

Figyelmedbe ajánlom a [Synaptic](https://github.com/cazala/synaptic?ref=blog.fps.hu) JavaScript frameworköt, amelyet a microsite esetében is használtam. A framework egyrészt azért érdekes, mert használható kliensoldalon és szerveroldalon egyaránt, ezáltal lehetővé teszi a neurális hálózatok alkalmazását a weben.

Még ennél is érdekesebb lehet számodra az a tény, hogy pár osztályból áll az egész. Persze nem lehet egy lapon említeni olyan robosztus keretrendszerekkel, mint amilyen a [TensorFlow](https://www.tensorflow.org/?ref=blog.fps.hu) vagy a [Caffe2](https://caffe2.ai/?ref=blog.fps.hu) (utóbbi egyébként a számomra a legszimpatikusabb), de pont az egyszerűsége teszi igazán alkalmassá arra, hogy elkezdj kicsit komolyabban foglalkozni a témával.

Az egyszerű XOR hálózat például ennyi:

```javascript
// Hálózat két bemeneti, három rejtett és egy kimeneti neuronnal.
var myNetwork = new Architect.Perceptron(2,3,1); 

// Trainer
var myTrainer = new Trainer(myNetwork);

// Tanítás a XOR training settel, átlagos négyzetes hibafüggvénnyel
myTrainer.XOR()

// Eredmény a [0, 1] bemenetre:
console.log( myNetwork.activate( [0, 1] ) );

```

Szóval hajrá!

### Felhasználási területek

A XOR példa a neurális hálózatok hello world-je, ennek még nincs sok gyakorlati haszna. Kicsit bonyolultabb, de hasonló felépítésű hálózatok viszont már használhatóak például [osztályozási feladatokra](https://www.solver.com/xlminer/help/neural-networks-classification-intro?ref=blog.fps.hu). Használhatsz másmilyen neuronokat, sokkal többet, több rejtett rétegben. Nem csak előrecsatolással kötheted össze őket, hanem például [visszacsatolással](https://machinelearningmastery.com/recurrent-neural-network-algorithms-for-deep-learning/?ref=blog.fps.hu). Taníthatod valamilyen [nem felügyelt](https://en.wikipedia.org/wiki/Unsupervised%5Flearning?ref=blog.fps.hu) eljárással, így elvontabb problémákat is megoldhatsz, ahol nem annyira egyértelmű, mi számít elfogadható eredménynek.

Egy [visszacsatolt neurális hálózat](https://en.wikipedia.org/wiki/Recurrent%5Fneural%5Fnetwork?ref=blog.fps.hu)nak (RNN) lehet memóriája ([LSTM](http://colah.github.io/posts/2015-08-Understanding-LSTMs/?ref=blog.fps.hu)), ami képessé teszi adatok iterációk közötti átvitelére, így alkalmas lesz távolabbi összefüggéseket is feltárni. Ezt használjuk például természetes nyelvfeldolgozásnál. Ekkor már neurális nyelvi modellekről beszélünk, amelyek [szavak](https://github.com/hunkim/word-rnn-tensorflow?ref=blog.fps.hu) vagy [betűk](https://github.com/karpathy/char-rnn?ref=blog.fps.hu) szintjén keresnek összefüggéseket a szövegekben. Azt tudják megmondani, hogy egy mondat mekkora valószínűséggel fordulhat elő a való életben. Jobbá teszik például a [fordítóprogramokat](https://nlp.stanford.edu/pubs/conll15%5Fnlm.pdf?ref=blog.fps.hu), mert életszerűbb fordításokat eredményeznek.

Szinte ugyanezzel a technológiával [költhetsz vereseket](https://www.facebook.com/fpsugynokseg/posts/10155185866609671) vagy [megírhatod a Trónok Harca befejezését](http://index.hu/tech/2017/08/30/egy%5Frobot%5Fmegirta%5Fa%5Ftronok%5Fharca%5Ffolytatasat/?ref=blog.fps.hu). [Skip-Trough vektorokkal](https://arxiv.org/pdf/1506.06726.pdf?ref=blog.fps.hu) még életszerűbb mondatokat generálhatsz, amelyekről már nem feltétlenül mondanád meg, hogy egy számítógép írta őket. Felismerhetsz képeken látható tárgyakat, sőt, [történeteket generálhatsz képek alapján](https://github.com/ryankiros/neural-storyteller?ref=blog.fps.hu).

A weben is számos területen bevethetőek. Ajánlhatsz termékeket egy webshopban. [Színpalettát generálhatsz](http://colormind.io/?ref=blog.fps.hu). Chatbotokat készíthetsz. Nagyobb [biztonságban tudhatod az adataidat](http://www.sciencedirect.com/science/article/pii/S1877705814003579?ref=blog.fps.hu). Értékes információkat bányászhatsz ki a felhasználóid viselkedéséből. Olyan összefüggéseket, amelyekről most még nem is tudod, hogy figyelned kellene rájuk.

Sokáig azt hittük, hogy bizonyos dolgokra csak mi, emberek vagyunk képesek. Régebben például egyszerű captcha megoldásokkal távol lehetett tartani a robotokat. [Ma már nem.](https://codepen.io/birjolaxew/post/cracking-captchas-with-neural-networks?ref=blog.fps.hu)

Szeretnéd legyőzni a világ legjobb Dota2 játékosát, de nem vagy profi gamer? Nem probléma, mesterséges intelligenciával [ezt is bármikor megteheted](https://blog.openai.com/dota-2/?ref=blog.fps.hu). Fáradt vagy és nincs kedved autót vezetni? Dőlj hátra, egy neurális hálózat simán elvezeti a kocsidat helyetted, ráadásul sokkal jobban.

Ez nem a jövő, ez a jelen. Hogy hol a határ? Sehol. Nincs határ. A lehetőségek tárháza végtelen és a technológia napjainkban rohamléptekben fejlődik. Csak egy dolog biztos: előbb-utóbb okosabbak lesznek nálunk a számítógépeink, ez pedig alapjaiban fogja megváltozni a ma ismert világunkat. A tekintetben, hogy ez mennyire lesz jó nekünk, megoszlanak a vélemények. Ha engem kérdezel, jogosnak tartom az aggályokat, de azért bizakodó vagyok.

És Te mit gondolsz?
### Retrospective-et mindenkinek!
URL: https://blog.fps.hu/retrospective-mindenkinek/
Last updated: 2026-07-17T08:27:37.000Z
Az emberek többsége azért szeret csapatban dolgozni mert örömöt, bánatot, kihívást könnyebben viselünk együtt. A csapatmunkában sokszor szükség van egy „szelepre”, ahol a felgyülemlett gondolatok megbeszélésre kerülhetnek. Mivel nem lehet mindig csapatépítő jellegű sörözésekre járni, sokszor formálisabb módját kell, hogy válasszuk: retrospective-eket tartunk.

![sok minion](https://m.popkey.co/712e52/4Z68_f-maxage-0.gif)

A retrospective hivatalosan az agilis fejlesztési folyamat szerves része, melynek célja a fejlesztési folyamat hatékonyság javítása, problémáinak kiküszöbölése. Minden csapattag elmondja a véleményét az utolsó sprintről, majd közösen megegyeznek, hogy mit változtatnak a következő sprint során. Mint a legtöbb módszertant, ezt sem mértani pontossággal kell alkalmazni, érdemes mindenkinek saját magára szabni.

Ami nálunk bevált: Csapat retrospective projekt szemlélettel

### Ki vegyen részt rajta?

A csapatod minden tagja, illetve szükség esetén az aktuális projektben bármilyen formában közreműködők (art director, rendszergazda, vezető fejlesztő stb.)

### Mikor tartsd?

Két–három hetente. Érdemes egy fix időpontot kijelölni, amihez mindenki tud majd alkalmazkodni.

### A csapatod nincs egy helyen fizikailag, mi a teendő?

Amennyiben megoldható, olyankor célszerű megtartani a retrospective-et, amikor mindenki személyesen részt tud venni rajta. Ha ez nem kivitelezhető, akkor skype-on, vagy bármilyen más eszköz segítségével egy-egy ember behívható, de sajnos ront a megbeszélés hatékonyságán, ha például pont olyan ember nem vesz részt rajta személyesen, aki kevésbé kommunikatív.

### Milyen részekből álljon?

Minden retrospective más és más, de van egy vezér fonal, amit érdemes követni. Nálunk a jól bevált forma, hogy a csapattagok egyesével elmondják, mi az, ami az elmúlt időszakban nem ment tökéletesen és változtatni kell rajta, illetve mi az, amit érdemes tovább csinálni, mert jól működik. Ennek hosszabb változata, mikor minden résztvevő maximum 3-3 cetlire felírja a pozitív és negatív tapasztalatait az elmúlt időszakról, ezeket csoportosítja közösen a csapat és arról beszélnek csak, ami gyakori topic volt.

![minion a kukába hajít egy papír galacsint](http://funnyminions.com/wp-content/uploads/2017/05/Today-Top-Funny-Minions-23.gif)

Ezt a nagyobb lélegzetvételű megbeszélést kéthavonta érdemes megtartani, a következő linkeken pedig találsz egy-két technikát, amivel változatossá tehetők a retrospective-ek:  
[Funretrospective](http://www.funretrospectives.com/?ref=blog.fps.hu)  
[Scrumalliance](https://www.scrumalliance.org/community/articles/2014/april/a-reflection-on-retrospectives?ref=blog.fps.hu)

Futó projektek megtérülésének és mérföldköveinek átbeszélésére is érdemes mindig időt szakítanod, a lezárult projektek tanulságaira pedig még ennél is fontosabb kitérni. Akár fél éve lezárult projektről is készíthetsz egy kisebb prezentációt a csapatnak, hogy a kitűzött célokat elérte-e a projekt, milyen ügyfél visszajelzések érkeztek azóta és így tovább.

Nagyon jó érzés, mikor időt szántok egymásra, és a csapat minden tagja beszélhet a közösen átélt élményekről egy olyan fórumon, ahol bevezetésre kerülhetnek a közösség mindennapjaiba az ott kimondott tanulságok.

> [#retro #board #fps #icons #pictograms](https://www.instagram.com/p/BTUCg3ujKGK/?ref=blog.fps.hu)
> 
> fps agency (@fpsagency) által megosztott bejegyzés, 2017\. Ápr 25., 08:19 PDT
### A WordPress ingyenes, akkor én miért fizetek?
URL: https://blog.fps.hu/wordpress-ingyenes-miert-fizetek/
Last updated: 2026-07-17T08:27:46.000Z
Ügyfél oldalról számos alkalommal merül fel a kérdés, hogy ha egy ingyenes, open source keretrendszerre épül a weboldala, akkor miért is kerül annyiba. Hiszen számtalan ingyenes sablon és bővítmény létezik, csak le kell őket tölteni, és össze kell „kattintgatni” a weboldalt. Ha ez ilyen egyszerű lenne...

### Van egy ismerősöm, ő már csinált ilyet…

Tagadhatatlan a tény, hogy tényleg össze lehet rakni egy weboldalt mindenféle kódolás és fejlesztői készség nélkül, esetleg lelkes amatőrként (elég csak a kezdeti munkáimra gondolnom). Az ilyen oldalakat azonban eléggé könnyedén ki lehet szűrni. Apró jelek, figyelmetlenségek vagy csak éppen a „jól van az úgy” megoldások árulkodnak arról, hogy milyen mélységig mentek bele a kivitelezésbe. Kiválóan szemlélteti a jelenséget, ha rákeresel az [alapértelmezett tartalom címére](https://www.google.hu/search?q=ez+egy+mintaoldal&ref=blog.fps.hu), és ezek ugye csak a magyar nyelvű oldalak.  
Személyes tapasztalatom, hogy akik a fenti módon szeretnének saját weboldalhoz jutni (netán szolgáltatásként értékesítik eme tevékenységüket) minden esetben válaszúthoz érnek:

- keresnek (még)egy ismerőst, aki ért a fejlesztéshez és segítséget kérnek tőle, mert bizonyos funkcionalitás megvalósítása már meghaladja a tudásukat
- elfogadják a sablonok és bővítmények korlátait, vagy éppen megpróbálják elmagyarázni, hogy a rendszer (ennyiért) ennyit tud, ez van.

### Jóból is megárt a sok

A WordPress egyik előnye és egyben hátránya is, hogy az évek alatt úgy alakították, hogy (szinte) minden problémát meg lehessen oldani vele, egészséges keretek között. Ezt szem előtt tartva dolgoznak a bővítmények és sablonok készítői is, igyekeznek olyan komponenseket készíteni, amik a lehető leginkább univerzális felhasználhatóságot biztosítanak. Fejlesztőként konkrétan zavarba ejt az egyes letöltött third-party bővítmények/sablonok beállíthatósága. Ilyenkor rendszerint az jut eszembe, hogy ez csak pár sornyi kód lenne, miért kell nekem átküzdenem magam ennyi mindenen? Az átlag felhasználónak is valószínűleg komoly kihívást jelent minden egyes paraméter beállítása, és általában ennek az eredménye a közel 50 feltelepített bővítmény (ki tudja, melyik akad össze melyikkel), a felesleges funkciók, inline formázások és fapados megoldások sokasága.

### Ez a plugin jó lesz, feltelepítem

A bővítmények esetleges összeakadásán, nem kívánt extra funkcióin túl nem elhanyagolható tényező a biztonsági kérdés sem. Sok esetben nem kellően letesztelt, utoljára évekkel ezelőtt frissített kiegészítők is bekerülhetnek a rendszerbe, amik [nem kívánt következményekhez](https://thehackernews.com/2017/06/wordpress-hacking-sql-injection.html?ref=blog.fps.hu) is vezethet. Előfordulhat az a kellemetlen eset is, amikor egy bővítményt már nem támogat a frissített WordPress verziónk (feltéve, hogy legalább azt frissítjük), és az egyszerűen kikapcsolja magát. Jön egy újabb kör, amikor alternatívát kell találni, ami ismét beállítások sokaságával, esetleg az oldal működésének megváltozásával jár, mert hát „csak ezt találtam”.

![wordpress-bovitmenyek](https://blog.fps.hu/content/images/2017/08/wordpress-bovitmenyek.jpg)

### Egyedi igények – egyedi megoldások

Amikor kicsit is többet szeretnél a weboldaladtól, minthogy csak legyen, netán van egy mögöttes konverziós vagy brandépítési cél vagy speciális funkció, felmerülnek az egyedi igények. Egy gondosan megtervezett, egyedi design-nal rendelkező oldalt szinte lehetetlen összekattintgatni csak az ingyenesen rendelkezésre álló WordPress komponensekből. Ez így van rendjén, hiszen komolyabb projekt már komolyabb munkával jár, és ha már a tervezés és grafika egyedi, joggal elvárható, hogy a kód is egyedi legyen, aminek ugye megvan a maga költsége. Ezt a témát egyébként már korábban is [boncolgattuk](https://blog.fps.hu/mennyi-az-annyi/), érdemes elolvasnod.

### Na, de akkor miért is fizetek?

Röviden? A hozzáadott értékekért. Nem szabad elfelejteni és már [korábban is írtam](https://blog.fps.hu/wordpress/), hogy a WordPress maga csak egy eszköz, ha sarkítva nézzük, egy előre meghatározott adatstruktúra egy kellően kidolgozott adminisztrációs felülettel. Egy egyszerűbb oldalt vizsgálva, abszolút elképzelhető, hogy nem szükséges egyedi fejlesztés, az ingyenes megoldásokkal összehozható és „eldöcög” magának.  
Azonban amikor már egy kicsit is komolyabb projektről beszélünk, fontos szemponttá válik a használhatóság, fenntarthatóság és esetlegesen a bővíthetőség. Ez egy hosszútávú befektetés. Kutatással, analitikai elemzésekkel, tervezéssel jár, hogy az elkészülő oldal valóban az igényeket szolgálja ki és hatékony legyen. Ha az elején szeretnéd megspórolni, esélyes, hogy a későbbiek során visszaüthet és valójában két weboldalért kell fizetned, ami sohasem kellemes.
### Automatizált képernyőképek Androidon
URL: https://blog.fps.hu/automatizalt-kepernyokepek-androidon/
Last updated: 2026-07-17T08:27:55.000Z
[ConfCat](http://www.confcat.com/?ref=blog.fps.hu) appjainkat évente újra megrendezésre kerülő konferenciákon használják. Ezekhez minden egyes alkalommal új képernyőképeket kell készíteni a konferenciák előtt a Play Store-hoz. 5 képernyőről, 2 nyelven, 3 méretben. Összesen 30 képet. Ezt az egészet pár perc alatt le lehetne rendezni, ha automatizáljuk. Akár a felületelemek különböző nyelveken való tesztelését is megkönnyíthetjük ezzel, mert csak a képeket kell átnézni. Így gyorsabban észrevehetőek a hibák.

#### Kezdjünk bele

Képernyőképeket tesztelés közben kell készíteni. Ehhez a készüléken vagy emulátoron futtatott tesztek szükségesek. Az ilyen teszteket instrumented teszteknek nevezik.

Most azzal nem fogok foglalkozni, hogy kell ilyen teszteket írni. Ha nem tudod, hogyan kezdj ilyenbe, akkor az [Espresso](https://developer.android.com/training/testing/espresso/index.html?ref=blog.fps.hu) nevű könyvtárat tudom ajánlani, amivel az Android Studioba épített Espresso Test Recorder segítségével, emulátoron keresztül rögzítheted tesztjeidet.  
A képernyőképeket az [UIAutomator](https://developer.android.com/training/testing/ui-automator.html?ref=blog.fps.hu) és a [Spoon](http://square.github.io/spoon/?ref=blog.fps.hu) könyvtár segítségével készítjük.

#### Spoon használata

A Square Spoon nevű könyvtárát használjuk képernyőképek lementésére és megjelenítésére. Továbbá ez futtatja az összes tesztet az elérhető vagy az általunk beállított készülékeken.

A project szintű build.gradle fájlban hozzáadjuk:

```java

buildscript {
    dependencies {
        classpath 'com.stanfy.spoon:spoon-gradle-plugin:1.2.2'
        classpath 'com.squareup.spoon:spoon-runner:1.7.1'
    }
}

```

Majd az app build.gradle fájlban hozzáadjuk és konfigurálhatjuk:

```java

apply plugin: 'spoon'

dependencies {
  androidTestCompile 'com.squareup.spoon:spoon-client:1.7.1'
}

// ez a rész opcionális
spoon {
    // debug kimenethez
    debug = true
    // teszt osztály megadása
    className = 'com.confcat.test.ScreenShotSuite'
    // készülékenkénti szekvenciális teszteléshez
    sequential = true
    // minden jog megadása (android M és felette)
    grantAllPermissions = true
}

```

Egy sor kóddal képernyőképet lehet készíteni, amit aztán egy webes felületen meg lehet tekinteni:

```java

Spoon.screenshot(activity, fileName);

```

Mindegyik képernyőről tudunk készíteni képet, csak rá kell lépni a teszt során.

A webes felületet az app/build/spoon könyvtár alatt található. Itt fog megjelenni az összes egy futás során készített kép.

![Spoon web interface](https://raw.githubusercontent.com/square/spoon/e4b528334901aa6164ea0261ddb38f1af6ff762e/website/static/example_screenshots.png)

Sajnos OpenGL-t alkalmazó elemekről nem lehet készíteni képet. Ilyen például a Google Maps. Ehelyett az UIAutomator könyvtárat kell alkalmazni a Spoonnal karöltve. A Spoontól megkapjuk a fájlt, ahova a képet menti, majd az UIAutomator segítségével megcsináljuk a képet:

```java

File screenshot = Spoon.screenshot(activity, fileName);
UiDevice.getInstance(getInstrumentation()).takeScreenshot(screenshot);

```

Ha nem sikerült valamilyen hiba miatt képet készíteni, annak oka is megtalálható a webes felületen, naplóval együtt.

#### Nyelvváltás

Mivel több nyelven is elérhető az alkalmazás, ezért valahogy nyelvet kell váltani és újra futtatni a teszteket a másik nyelvvel. Ezt parametrizált teszt segítségével lehet megvalósítani:

```java

@RunWith(Parameterized.class)
@LargeTest
public class MainActivityTest {

  public MainActivityTest(Locale locale) {
    this.locale = locale;
  }

  @Parameterized.Parameters
  public static Object[] data() {}
}

```

Ekkor a *data()* metódusban vissza kell adni az összes nyelvet, amivel futnia kell a teszteknek.

Minden teszt előtt újraindul az Activity. Még az Activity indulása előtt be kell állítani a nyelvet. Ha máskor állítod be, nem fog sikerülni. Ehhez először az szükséges, hogy az Activity ne induljon el automatikusan:

```java

@Rule
public ActivityTestRule activityRule = new ActivityTestRule<>(MainActivity.class, true, false);

```

Az *ActivtyTestRule* konstrukturának harmadik paramétere hamis, ekkor nem indul el automatikusan. Minden teszt indulása előtt beállítjuk a nyelvet és elindítjuk az Activityt:

```java

@Before
public void setUp() throws Exception {
    LocaleUtil.setLocale(InstrumentationRegistry.getTargetContext(), locale);
    activityRule.launchActivity(null);
}

```

A *LocaleUtil.setLocale()* metódusa, ami a nyelvet váltja:

```java

public static void setLocale(Context context, Locale locale) {
    Locale.setDefault(locale);
    Resources resources = context.getResources();
    Configuration configuration = resources.getConfiguration();
    if (android.os.Build.VERSION.SDK_INT > android.os.Build.VERSION_CODES.JELLY_BEAN) {
      configuration.setLocale(locale);
  } else {
      configuration.locale = locale;
  }
    resources.updateConfiguration(
      configuration,
      resources.getDisplayMetrics()
    );
}

```

Sajnos itt van egy bökkenő. A Spoon elromlik, mert rosszak lesznek az elnevezések. Indexelni kell a nyelveket 0-tól és működni fog minden. Ekkor már a nyelv és az index is paraméterként kerül a konstruktorba:

```java

public MainActivityTest(Locale locale, int localeIndex) {
      this.locale = locale;
      this.localeIndex= localeIndex;
}

```

Ezt az indexet kell megadni a Spoonnak, amikor képet készítünk:

```java

File screenshot = Spoon.screenshot(
              activityRule.getActivity(),
              fileName,
              getClass().getCanonicalName(),
              String.format("%s[%s]", testName, localeIndex)
);

```

#### Demo mód integrálása

Nekünk Play Store-hoz kellenek a képek, ezért nem szeretnénk, ha felesleges dolgok lennének a státusz baron. Szerencsére 23-as API-tól elérhető a demo mód, amivel testre lehet azt szabni.

![Demo mode](http://i.imgur.com/bUwUoRn.png)

Ezt minden futás előtt engedélyezni szeretnénk, majd utána kikapcsolni. Hogy ez telesüljön egy Gradle taskot kell lefuttatni a Spoon Gradle taskja előtt, majd egyet utána. Gradle taskhoz létrehozunk egy buildSrc/src/main/groovy könyvtárszerezetet a project gyökeréből kiindulva. A groovy almappában létre lehet hozni egy .groovy kiterjesztésű fájt, amit a task futtat majd.

A buildSrc könyvtárban található build.gradle fájlnak az alábbiakat kell tartalmaznia:

```java

apply plugin: 'groovy'

repositories {
  mavenCentral()
  jcenter()
}

dependencies {
  compile 'com.squareup.spoon:spoon-runner:1.7.1'
  compile 'com.android.tools.ddms:ddmlib:25.3.0'
  compile 'com.android.tools.build:gradle:2.3.3'
  compile gradleApi()
  compile localGroovy()
}

```

Itt annyi történik, hogy a groovy plugint használjuk groovy fordításához. Spoon függőségen keresztül inicializáljuk az ADB-t, ddmlib-et az ADB használatához és Android Gradle plugint az SDK könyvtár megtalálásához.

A task inicializálja az ADB-t. Megkérdezi milyen eszközök vannak. Ha be kell kapcsolni a prezentációs módot végigmegy az összesen és bekapcsolja azt, ha ki kell kapcsolni, akkor kikapcsolja mindegyiken.

```java

class DemoModeTask extends DefaultTask {

    Duration DEFAULT_ADB_TIMEOUT = Duration.ofMinutes(10)

    boolean isDemoModeEnabled;

    @TaskAction
    public void run() {
        //init adb
        BaseExtension android = project.android
        AndroidDebugBridge adb = SpoonUtils.initAdb(
                android.sdkDirectory,
                DEFAULT_ADB_TIMEOUT.toMillis()
        )
        //get all devices
        IDevice[] devices = adb.getDevices()
        CollectingOutputReceiver grantOutputReceiver = new CollectingOutputReceiver()
        if (isDemoModeEnabled) {
            for (IDevice device : devices) {
                //turn demo mode on
                device.executeShellCommand("settings put global sysui_demo_allowed 1", grantOutputReceiver)
                device.executeShellCommand("am broadcast -a com.android.systemui.demo -e command enter", grantOutputReceiver)
                //set clock to 12:00
                device.executeShellCommand("am broadcast -a com.android.systemui.demo -e command clock -e hhmm 1200", grantOutputReceiver)
                //hide notification icon
                device.executeShellCommand("am broadcast -a com.android.systemui.demo -e command notifications -e visible false", grantOutputReceiver)
                //change network bars to full with no lte 3g or other logo
                device.executeShellCommand("am broadcast -a com.android.systemui.demo -e command network -e mobile show -e datatype none -e level 4", grantOutputReceiver)
            }
        } else {
            for (IDevice device : devices) {
                //turn off demo mode
                device.executeShellCommand("am broadcast -a com.android.systemui.demo -e command exit", grantOutputReceiver)
            }
        }
    }
}

```

Miért van minden készüléken beállítva a prezentációs mód? Alternatív esetben szükséges lenne az összes készülékhez generálni külön taskot, mivel egy task csak egyszer futhat le. A jelenlegi egy egyszerűbb, gyorsabb megoldás.

Amint ez megvan, az app build.gradle-ben, beállítjuk:

```java

task enableDemoMode(type: DemoModeTask) {
    isDemoModeEnabled = true
}
task disableDemoMode(type: DemoModeTask) {
    isDemoModeEnabled = false
}

tasks.whenTaskAdded() { theTask ->
    if (theTask.name.contains("spoon")) {
        theTask.dependsOn(enableDemoMode)
        theTask.finalizedBy(disableDemoMode)
    }
}

```

A isDemoModeEnabled szabályozza, hogy ki vagy bekapcsoljuk a demó módot. Ehhez 2 taskot kell létrehozni. Egyet, ami a Spoon előtt fut le és egyet, ami utána.

#### Eredmény

Ezek után pár perc alatt megvannak a képek, amit lehet böngészni. Egy másik Gradle taskban akár automatikusan is fel lehetne tölteni a Play Store-ba, ugyanis van hozzá API. De ezt majd máskor…
### Kanter törvénye
URL: https://blog.fps.hu/kanter-torvenye/
Last updated: 2026-07-17T08:28:05.000Z
Jön egy új projekt, izgalom fogja el a csapatot, öröm és boldogság tölt el mindenkit. Vágjunk bele, csináljuk, jó lesz. Aztán jönnek a nehézségek, nem úgy alakulnak az események, ahogy azt elképzeltük. Borulnak a dolgok, keményen dolgozik mindenki, egyszerűen nem látszik, hogy valamikor is véget ér. A „sosem fog elkészülni” érzés járja át a csapatot. Sötét van, nem látszik világosság a távolban.

Ismerős? Pont erről szól Rosabeth Moss Kanter a Harvard Business School professzorának törvénye a [Kanter's law](https://facilethings.com/blog/en/everything-looks-like-a-failure-in-the-middle?ref=blog.fps.hu), ami így hangzik szabad fordításban:

> Minden kudarcnak látszik félúton.

Az állítás ráadásul mindenhol, minden körülmények között igaznak bizonyul, legyen szó egyénről, vagy akár szervezetről. Mindenki szereti az inspiráló kezdetet és a boldog befejezést. Félúton nem jut más, mint a kőkemény munka. Ha ábrázolni szeretném ezt a folyamatot az idő függvényében, akkor egy U-szerű alakot kapnék, ahogy a fejlécképen is láthatod.

Az oka egyszerű: a **változás**. A projekt elején készült egy [hipotézis](https://blog.kolboid.eu/hipotezis-mentalis-kep/?ref=blog.fps.hu), egy terv a megvalósításra. Ahogy haladtok előre az időben, a környezet megváltozik. Félúton döbben rá az ember, hogy a terv nem megvalósítható, sokat kell rajta módosítani. Ezt bizony kudarcnak, sőt sorozatos kudarcoknak éljük meg. Az általános türelmetlenség sem tesz jót: „Ott vagyunk már?”. Lassan elveszítjük a hitünket, az inspirációnkat és beszűkül a tér. Itt szokták feladni az emberek. Mivel ez mindig megtörténik, tartsd ezt észben és akkor talán könnyebben tudtok átlendülni ezen a ponton.

### Mit lehet tenni ellene?

#### Folyamatjelzés

Sétálsz és távolabb meglátsz egy gyümölcsfát. Az agyad nyomban termel egy jó adag dopamint, hogy útra kelj. Ahogy közeledsz, folyamatosan látod, mennyi van még hátra, az agyad újabb és újabb dopamint adagol. Végül mikor odaérsz, kapsz egy órási dopamin fröccsöt. Így működsz. Ezért (is) érdemes a projekthez mérföldköveket kitűzni és szüntelen követni hol tartotok a folyamatban mint, ahogy a kollégáim teszik is:

![Gyuribácsi, mint folyamat jelző sáv az fps irodában a falon](https://blog.fps.hu/content/images/2017/07/gyuribacsi-progress-bar.png)

#### Folyamatos visszajelzés

Ha vezető vagy, akkor elképesztően fontos feladatod, hogy megszakítás nélkül szállítsd a pozitív visszajelzéseket a csapat tagjai számára. Ezek mind segítenek megőrizni a hitet, és kitartást eredményeznek. Ugyebár a kicsi örömök, egyszerű apró dicséretek, a kis győzelmek szerepe: óriási.

#### Vízió

Végül, de nem utolsó sorban, időnként el kell távolodni a hétköznapok problémáitól és madártávlatból szemlélni az eseményeket. Miért is csináljuk ezt az egészet? Milyen célt szolgálunk vele?

**Szóval ne add fel, ne adjátok fel!**
### Tanulj YouTube videókból
URL: https://blog.fps.hu/youtube-csatornak-fejlesztoknek/
Last updated: 2026-07-17T08:28:15.000Z
Az írott anyagokon kívül egyre több videó tutorial, interaktív kurzus áll a tanulni vágyó fejlesztők rendelkezésére. A YouTube-nak köszönhetően adott egy platform, ahol rendszeresen bővülő tartalmat kapunk ingyen vagy pár reklám megtekintéséért cserébe. Ha már ezek adottak, érdemes szemezgetni belőlük, mindig lehet újat tanulni!

### [Codecourse](https://www.youtube.com/user/phpacademy/?ref=blog.fps.hu)

Rengeteg témát dolgoz fel részletesen a csatorna, főleg JavaScript, CSS és PHP témakörben. Teljes projektek mellett számos olyan lejátszási lista akad, ami egy-egy kisebb problémát jár körbe: pl. fájl feltöltés, biztonságtechnika, dátumkezelés stb.

- 260 ezer feliratkozó
- 1160 videó
- #php #laravel #back-end

### [LearnCode.academy](https://www.youtube.com/user/learncodeacademy/?ref=blog.fps.hu)

Front-end témában találhatsz a csatornán érdekes lejátszási listákat. Leginkább azoknak szól, akik csak most ismerkednek egy-egy technológiával vagy keretrendszerrel.

- 357 ezer feliratkozó
- 129 videó (havi 1–2 új)
- #javascript #react #angular #node.js

![the coding train](https://blog.fps.hu/content/images/2017/07/youtube_thecodingtrain-1.jpg)

### [The Coding Train](https://www.youtube.com/channel/UCvjgXvBlbQiydffZU7m1%5Faw?ref=blog.fps.hu)

Daniel Shiffman rendkívül szórakoztató módon, lépésről lépésre mutatja be videónként az egyes témáit. Leginkább JavaScript alapokon fejleszt játékokat nulláról. Elmagyarázza a machine learning alapjait és bevezet a canvas rejtelmeibe a p5.js lib segítségével. Rendszeresen követem az élő adásait is, így a fejembe égett a [This Dot Song](https://soundcloud.com/kristianpedersen/this-dot-feat-daniel-shiffman?ref=blog.fps.hu). ☺

- 286 ezer feliratkozó
- 575 videó (heti 4–5 új)
- #javascript #p5.js #machinelearning #gamedev

### [The New Bostom](https://www.youtube.com/user/thenewboston?ref=blog.fps.hu)

A feliratkozások és videók száma is mutatja, hogy itt bizony komoly mennyiségű tudásanyag található. Webfejlesztéstől kezdve a hálózatokon keresztül a játékfejlesztést, matematikai témákat érintve az alkalmazásfejlesztésig mindenről találhatsz videó tutorialokat, kezdő és haladó szinten egyaránt.

- 1,6 millió feliratkozó
- 4348 videó
- #javascript #python #seo #front-end #node.js #ios #java #c #photoshop

### [Google Developers](https://www.youtube.com/user/GoogleDevelopers/?ref=blog.fps.hu)

A témában kihagyhatatlan a Google hivatalos csatornája, ahol első kézből juthatsz hírekhez a cég legfrissebb fejlesztéseiről és technológiai újításairól, mindezeket rengeteg oktatóvideóval kiegészítve.

- 1,1 millió feliratkozó
- 4433 videó (heti 3–4 új)
- #google #android #javascript #polymer #angular #machinelearning

### [freeCodeCamp](https://www.youtube.com/channel/UC8butISFwT-Wl7EV0hUK0BQ/?ref=blog.fps.hu)

Kissé kilóg a sorból pozitív értelemben a csatorna, mivel a szokásos videó tutorialok mellett számos általánosabb témát is feldolgoz, úgy mint fejlesztői etika, matematika, agilis fejlesztés és clean code.

- 171 ezer feliratkozó
- 377 (heti 4–5 új)
- #livecoding #javascript #datastructure #math #developerlife #cleancode

![level up tutorials](https://blog.fps.hu/content/images/2017/07/youtube_leveluptuts-1.jpg)

### [LevelUpTuts](https://www.youtube.com/user/LevelUpTuts?ref=blog.fps.hu)

A csatornát Scott Tolinski üzemelteti 2012 óta. A témája természetesen a modern webfejlesztés és eszközei, leginkább front-end irányból megközelítve. A [weboldalán](https://www.leveluptutorials.com/?ref=blog.fps.hu) átláthatóbban vannak listázva a csatorna videói, így érdemes onnan kezdened a böngészést.

- 194 ezer feliratkozó
- 933 videó (hetente 1–2)
- #react #vscode #gitlab #html5 #drupal #magento #ublime #wordpress

### [Emarsys Craftlab](https://www.youtube.com/channel/UCOoctvApya3GP9EdCVsq85Q?ref=blog.fps.hu)

Próbáltam magyar csatornákat is keresni, sajnos kevesebb sikerrel. Viszont az Emarsys Craftlab csatornáját már régóta követem és egyértelműen csak ajánlani tudom. A tartalom nagyon sokrétű, általános fejlesztői kérdésekről is szó esik és minden videóból sokat tanulhatsz.

- 457 feliratkozó
- 32 videó (havi 1–2 új)
- #fejlesztés #minőségbiztosítás #módszertanok #tesztelés

### [Webtudor](https://www.youtube.com/channel/UCohOuCO6gLpDuhFs60eEJPQ?ref=blog.fps.hu)

Sajnos már nem nagyon számíthatunk folytatásra, mindenesetre egy remek kezdeményezés volt anno a magyar csatornák között és lehet érdekes dolgokat találni a feltöltött videók között. Érdemes megjegyezni, hogy a történet erősen kapcsolódik a [Refaktor magazinhoz](https://www.refaktor.hu/?ref=blog.fps.hu).

- 919 feliratkozó
- 17 videó
- #drupal #minőségbiztosítás #linux #php #mvc #git #oop

Ha van olyan csatorna, ami szerinted kimaradt a listából, kérlek, oszd meg velünk komment formájában!
### Android Architektúrák – MVVM
URL: https://blog.fps.hu/android-architechturak-mvvm/
Last updated: 2026-07-17T08:28:25.000Z
A Model-View-Presenter(MVP) mellett leginkább ismert tervezési minta a Model-View-ViewModel, ami a 2015 Google I/O-n bemutatott Databinding könyvtárral lett népszerű.

Az [MVP-hez](https://blog.fps.hu/android-architecturak-mvp/) nagyon hasonló feépítésről van szó. A különböző szerepkörök szétválasztását célozza meg, így segítve a tesztelést és karbantartást. Ilyen szerepkör a felület és az üzleti logika.

Model-View-Binding néven is emlegetik, mivel a kulcs ebben a mintában a felület és az adatok között létrejövő kapcsolat. Ha változás történik az adatokban, az megjelenik a felületen is.

![MVVM Model View Presenter diagram](https://blog.fps.hu/content/images/2017/06/model-view-presenter-mvvm.png)

#### Model

Az üzleti logika itt található. Itt van a helye a Java POJO osztályoknak, az adatbázis és API kezelőknek is. Ezeknek a felépítésével nem foglalkozik az MVVM.

#### View

A felület, ami meg fog jelenni, azaz layout XML-ek. Ide tartoznak az Activity és Fragment osztályok is.

#### ViewModel

A ragasztó az üzleti logika és a felület között. Segít a Model változásairól értesíteni a felületedet *databinding* használatával. Feliratkozik és értesül a felület eseményeiről, azaz itt helyezkedik el a felület logikája is.

### Hogyan kell használni?

Egy egyszerű Gradle beállítással engedélyezd az egészet:

```java

android { 
    dataBinding {
        enabled = true
    }
}

```

Az XML layoutokat vedd körül egy új XML taggel:

```xml

<layout xmlns:android="http://schemas.android.com/apk/res/android">
  ...eddigi layout...
</layout>

```

A databinding könyvtár generál a layout fájlból egy osztályt, amit a kapcsolatra használni kell. A neve a layout fájl neve lesz. Például *main\_activity.xml*\-ből *MainActivityBinding* osztály fog keletkezni, mivel az \_ (alulvonás) utáni karaktereket nagybetűvel kezdi és végére csap a névnek egy *Binding* szót. Ezt elérheted az *onCreate()* vagy *onViewCreated()* metódusokban:

```java

//Fragment vagy RecyclerView esetén
FragmentListBinding binding = DataBindingUtil.inflate(inflater, R.layout.fragment_list, container, false);

//Fragment vagy RecyclerView másik lehetőség
FragmentListBinding binding = FragmentListBinding.inflate(inflater, container, false);

//Activity esetén
MainActivityBinding binding = DataBindingUtil.setContentView(this, R.layout.main_activity);

//Activity másik lehetőség
MainActivityBinding binding = MainActivityBinding.inflate(getLayoutInflater());

```

A következő lépésben létrehozod a felülethez tartozó ViewModel osztályodat.  
Ebben lesznek a felületet és Modelt érintő metódusok, változók:

```java

public class ViewModel {
  ...
}

```

Hivatkozol az XML layoutodban a ViewModel osztályodra, mint adatra:

```xml

<layout xmlns:android="http://schemas.android.com/apk/res/android">
  <data>
    <variable
            name="viewModel"
            type="hu.fps.example.ViewModel"/>
  </data>
  
  ...eddigi layout...
</layout>

```

Létrehozod és csatolod a ViewModelt kódban is. Ezt a generált databinding osztályon keresztül lehet megtenni. A generált osztályban lesz egy *setVáltozóNév()* metódus. A „változó név” az előbbi példából a *<variable name="változó név">*:

```java

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.main_activity);

  //Binding létrehozása
  MainActivityBinding binding = MainActivityBinding.inflate(getLayoutInflater());
  
  //ViewModel létrehozása
  ViewModel viewModel = new ViewModel();

  //ViewModel csatolása a view-hoz databindinggal
  binding.setViewModel(viewModel);
}

```

Hogy a felületet feltöltsd adatokkal, hivatkoznod kell rájuk XML-ben. Ezt a becsatolt változón keresztül tudod megtenni, aminek látod a metódusait, változóit:

```xml

   <TextView
    ...
    android:text="@{viewModel.exampleText}" />

```

A fenti példában tehát az XML deklarált a *viewModel* változó *exampleText* metódusára vagy változójára mutatunk. Magától keresi meg melyikről van szó. Szóba jöhetnek a következők:

- publikus *exampleText* változó
- *getExampleText()* metódus
- *exampleText()* metódus

A felhasználótól jövő bemenetre is lehet figyelni, de azt másképp kell megírni az XML-ben:

```xml

   <EditText
    ...
    android:text="@={viewModel.userName}" />

```

Ekkor a ViewModel-ben a *setUserName()* metódust fogja meghívni a rendszer.

A ViewModel-ban történt változásokra akkor tud feliratkozni a felület, ha az *Observable* interface-t implementálod. Szerencsére vannak [wrapper osztályok](https://developer.android.com/topic/libraries/data-binding/index.html?ref=blog.fps.hu#observablefields), amikkel megfigyelhető lesz egy változó:

```java

  private ObservableField exampleText;

```

A fenti *exampleText* változóban elérhető egy *set(String value)* metódus, ami beállítja azt és értesíti a felületet a változásról.

Ezek mind alapvető dolgok, de elkezdeni így lehet. Ha belevágsz még több mindennel fogsz találkozni:

- Saját XML attribútum létrehozása az összekötéshez:  
Ha használsz képletöltőt (Picasso, Glide stb.), akkor az XML-hez egy *app:url=""* attribútumot hozhatsz létre, ahol csak az URL-t kell megadnod. Egy úgynevezett *BindingAdapter*\-ben lesz a kód, ami letölti és beállítja a képet.
- RecycleView kezelése
- XML-ben lévő kód:  
Itt egész bonyolult dolgokat lehet létrehozni, ugyanis logikai operátorok, lambda kifejezések, és még sok minden rendelkezésre áll.

### Amikre figyelned kell

- Logika az XML-ben:  
Figyelni kell, hogy ne rakjon logikát az XML-be senki. Habár erre hiába figyelsz, valaki a csapatból úgyis oda fog rakni valamit.
- Hibakezelés:  
Az esemény vezéreltség miatt nehezebb keresztül lépkedni a kódon. Egy databinding nevű fekete dobozon keresztül állítod be a felületi elem tulajdonságait, ami tovább nehezítheti a hibakeresést.  
Kisebb, javítható hiányosságok is vannak, amik idegesítőek. Például hibás XML esetén az Android Studio csak sor és oszlopszámot dob ki jelenleg, nem tud odaugrani a hiba helyére.

### És most?

Ez csak egy kis segítség a kezdéshez. Ha elkezded alkalmazni, a developer portál [databinding cikkében](https://developer.android.com/topic/libraries/data-binding/index.html?ref=blog.fps.hu) jó segítséget találsz a pontos működéshez.

Amennyiben érdekelnek az ehhez hasonló tervezési minták, akkor ajánlom olvasásra Martin Fowler [Patterns of Enterprise Application Architecture](https://www.martinfowler.com/books/eaa.html?ref=blog.fps.hu) című könyvét.
### Statikus kódanalízis Androidon
URL: https://blog.fps.hu/android-kodelemzes-kodanalizis/
Last updated: 2026-07-17T08:28:38.000Z
Szoftverfejlesztésben a hibák megelőzése kiemelt figyelmet érdemel. Minél később észlelsz egy hibát, annál költségesebb kijavítani. A legjobb az lenne, ha fordítód figyelmeztetne a rossz gyakorlatokra, lehetséges összeomlásra és ajánlásokat adna hogyan javíthatnál a kódodon. Ilyen segítséget nyújt neked a statikus kódanalízis.

Az egész úgy működik, hogy a kód futtatása nélkül ellenőrzöd a kódot. Legtöbb esetben vagy a forráskódon vagy annak egy formáján zajlik egy vizsgálat (például Java esetén, a bájtkódon). Az ellenőrzéseknek lehet célja egy konvenció betartása, komplexitás leszorítása vagy gyakori hibák elkerülése.

### Lehetséges eszközök

#### [Lint](https://developer.android.com/studio/write/lint.html?ref=blog.fps.hu)

Az Android fejlesztői környezethez tartozó kódelemző, ami szorosan integrálva van az Android Studio fejlesztői környezetbe. Nagyrészt [Android specifikus szabályokat](http://tools.android.com/tips/lint-checks?ref=blog.fps.hu) tartalmaz, több csoportba osztva és azon belül is prioritás szerint rendezve.

Alapértelmezetten ezeknek az ellenőrzéseknek egy része szerkesztéskor lefut az Android Studioban. A szerkesztő ki is emeli a hibákat vagy figyelmeztetéseket neked. Ez letiltható és konfigurálható, csak a jobb alsó sarokban lévő rendőr bácsi ikonra kell kattintani. Azt ajánlom, a szerkesztés közben futó ellenőrzéseket módosítsd, mert néha érezhetően belassíthatják az Android Studiot layoutok megnyitásakor.

A teljes vizsgálat az *Analyze* menüpont alatt található *Inspect Code…* opciót választva indítható el. Ez szépen rendezi neked a problémákat és egyes esetekben gyors javításokat is végre tud hajtani.

![teljes lint vizsgálat eredménye](http://i.imgur.com/i3MdXXd.png)

Az analízis a parancssorból is indítható a Gradle segítségével, mégpedig a *lint* parancs kiadásával. Ilyenkor alapértelmezetten XML és egy HTML formátumú riportot is kapsz. A HTML-t szépen lehet navigálni.

Többféleképpen ki tudod zárni az osztályokat, layoutokat a vizsgálatból:

- *@SuppressLint* annotációval kódban
- Layout fájlokban *tools:ignore* használatval
- Egy *lint.xml* konfigurációs fájlban

Ezen kívül a *build.gradle* fájlban is [konfigurálhatod](https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.LintOptions.html?ref=blog.fps.hu). Itt kell ugyanis megadni a *lint.xml* fájl elérési útvonalát. Ebben a fájlban tudod az alkalmazott szabályok prioritását is megváltoztatni.

#### [Findbugs](http://findbugs.sourceforge.net/?ref=blog.fps.hu)

**Szerk.:** A post írásakor már [halott volt](https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html?ref=blog.fps.hu) ez a project, de még nem volt más helyette. Azóta bejelentették a [Spotbugs-ot](https://spotbugs.github.io/?ref=blog.fps.hu) mint utódot és ki is jött 2017 októberében az első használható verzió. A bekötésére találsz példát a [githubunkon](https://github.com/fpshu/android-quality-starter/blob/5a77e0adbe192ccf39d385cdcfa55eb4d024f0be/config/quality.gradle?ref=blog.fps.hu). Ezt használd inkább.

Több mint 10 éves Java bájtkód elemző, ami lehetséges hibák után kutat. Nem csak [saját listája van](http://findbugs.sourceforge.net/bugDescriptions.html?ref=blog.fps.hu), hanem egy [biztonsági](http://find-sec-bugs.github.io/?ref=blog.fps.hu) és még egy [nagyobb kiegészítő lista is](http://fb-contrib.sourceforge.net/?ref=blog.fps.hu).

Android Studioban egy [IntelliJ](https://plugins.jetbrains.com/plugin/3847-findbugs-idea?ref=blog.fps.hu) vagy [Gradle](https://docs.gradle.org/current/userguide/findbugs%5Fplugin.html?ref=blog.fps.hu) bővítmény segítségével lehet használni.  
Mindkettőt testre lehet szabni, bár a Gradle plugint [körülményesebb beállítani](https://github.com/fpshu/android-quality-starter/blob/d4b7adce405b1027908888b0b4c4ca20b1bfd87d/config/quality.gradle?ref=blog.fps.hu#L17).

A szabályok különböző csoportokba (pl.: rossz gyakorlat, biztonság stb.) vannak sorolva. Ez a listán nem látszik, de egy 1–20-ig terjedő prioritásuk is van. 1 az, ami magasabb szintű hiba és a 20, ami alacsonyabb szintű. Elemzés után kapnak egy konfidencia értéket is a talált figyelmeztetések, ami 1-től 3-ig terjed. Az 1-es érték itt is a legmagasabb.

Az elemzőnél be lehet állítani az elemzés mértékét. Egy jobb elemzés több memóriát fogyaszt és lassabb, de több hibát tárhat fel, nagyobb konfidenciával. Továbbá testre szabhatod azt is, milyen prioritású hibák érdekelnek.

A hibát az IntelliJ plugin szépen grafikusan összeszedve felsorolja. A parancssor XML, HTML fájlt generál vagy egyszerűen kitol mindent a parancssori kimenetre. A HTML fájl normálisan böngészhető és a hibák magyarázatai is benne vannak. A prioritás pedig 3-féle színnel jelölve van.

#### [PMD](https://pmd.github.io/?ref=blog.fps.hu)

Egy több nyelvhez használható forráskód elemző, ami leginkább a rossz gyakorlatok felderítésében segít. [IntelliJ](https://plugins.jetbrains.com/plugin/4596-qaplug--pmd?ref=blog.fps.hu) vagy [Gradle](https://docs.gradle.org/current/userguide/pmd%5Fplugin.html?ref=blog.fps.hu) plugin formájában lehet futtatni.

[Nagyrészt Java szabályokat](https://pmd.github.io/pmd-5.6.1/pmd-java/index.html?ref=blog.fps.hu) tartalmaz, de 3 db Android szabályt is találsz köztük. A szabályok átláthatóan csoportosítva vannak a dokumentációban és mindegyik példa kóddal van leírva.

Egy külön XML fájlban tudod konfigurálni, mely szabály csoportok fussanak és ezek közül melyik ne. A téves találatokat a kódodban tudod majd kizárni a *@SuppressWarning* annotációval.

Az eredmény egy XML vagy HTML formában látható vagy az IntelliJ plugin esetében grafikusan. Sajnos a HTML fájlban nincsenek benne talált hibák magyarázatai, hanem a honlapjukra dobnak. Ennek ellenére talán használhatóbb, mert itt nem hibakódok vannak a generált fájlban, hanem egy rövid mondat a hibáról.

#### [Checkstyle](http://checkstyle.sourceforge.net/?ref=blog.fps.hu)

Kód stílusára vonatkozó előírások betartását segíti elő. [IntelliJ](https://plugins.jetbrains.com/plugin/1065-checkstyle-idea?ref=blog.fps.hu) és [Gradle](https://docs.gradle.org/current/userguide/checkstyle%5Fplugin.html?ref=blog.fps.hu) plugin is rendelkezésre áll a futtatásra.

Az ellenőrzés szabályait egy XML fájlban lehet definiálni. Parancssori futtatás után HTML, XML és parancssori kimenetet is kapsz, amiket természetesen külön-külön le is tilthatsz. A HTML kimenet osztályonként van rendezve, amiken belül fel van sorolva melyik sorral mi a probléma.

Az Android Studioban van beépített kódformázás. Persze ez nagyrészt csak a szóközök, tabulátorok és zárójelek elhelyezésében segít, de ezzel is átláthatóbb lesz a kód. Ezt testre lehet szabni a beállítások *Editor* menüpont *Code Style* opciója alatt. Ha a *ctrl+alt+l* (*cmd+alt+l* Mac alatt) parancsot használod, automatikusan formázza a kódot és XML fájlokat erre a stílusra. Verziókövető rendszerbe való feltöltéskor is tudja erre a stílusra formázni a kódot, ha bepipálod a *Commit* ablakban a *Before Commit* résznél a *Reformat Code* négyzetet.

#### [SonarQube](https://www.sonarqube.org/?ref=blog.fps.hu)

Kicsit más eszköz mint többi, mivel ennek külön felülete van, ami egy szerveren fut. Itt lehet adminisztrálni a különböző projekteket és szabályokat. Egy elég komplex megoldás, ezért a beállítással többet kell foglalkozni, mintha egyesével raknád fel a fentieket.

Több nyelvet is tud és pluginokat is kezel, bár ezek közül vannak, amiért fizetni kell. A fenti keresők mind integrálhatóak bele. Mivel ezek mind külső függőségek és nem tudtak rajtuk könnyen változtatni, ezért megalkották a saját elemzőjüket, ami mindezeket egyesíti. Egyszerre dolgozik forrás és bájtkódon, hogy kevesebb téves találat legyen. Kb. 1600 szabály van és ehhez még hozzáveheted a Findbugs, PMD és Checkstyle és Android lint keresések eredményeit.

Magát a felületet [kipróbálhatod a honlapjukon](https://sonarqube.com/projects?ref=blog.fps.hu). Érdemes megnézni, mert még azt is megmutatja mennyi idő kijavítani egy-egy hibát.

### Beállítás

Legjobb ha a Gradle pluginokat használod, így verziókezelőből letöltve bárhol használhatod. Ráadásul, ha csapatban dolgozol ők is tudják használni a kódelemzőket, nem kell mindenkinek telepítenie valamit.

Nézd meg az [android-quality-starter](https://github.com/fpshu/android-quality-starter?ref=blog.fps.hu) GitHub repót. Benne van minden. Arról van szó, hogy a projekteden belül létrehozol egy külön *quality* mappát a beállításoknak.  
Ezen belül egy *quality.gradle* fájlt a Gradle beállításoknak. Ez fogja tartalmazni a Gradle plugin beállításokat.  
Ezt becsatolod a build.gradle fájlba:

```java

apply from: '../quality/quality.gradle'

```

A keresők konfigurációs fájljai a *quality* mappán belül almappákban vannak. Javaslom egyenként próbáld ki és állítsd be őket. Az annotációs processzort vagy reflectiont használó könyvtárak szinte mind téves figyelmeztetéseket okoznak, ezért ezeket ki kell majd zárni valamilyen módon.

Érdemes fokozatosan bevezetni azokat a szabályokat, amik a kód stílusára vonatkoznak. Így alkalmazkodni lehet hozzájuk és nem lesz túl sok teher a változás. Ennek ellenére a szabályok segíthetnek más megvilágításba helyezni a problémákat. Ne add fel vagy kapcsolj ki egy szabályt, ha első látásra nem tudod megoldani.

Az összes vizsgálatot a *check* Gradle paranccsal lehet futtatni. Mivel külön mappában van minden, könnyen behúzhatod más projektekhez.

### Eredmény

Ha be lett állítva minden és megvannak a találatok, akkor neki lehet esni a javításnak. Persze itt adódnak gondok. Ugyanis nem fogja senki sem futtatni ezeket a teszteket, mert sokáig tart, körülményes, az eredmény nem könnyen átlátható stb.  
Itt jön be a képbe a CI azaz Continous Integration. Egy központi szerver, ami lefordítja a kódot és szól, ha baki történt. De ez egy másik alkalomra szóló mese.
### Magyar (mobil)web sebesség 2017
URL: https://blog.fps.hu/magyar-mobil-web-sebesseg-2017/
Last updated: 2026-07-17T08:28:47.000Z
Harmadik éve és most utoljára vizsgáltuk meg a magyar webet mobil optimalizáltság, oldal betöltési sebesség és titkosított kapcsolat szempontok szerint. [Olvasd el a tavalyi eredményeket és következtetéseket](https://blog.fps.hu/magyar-mobil-web-sebesseg-ssl/)! Ebben a posztban kizárólag a 2016-ról 2017-re egy év alatt történt változásokat írtuk le. Minden alapvetés és fő gondolat megtalálható a korábbi írásban.

### Eredmények

Íme a kutatás eredményei számokban.

#### 2017\. június

- **mobilon átlag oldalbetöltési sebesség: 53,59 pont** – 2016: 60,05 pont
- **desktopon átlag oldalbetöltési sebesség: 59,46 pont** – 2016: 65,19 pont
- az oldalak **82,89%-a szolgálja ki a mobil eszközökkel** rendelkező felhasználókat – 2016: 79,61%
- az oldalak **49,67%-a használ responsive** megoldást – 2016: 41,78%
- az oldalak **33,22%-a használ szeparált, vagy RESS** megoldást (mobil eszközökhöz) – 2016: 37,83%
- az oldalak **39,47%-a használ SSL tanúsítványt** (https) – 2016: 14,47%
- **mobilon** a felhasználó által **letöltött adatmennyiség átlagosan 4,11MB** – 2016: 3,81MB. A legdurvább 55MB :o, de nem ritka a 10MB feletti letöltés sem, ami a mobilos adatforgalmat tekintve még mindig súlyos
- **desktopon** a felhasználó által **letöltött adatmennyiség átlagosan 5,03MB** – 2016: 4,89MB

Ha az oldalbetöltési sebességek szerinti elosztást nézed (növekvően), akkor látszik csak igazán a helyzet. Még mindig alig mint az oldalak 6–12%-a teljesíti a Google (és a felhasználók) elvárásait, viszont látható egy jobb (pozitív) irányú eltolódás, ami mindenképpen üdvözlendő.

![2016 vs. 2017. oldalbetöltési sebesség mobilon](https://blog.fps.hu/content/images/2017/06/2016-vs-2017-oldalbetolesi-sebesseg-mobil-1.png)

![2016 vs. 2017. oldalbetöltési sebesség desktopon](https://blog.fps.hu/content/images/2017/06/2016-vs-2017-oldalbetolesi-sebesseg-desktop-1.png)

#### Változás egy év alatt

- az oldalbetöltési sebesség átlagosan **mobil esetén 6,46 ponttal csökkent**, míg **desktop esetében 5,73 ponttal romlott** a helyzet
- átlagosan ugyan csökkent, de az előző ábrán jól látható, hogy összességében pozitív irányú fejlődés tapasztalható
- tovább **bővült a mobilos eszközökkel rendelkező felhasználók kiszolgálása**
- a **responsive megoldás tovább növekedett**, összesen\*\* 34 oldal állt át\*\* erre a technológiára
- az **SSL tanúsítvány**, a titkosított kapcsolat használata **jelentősen megnőtt** 14,47%-ról **39,47%-ra**

#### Következtetések

- **foglalkozni kell az oldalbetöltési sebességgel**, mert ezek kifejezetten rossz eredmények
- **SSL használat gyorsan terjed**, de még van hova fejlődni
- az állami szektor oldalai még mindig nem szolgálják ki a mobilosokat és nem használnak titkosítást sem
- az **e-kereskedelemmel foglalkozó oldalak mind használnak SSL-t**
- a **versenyszférában működő oldalak mindegyike támogatja a mobilos eszközöket**, szemben a monopol helyzetben lévőkkel

Fontos az oldalbetöltési sebességen javítani a felhasználók és SEO szemszögéből is, de nem szabad megfeledkezned arról, hogy a [gyors sebesség érzete, az idő érzékelése szubjektív, olvass hasznos trükköket](https://blog.kolboid.eu/gyors-mukodes-illuzioja-sebesseg-erzet/?ref=blog.fps.hu)!
### Androidos újdonságok a Google I/O 2017-en
URL: https://blog.fps.hu/google-io-2017/
Last updated: 2026-07-17T08:28:57.000Z
Újra eljött az idő, amikor a Google megbombáz minket elég sok bejelentéssel és prezentációval egy konferencia keretében. Nagyjából [54 darab, összesen 30 órányi Androidos prezentációt](https://www.youtube.com/watch?v=1N9KveJ-FU8&list=PLWz5rJ2EKKc-odHd6XEaf7ykfsosYyCKp&ref=blog.fps.hu) tudsz megnézni. Kigyűjtöttem a szerintem lényegesebb, érdekesebb infókat és prezentációkat:

### Újdonságok

#### Kotlin

Mostantól a Google is támogatja ennek a nyelvnek a használatát Androidhoz. Ha valakit visszatartott a támogatás hiánya, most már ez az akadály is eltűnt.

Az IntelliJ-t fejlesztő JetBrains hozta létre a nyelvet még 2011-ben. Az elmúlt 1-2 évben kapott szárnyra, lett népszerű.

![Kotlin sorok száma githubon 2016-ra 2 millót elérte](https://blog.jetbrains.com/kotlin/files/2016/02/KotlinAdoption.gif)

A nyelv előnye többek között, hogy tömör, nullpointer hibákat teljesen ki lehet szedni a kódból és az Android Studio is teljes mértékben támogatja.

Hátránya a fiatalsága, ezért stílusok és fejlesztési irányelvek nincsenek, ezeket le kell fektetni. Bár az úttörő munka egyeseket csábíthat.

Ha többet szeretnél megtudni a nyelvről és jövőéről nézd meg, ahogy a [JetBrains bemutatja](https://www.youtube.com/watch?v=czKo-jPVweg&ref=blog.fps.hu) és ahogy [más fejlesztők beszélnek róla](https://www.youtube.com/watch?v=fPzxfeDJDzY&ref=blog.fps.hu).

#### Instant Apps

Telepítés nélküli appok. Tavaly jelentették be őket, amikor egy zárt tesztelés indult, ezúttal pedig minden fejlesztő számára elérhető lett.

Implementálásához fel kell osztani a kódot modulokra. Ezek a modulok URL alapján lesznek elérhetőek és önállóak. Egyenként 4MB-ot nyomhatnak maximum a modulok. Az Instant Appok 23-as API-tól érhetőek el és limitált hozzáféréssel a rendszerhez. Mielőtt ráharapnál jól nézd meg tudod-e használni.

Két prezentációt is tartottak erről. Egyik leginkább a [használatáról szól](https://www.youtube.com/watch?v=oispNrpGnIY&ref=blog.fps.hu), a másikban pedig a [készítésére adnak példát](https://www.youtube.com/watch?v=9Jg1D07NgeI&ref=blog.fps.hu).

#### Architektúra

Ez az egyik talán leghasznosabb bejelentés. Sokan panaszkodnak a Fragmentek életciklusára és arra, hogy Androidon nincs ajánlott architektúra. Most tettek egy jó lépést ennek megoldására.

4 darab komponenst jelentettek be:

- Room
- LiveData
- LifeCycleOwners – LifeCycleObservers
- ViewModel

##### Room

AZ SQLite adatbázisodat kötheted össze Java pojo osztályokkal egyszerűen. Nagyon hasonló a Retrofithez, ha már haszáltad, ha nem akkor annotációkat kell használni ahova SQL-t kell írni. SQL fordítási időben ellenőrizve van. RxJava-val kompatibilis.

##### LifeCycleOwners and LifeCycleObservers

Egyes app komponenseknek életciklusuk van, ezért gyakran az onStop és onStart metódosokban kötnek ki. Ilyen például egy LocationListener osztály. Ezeket a fentiek segítségével külön osztályokba tudod átrakni, így függetleníteni az adott Activity-től vagy Fragmenttől.

##### LiveData

Egy olyan osztály, ami adatot tartalmaz. Ennek az adatnak a változásaira feliratkozhatsz, azaz megfigyelheted. Például a Room-mal tudsz LiveData adatot visszaadni, így figyelni az adatbázis változásait.

##### ViewModel

Az adataidat függetleníteni tudod a Fragmentek és Activity-k életciklusától.  
Például létrehozol egy ViewModel osztály, amint létrejön az Activity. Ha elforgatod a képernyőt ugyanazt a ViewModel-t fogod visszakapni. Csak akkor fog elpusztulni, amikor elhagyod ezt a képernyőt. Így megtarthatod az adataid, hálózati hívásaid konfiguráció váltások között is.

Ez így nyilvánvalóan elég bonyolult első olvasásra, ezért nézz meg egy [összefoglaló prezentációt](https://www.youtube.com/watch?v=FrteWKKVyzI&ref=blog.fps.hu) róluk. Megnézheted még a [részletesebb prezentációt](https://www.youtube.com/watch?v=MfHsPGQ6bgE&ref=blog.fps.hu) is a Room-ról. Van már [dokumentáció](developer.android.com/arch) is az Android developer portálon.

#### Fejlesztői környezet

Az eddigi 2.4-es Android Studio-t átnevezik 3.0-ra, mivel annyi új funkció van benne. Ilyenek:

- Kotlin
- Java 8
- Play Store az emulátoron
- Fájl böngésző az emulátorhoz
- APK analyzer fejlesztése, Proguard szabály támogatással, APK-k összehasonlítással
- Adaptive icon generátor
- Támogatás Instant App-hoz
- [Layout editor fejlesztések](https://www.youtube.com/watch?v=nYb4FUdlLZE&ref=blog.fps.hu)
- Databinding támogatás RecyclerView previewhoz
- Új memória, CPU, hálózat profiler
- [2016.3](https://www.jetbrains.com/idea/whatsnew/?ref=blog.fps.hu#v2016-3) és [2017.1](https://www.jetbrains.com/idea/whatsnew/?ref=blog.fps.hu#v2017-1)\-es IntelliJ integrálva van benne

Gradle fejlesztések között van végre, hogy Debug és Release módban is lehet futtatni a könyvtárakat. Az incremental compiler is gyorsabb lett.

Összességében elég sok minden van, két videót érdemes megnézned ezzel kapcsolatban:

- [Gyors összefoglaló](https://www.youtube.com/watch?v=rHiA66zUv8c&ref=blog.fps.hu)
- [Prezentáció a Google I/O-n](https://www.youtube.com/watch?v=Hx%5FrwS1NTiI&ref=blog.fps.hu)

#### Support lib

Jön a 26-os support lib. Rögtön fel is emelik a minimum SDK-t 14-re, de ez nem ér valószínűleg senkit sem meglepetésként.  
Fontosabb, hogy maven repóként elérhető, így nem kell SDK managerből letölteni:

```css

repositories {
    maven {
        url 'https://maven.google.com'
    }
}

```

Betűtípus kezelés terén is fejlődnek. Android O újítása a font resource mappa, ami elérhető lesz a support könyvtárban is.  
Mivel a fontok nagyban növelhetik az appok méretét, ezért előálltak a letölthető fontokkal. Így nem kell a betűtípusokat az APK-ba berakni, hanem első indításkor lehúzza a rendszer. A Google 800 ingyenes fontja ilyen formában elérhető.

Az EmojiTextView segítségével az új emojikat is használatba veheted. Ezek eddig az Android OS-ben voltak, így a régi api szinteken nem volt elérhető minden emoji. Ennek használatához külön függőséget szükséges majd behúznim mert külön View osztályokban érhetőek el.  
AutoSize TextView a következő újdonság, ahol a szöveg mérete változik a konténerrel együtt. Ezt a meglévő TextViewCompat osztályba integrálták és a *app:autoSizeTextType* XML taggel érhető majd el.

Az animációknál is vannak újdonságok. Jönnek a [fizikán alapuló animációk](https://www.youtube.com/watch?v=BNcODK-Ju0g&ref=blog.fps.hu). A Rúgózás egy jó példa erre.

A [prezentáció](https://www.youtube.com/watch?v=V6-roIeNUY0&ref=blog.fps.hu) tartalmaz még TV-s és vektoros újításokat is, ezért érdemes megtekinteni.

#### Play Console

Ha mostanában használtad a Play Console-t, akkor látni lehetett hogy teljesen átalakult. Itt nagyon sok újdonság van:

##### Android vitals

Statisztika az app teljesítményéről és lehetséges problémákról. A Crash-ek és ANR-ek száma most már megemelkedik, mivel alapból gyűjti mindenkinél, aki az Android első indításnál beleegyezett az adatgyűjtésbe.  
Nem csak hibák, hanem lassú és helytelen működés is látszani fog itt.

##### Google Play App Signing

Amikor elveszíted az APK-t aláíró kulcsodat, azt nem tudod pótolni, új appot kell létrehoznod. Ennek kivédésére elhelyezheted a kulcsodat a Google-nél. Egy feltöltési kulccsal kell aláírni majd az APK-dat, amit pótolni lehet, ha elveszíted. Ez lehetőséget ad arra is, hogy optimalizálják az appodat kiadás előtt. Egyenlőre nem kötelező részt venni benne, de talán ez lesz, majd a megoldás a lejáró kulcsokra.

##### Készülék katalógus

Lecserélték a régi katalógust. A készülékekről van már több információ, szűrés, keresés.

##### Jobb statisztika

Itt eléggé nagy változtatás történt. Egyes statisztikák már élőben jönnek. A kiadásokat és más statisztikákat össze lehet hasonlítani egymással, hogy megtudhassuk hogyan teljesít az új verzió vagy milyen összefüggések vannak.

Ezekről van pár prezentáció:

- [összefoglaló](https://www.youtube.com/watch?v=L9uKkhCCRZA&ref=blog.fps.hu)
- [Készülék katalógus összefoglaló](https://www.youtube.com/watch?v=5tdGAP927dk&ref=blog.fps.hu)
- [statisztika összefoglaló](https://www.youtube.com/watch?v=Dr82cv6Lj0c&ref=blog.fps.hu)
- [App Signing és kiadás összefoglaló](https://www.youtube.com/watch?v=peCWuCSIv7U&ref=blog.fps.hu)

#### O

Tovább folyik a háború a háttérben folyó számítások ellen az akkumulátoridő megmentésére. Ha arra vagy kíváncsi pontosan miért is csinálják ezt, [elmondták](https://www.youtube.com/watch?v=hbLAzwhBjFE&ref=blog.fps.hu).  
Sajnos egyes [infók](https://commonsware.com/blog/2017/05/24/android-o-background-limitations-not-just-targetsdkversion-o.html?ref=blog.fps.hu) szerint nem csak az O-t megcélzó alkalmazásokra fognak vonatkozni a korlátozások. Az O-t futtató telefonok bármely API-t megcélzó alkamazás háttérbeni folyamatait korlátozhatják.

Designerek számára fontos újdonság a [színprofilok támogatása](https://www.youtube.com/watch?v=r8NeG0wmFXM&ref=blog.fps.hu).

Értesítéseket is teljesen átdolgozták. Ha O-t célzod meg, akkor kötelező ezzel foglalkoznod. Bevezették a csatornákat és sorba rendezték az értesítéseket is prioritás szerint. Egy [UX prezentációban](https://www.youtube.com/watch?v=vwZi56I0Mi0&ref=blog.fps.hu) és egy [áttekintőben](https://www.youtube.com/watch?v=TB-K6OniF68&ref=blog.fps.hu) megtudhatod a részleteket.

Egy dolog, amit jó volt hallani az az ART-hoz tartozó optimalizációk voltak. Gyorsítottak a objektumok lefoglalásán, ciklusokon és kevesebb memóriát fog használni a rendszer. Ajánlom a [prezentációt](https://www.youtube.com/watch?v=iFE2Utbv1Oo&ref=blog.fps.hu), ahol még többet megtudhatsz.

### Ajánlott prezentációk

#### Teljesítmény

Most, hogy Play Console-on megjelent a Vitals menüpont, voltak a teljesítménnyel kapcsolatos előadások is. Egy [áttekintő prezentáció](https://www.youtube.com/watch?v=1N9KveJ-FU8&list=PLWz5rJ2EKKc-odHd6XEaf7ykfsosYyCKp&ref=blog.fps.hu) különböző eszközökről. Egy [prezentáció gfx infó és systrace használatról](https://www.youtube.com/watch?v=Qfo5fdoXrTU&ref=blog.fps.hu).

#### Flutter

Cross-platform programozási nyelv a Flutter. iOS, Android és Fuchsia rendszerekre lehet fordítani. Dart nyelven kell programozni hasonlóan a React-hoz. Még alfa állapotban van, de lehet próbálgatni. Erről tartottak [előadást](https://www.youtube.com/watch?v=w2TcYP8qiRI&ref=blog.fps.hu).

#### Egyéb

- [Kisebb APK előadás](https://www.youtube.com/watch?v=AdfKNgyT438&ref=blog.fps.hu), tippek között Proguard, haszontalan fordítások eltávolítása, multi apk, kisebb képek.
- [Gradle build felgyorsítása 10 lépésben](https://www.youtube.com/watch?v=7ll-rkLCtyk&ref=blog.fps.hu),  
ezt érdemes megnézni ha küzködsz
- [Tesztelés a support test könyvtárral](https://www.youtube.com/watch?v=pK7W5npkhho&ref=blog.fps.hu)
### Képfeldolgozás Androidon 1. – Bevezetés
URL: https://blog.fps.hu/kepfeldolgozas-androidon-1-bevezetes/
Last updated: 2026-07-17T08:29:07.000Z
Ebben a néhány részes cikksorozatban az Androidos telefonokkal kapcsolatban fogom körüljárni a digitális képfeldolgozás témakörét. Ez az írás leginkább „mit hogyan” típusú lesz, erősen technikai jellegű. Ennek ellenére nem csak fejlesztőknek lehet érdekes, hiszen megrendelőként sem árt tisztában lenni a lehetőségekkel vagyis, hogy mit is bír el a „vas”. Lesznek tehát teljesítmény mérések is. Ez az egyik oka annak, hogy amennyire lehet, próbálom kerülni a különböző külső függvénykönyvtárakat. A másik ok, hogy igazából ez a legérdekesebb része az egésznek, hülye lennék pont ezt kihagyni. Amúgy sem túl hasznos mondjuk 3–4 szűrőért behúzni egy 50 megás gépi látásra írt függvénykönyvtárat, viszont szeretném szemléltetni, hogy milyen apróságok mennyit számítanak egy-egy szűrő implementálásánál.

### Amit nem árt, ha tudsz

A képfeldolgozás egy relatíve nehéz és nagy terület, leginkább a sok matematikai formula miatt, amire szükség van hozzá. Viszont látványos, és emiatt hamar nyújt sikerélményt a nehézségek ellenére. Megmondom őszintén, hogy középiskolában és az egyetem első éveiben kimondottan utáltam mindenféle matekot. Így utólag persze rájöttem, hogy csak azért, mert elfelejtették közölni azt az apróságot, hogy egy-egy képlet mi a fenére használható. Van néhány terület, ahol azonban elég hamar értelmet nyernek a tanultak. Ilyenek a fizikai szimulációk, a hang-, kép- és egyéb jelfeldolgozási problémák, valamint a háromdimenziós grafika. Szóval igazából minden érdekesebb dologhoz kell a matek. Szerencsére diszkrét esetekben – amikor csak a különálló pontokat ismerjük, a függvényt magát nem – azért nagyban leegyszerűsödnek a dolgok. A digitális jelek, mint a képek, hangok, mért gyorsulás stb. ilyenek, így szerencsére viszonylag egyszerű dolgunk lesz. Tehát ha hadilábon állsz az egyetemi matekkal, akkor néhány komolyabb probléma okozhat fejtörést, de általában elboldogulhatsz nélküle.

### Hardveres követelmények

Rengeteg lehetőséget rejt a mobilok beépített kamerája. Gondolj csak az augmented reality appokra, vagy az arccserélő hülyeségekre, de hogy valami hasznosat is mondjak, érdemes ránézni a [google realtime fordítójára](https://www.youtube.com/watch?v=06olHmcJjS0&ref=blog.fps.hu). A cikksorozatban tehát a kamera előnézeti képéből fogok kiindulni.

Azt viszont tartsd észben, hogy a képfeldolgozás egy meglehetősen teljesítményigényes téma. Alapvetően sok memóriát és minél erősebb processzort, ebből kifolyólag rengeteg energiát igényel. Na a mobiltelefonokban pont ezekből van kevés, de legalább jó nagy felbontású kijelzőkkel és még nagyobb felbontású kamerákkal szerelik őket, így a feldolgozandó képek mérete elég nagy. Ilyen helyzetben előtérbe kerül a megfelelő optimalizálás. A méréseket egy Huawei p9 lite-tal végeztem. Egyrészt ez a készülék egy tömegek számára is elérhető középkategóriás mobil, másrészt lehet rajta küzdeni a gyártóspecifikus érdekességekkel, de erről majd később. Ennél a készüléknél rendelkezésre áll egy 8 magos processzor és 2GB memória, valamint támogatja az Android camera2 API-ját (ezt fogom használni a későbbiekben a kamera képének kinyerésére). Tud FullHD felbontású előnézeti képet adni, ami tök hasznos, de most nem fogom használni, ugyanis annak a valós idejű feldolgozása egy asztali rendszert is megránt, nemhogy egy középkategóriás mobilt.

### Android

Az Androidos alkalmazások alapvetően Java nyelven íródnak. Biztonságos, jól olvasható, viszonylag könnyen tanulható nyelv. Nem lehetetlen benne memory leaket csinálni, de meg kell érte dolgozni. Ha képfeldolgozással szeretnék foglalkozni, akkor viszont sajnos el is felejthetem. Egyrészt a managelt kód általában lassabb valamelyest, másrészt a Java nem kezel előjel nélküli típusokat. Ez azt jelenti, hogy a 8 bit/csatornás képek esetén jellemzően 0-255 közötti értéket felvevő intenzitás értékeket nem nagyon lehet a Java-s byte típusban tárolni, mivel annak értékkészlete -128 és 127 között van. Pontosítok, tárolni lehet, hiszen 8bit az 8bit, de észnél kell lenni, amikor felhasználod a kapott értékeket. Nem megoldhatatlan a probléma, némi bitmaszkolással és az éppen használt érték egyéb típusban (jellemzően int-ben) tárolásával megoldható. Igen, több memória és processzor idő árán.  
A számításintenzív, vagy alacsony késleltetést igénylő kódokat bizony C, vagy C++ nyelven kell megírni. Szerencsére keverhető a két megoldás, így az app alapvető logikája írható Java-ban, a számításigényesebb képfeldolgozó algoritmusok pedig C, vagy C++ nyelven. Ha nem vagy otthon ezen nyelvek valamelyikében, akkor a továbbiakban nehézségekbe ütközhetsz, de mivel a Java alapvetően ezekből a nyelvekből származik, nem annyira vészes megtanulni. A memóriakezelésnél viszont észnél kell lenni, mivel a Java-val ellentétben elég könnyű memory leak-et csinálni, vagy rossz memória címre írni, amitől azonnal összeomlik az alkalmazás.

Másik alternatíva a RenderScript, aminek egyik nagy előnye, hogy a GPU-t is bevonja a munkába, így a jól párhuzamosítható számításokat – mint amilyenek a képfeldolgozó algoritmusok – eléggé meggyorsíthatja. Hátránya viszont, hogy a C, vagy C++ kódokkal ellentétben sajnos csak Androidon működik – ahogy az Apple féle Metal API csak iOS-en –, így a több platformot érintő fejlesztéseknél nem nagyon jöhet számításba.

A nyílt OpenCL szabványt, amelynek hasonló lenne a célja, sajnos sem az Android, sem az iOS nem támogatja hivatalosan, tehát ha a GPU-t is be szeretnéd vonni a számításokba, kénytelen vagy a platformspecifikus API-kat használni.

### Kezdjünk hát neki

A kamera képét viszonylag könnyű kirajzolni. A Google-nek is van [példakódja](https://github.com/googlesamples/android-Camera2Basic?ref=blog.fps.hu) rá. Én is ebből a példából fogok kiindulni. Módosítanom kell majd, hogy a képet ne rajzoljam ki közvetlenül a TextureView-ba, hanem azt feldolgozható formában kapjam meg. A tovább haladáshoz érdemes a példát átnézni, ugyanis annak tartalmát nem fogom tárgyalni, csak a szükséges módosításokat. A C nyelvű kódrészletek hozzáadásához is van tutorial az [Android oldalán](https://developer.android.com/studio/projects/add-native-code.html?ref=blog.fps.hu).

#### A kamera képének kinyerése a camera2 API-val

Első lépésként létrehozok egy ImageReader.OnImageAvailableListener-t, mely a kapott kép feldolgozásáért lesz felelős.

```java

private final ImageReader.OnImageAvailableListener mOnImageAvailableForProcessingListener
            = new ImageReader.OnImageAvailableListener() {

        @Override
        public void onImageAvailable(ImageReader reader) {
            Image img = null;
            img = reader.acquireLatestImage();

            if (img != null) {
                ByteBuffer buffer = img.getPlanes()[0].getBuffer();//Y channel buffer of YUV color image
                byte[] data = new byte[buffer.remaining()];
                buffer.get(data);
                final int width = img.getWidth();
                final int height = img.getHeight();

                img.close();
            }

        }
    };

```

Az utolsó sorban található img.close() hívás meglehetősen fontos. Nélküle pár kép után összecsuklik az alkalmazás java.lang.IllegalStateException-el.

A setUpCameraOutputs(lásd [sample](https://github.com/googlesamples/android-Camera2Basic/blob/master/Application/src/main/java/com/example/android/camera2basic/Camera2BasicFragment.java?ref=blog.fps.hu)) metódusban, hozok létre egy ImageReader-t a következőképpen:

```java

mImageReaderProcessing = ImageReader.newInstance(mPreviewSize.getWidth(), mPreviewSize.getHeight(), ImageFormat.YUV_420_888,2);

mImageReaderProcessing.setOnImageAvailableListener(mOnImageAvailableForProcessingListener, mBackgroundHandler);

```

Feltűnhet, hogy képformátumnak a YUV\_420\_888-at adtam meg. Ennek egyszerű oka van. A camera2 API ezt támogatja előnézet esetén ([bővebben](https://developer.android.com/reference/android/hardware/camera2/package-summary.html?ref=blog.fps.hu)). Ennek egyik előnye, hogy az Y csatorna maga a fekete-fehér kép, így ha a feldolgozás során ebből szeretnél kiindulni, akkor egy lépéssel előrébb vagy. Ha a színes előnézeti képre lenne szükséged, akkor át kell konvertálni a kapott képet. Egyelőre megelégszem a fekete-fehér képpel.

Ezután a createCameraPreviewSession metódushoz adom hozzá a következőket:

```java

Surface imageSurface = mImageReaderProcessing.getSurface();
mPreviewRequestBuilder.addTarget(imageSurface);

```

Majd ugyanitt átírom a következő sort erről:

```java

mCameraDevice.createCaptureSession(Arrays.asList(surface, mImageReader.getSurface()),
                    new CameraCaptureSession.StateCallback() {...

```

erre:

```java

mCameraDevice.createCaptureSession(Arrays.asList(mSurface, imageSurface),
                    new CameraCaptureSession.StateCallback() { ...

```

És nagyjából ennyi módosítással megkaptam az előnézeti képet fekete-fehérben egy byte tömbben, párhuzamosan a kirajzolással. Ez már alkalmas arra, hogy feldogozd és a kinyert információt megjelenítsd valamilyen formában. A fejlesztéshez azonban jó lenne látni, hogy mit csinálok, így a feldolgozott kimentet is meg kell tudni jeleníteni.

#### Feldolgozott kép kirajzolása TextureView segítségével

Először is kiveszem a TextureView-unkból csinált Surface-t a Surface listából, ugyanis ha erről elfelejtkezel, akkor amikor ki akarod rajzolni a képet, a következő hibát kapod majd:

E/BufferQueueProducer: \[SurfaceTexture-0-30254-1\] connect(P): already connected (cur=4 req=2)

Tehát a createCaptureSession hívásod így fog kinézni:

```java

mCameraDevice.createCaptureSession(Arrays.asList(imageSurface),
                    new CameraCaptureSession.StateCallback() { ...

```

Első körben teljesen Java-ban fogom megoldani a dolgot, de csak azért hogy lásd mennyivel gyorsabb a natív kód, mert bizony gyorsabb.

```java

private final ImageReader.OnImageAvailableListener mOnImageAvailableForProcessingBitmapListener
            = new ImageReader.OnImageAvailableListener() {

        Bitmap bm;

        Bitmap byteArrToBitmap(byte[] src, int width, int height) {
            byte[] bits = new byte[src.length * 4];
            int i;
            int j=0;
            for (i = 0; i < src.length; i++) {
                j=i*4;
                bits[j] =  src[i];
                bits[j + 1] =  src[i];
                bits[j + 2] = src[i];
                bits[j + 3] = (byte)0xff; // the alpha.
            }
            if(bm == null || bm.getWidth() != width || bm.getHeight() != height) {
                if(bm != null)bm.recycle();
                bm = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);
            }
            bm.copyPixelsFromBuffer(ByteBuffer.wrap(bits));
            return bm;
        }

        @Override
        public void onImageAvailable(ImageReader reader) {
            Image img = null;
            img = reader.acquireLatestImage();

            if (img != null) {
                ByteBuffer buffer = img.getPlanes()[0].getBuffer();
                byte[] data = new byte[buffer.remaining()];
                buffer.get(data);
                final int width = img.getWidth();
                final int height = img.getHeight();
                img.close();
             
                SurfaceTexture texture = mTextureView.getSurfaceTexture();
                texture.setDefaultBufferSize( width,height);
                Canvas s = mSurface.lockCanvas(new Rect(0,0,mPreviewSize.getWidth(),mPreviewSize.getHeight()));
                Bitmap b = byteArrToBitmap(data,width,height);
                s.drawBitmap(b,0,0,null);
                mSurface.unlockCanvasAndPost(s);
            }
        }
    };

```

Ez a megoldás az, amit igazából el kell felejteni, mert ugyan megoldható, de mint a későbbiekben látni fogod, jóval lassabb, mint a natív implementáció.

A natív kódot használó megoldás Java-s fele a következőképpen néz ki:

```java

private final ImageReader.OnImageAvailableListener mOnImageAvailableForProcessingListener
            = new ImageReader.OnImageAvailableListener() {

        @Override
        public void onImageAvailable(ImageReader reader) {
            Image img = null;
            img = reader.acquireLatestImage();

            if (img != null) {
               ByteBuffer buffer = img.getPlanes()[0].getBuffer();
               byte[] data = new byte[buffer.remaining()];
               buffer.get(data);
               final int width = img.getWidth();
               final int height = img.getHeight();
               img.close();

               PreviewHelper.drawBytesToSurface(mSurface, data, width, height, 1, 1);
            }
        }
    };
```

Nagy varázslat nincs benne, gyakorlatilag egy wrappert hívok megfelelően paraméterezve.

A wrapper osztály a natív kódhoz igazából egy törzs nélküli metódus, meg a natív lib betöltése:

```java

public class PreviewHelper {
    // Used to load the 'native-lib' library on application startup.
    static {
        System.loadLibrary("native-lib");
    }
    public native static void drawBytesToSurface(Surface surface, byte[] pixelData,int w, int h , int colors, int threadNumber);
}
```

A lényeg, vagyis a célbufferbe másolás alapvetően nem egy bonyolult dolog, így kicsit megbonyolítottam, hogy több szálra szét lehessen bontani a műveletet. Mint később látni fogod a mérési eredményekből, nem teljesen hülyeség.

A native-lib.cpp file tartalma a következőképpen néz ki:

```c

#include <jni.h>
#include <android/native_window.h>
#include <android/native_window_jni.h>
#include <pthread.h>

#define MAX_THREAD_NUMBER 16

/**
 * DataStructures
 */
struct imgProcArgs_struct {
    unsigned char *destImg;
    int destWidth;
    int fromdestHeight;
    int todestHeight;
    int fulldestHeight;
    unsigned char *srcImg;
    int srcWidth;
    int srcHeight;
    int destColors;
    int srcColors;
};

extern "C"
void
*copyImgGrayToImgRGBA(void *arg) {
    struct imgProcArgs_struct *args = (struct imgProcArgs_struct *) arg;
    int destIndex = args->destWidth * args->fromdestHeight * 4;
    int len = args->destWidth * args->todestHeight;
    for (int i = args->destWidth * args->fromdestHeight; i < len; i++) {

        *(args->destImg + destIndex++) = *(args->srcImg + i);
        *(args->destImg + destIndex++) = *(args->srcImg + i);
        *(args->destImg + destIndex++) = *(args->srcImg + i);
        *(args->destImg + destIndex++) = 0xFF;

    }
    return NULL;
}

extern "C"
void
createCpyThread(pthread_t *thread, imgProcArgs_struct *cpyArgs, unsigned char *destImg,
                int destWidth, int fromdestHeight, int todestHeight, unsigned char *srcImg,
                int destColors, int srcColors) {

    cpyArgs->destImg = destImg;
    cpyArgs->destWidth = destWidth;
    cpyArgs->fromdestHeight = fromdestHeight;
    cpyArgs->todestHeight = todestHeight;
    cpyArgs->srcImg = srcImg;
    cpyArgs->destColors = destColors;
    cpyArgs->srcColors = srcColors;

    pthread_create(thread, NULL, copyImgGrayToImgRGBA, (void *) cpyArgs);
}

/**
 * JNI functions
 */
extern "C"
JNIEXPORT void JNICALL
Java_hu_fps_rtcamimgproc_ui_PreviewHelper_drawBytesToSurface(JNIEnv *env, jclass type,
                                                                  jobject surface,
                                                                  jbyteArray pixelData_, jint w,
                                                                  jint h, jint colors,
                                                                  jint threadNumber) {
    jbyte *pixelData = env->GetByteArrayElements(pixelData_, NULL);
    ANativeWindow *window = ANativeWindow_fromSurface(env, surface);

    ANativeWindow_setBuffersGeometry(window, w, h, WINDOW_FORMAT_RGBA_8888);

    ANativeWindow_Buffer buffer;
    if (ANativeWindow_lock(window, &buffer, NULL) == 0) {
        int width = buffer.width;
        int height = buffer.height;

        pthread_t threadArr[MAX_THREAD_NUMBER];
        struct imgProcArgs_struct cpyArgs[MAX_THREAD_NUMBER];

        int tNum = threadNumber;
        if (tNum > MAX_THREAD_NUMBER) {
            tNum = MAX_THREAD_NUMBER;
        }

        for (int i = 0; i < tNum; i++) {
            createCpyThread(&threadArr[i], &cpyArgs[i], (unsigned char *) buffer.bits, width,
                            height * i / tNum, height * (i + 1) / tNum,
                            (unsigned char *) pixelData, 4, colors);
        }

        for (int i = 0; i < tNum; i++) {
            pthread_join(threadArr[i], NULL);
        }

        ANativeWindow_unlockAndPost(window);
    }

    ANativeWindow_release(window);

    env->ReleaseByteArrayElements(pixelData_, pixelData, 0);
}
```

A lényeg az ANativeWindow használata, ami önmagában ennyi:

```c

ANativeWindow* window = ANativeWindow_fromSurface(env, javaSurface);

ANativeWindow_setBuffersGeometry(window, w, h, WINDOW_FORMAT_RGBA_8888);

ANativeWindow_Buffer buffer;
if (ANativeWindow_lock(window, &buffer, NULL) == 0) {
  memcpy(buffer.bits, pixels,  w * h * 4);
  ANativeWindow_unlockAndPost(window);
}

ANativeWindow_release(window);
```

Ennyi elég is lenne, ha RGBA módban kapnám a képet és egy szálon szeretném másolni. Mivel csak szürke árnyalatos képem van, így kénytelen vagyok egy ciklussal végigiterálni a forrás buffer minden pixelén és gyakorlatilag háromszor belemásolni a célbufferbe, valamint az alpha csatornát kitölteni fixen a maximális értékkel.

Amire érdemes odafigyelned – ugyanis én belefutottam ebbe a hibába –, hogy nem minden készülék tud bármilyen bufferméretet kezelni az ANativeWindow esetén. A Huawei p9 és p9 lite készülékeken az 1440\*1080-as felbontáshoz nem sikerült beállítanom megfelelően a buffert, aminek az lett az eredménye, hogy ezen a felbontáson teljesen használhatatlan képet kaptam. Egyelőre úgy tűnik, hogy a szélesség és magasság szorzatának oszthatónak kell lennie 512-vel. Nexus 5 és Samsung Galaxy S7 készülékeken ezzel a problémával nem találkoztam. De hát ezért szép Androidra fejleszteni, hiszen ahány gyártó annyi féle móka…

Szóval már kirajzoltam a képet, de látható, hogy valami nem stimmel.

![Kép: Hibás forgatás, torz képarány](https://blog.fps.hu/content/images/2017/04/wrong_rotation_and_ratio_600.png)

Az eredeti kódon még faragni kell egy kicsit, ugyanis máshogy rajzolom a TextureView-ra, mint a kamera eredeti előnézeti implementációja. A configureTransform metódust a következőképpen kell módosítani:

```java

private void configureTransform(int viewWidth, int viewHeight) {
        Activity activity = getActivity();
        if (null == mTextureView || null == mPreviewSize || null == activity) {
            return;
        }
        int rotation = activity.getWindowManager().getDefaultDisplay().getRotation();
        Matrix matrix = new Matrix();
        RectF viewRect = new RectF(0, 0, viewWidth, viewHeight);
        RectF bufferRect = new RectF(0, 0, mPreviewSize.getHeight(), mPreviewSize.getWidth());
        float centerX = viewRect.centerX();
        float centerY = viewRect.centerY();
        if (Surface.ROTATION_0 == rotation) {
            bufferRect.offset(centerX - bufferRect.centerX(), centerY - bufferRect.centerY());
            matrix.setRectToRect(viewRect, bufferRect, Matrix.ScaleToFit.FILL);
            float scaleH = (float) viewHeight / mPreviewSize.getHeight();
            float scaleW = (float) viewWidth / mPreviewSize.getWidth();
            matrix.postScale(scaleH, scaleW, centerX, centerY);
            matrix.postRotate(90, centerX, centerY);
        }
        mTextureView.setTransform(matrix);
    }
```

Mindjárt jobban néz ki az eredmény. Végre a telefon orientációjának megfelelően látod a képet és a képarány sem torzul.

![Kép: Helyes forgatás, helyes képarány](https://blog.fps.hu/content/images/2017/04/proper_rotation_and_ratio_600.png)

Végeztem is. Most már minden adott ahhoz, hogy lásd is majd, mit csinálok a kamera képének feldolgozása során.

#### Mérjünk kicsit

Na de ennyi kód után nézzük meg, hogy mennyivel gyorsabb a natív kód, mint a Java-s Canvas-ra rajzolgatás. A több szálú feldolgozást csak a natív kódra csináltam meg, mivel jól láthatóan egy szálon is bőven veri a Java-s Canvas-ra épülő megoldást.

Tehát egy Huawei p9 lite készüléken a kép kimásolása a kimenetre milliszekundumban:

1920\*1080 Canvas: 264-266ms  
1920\*1080 ANativeWindow thread nélkül:96-97ms  
1920\*1080 ANativeWindow 1 thread: 103-105ms  
1920\*1080 ANativeWindow 2 thread: 57-60ms  
1920\*1080 ANativeWindow 4 thread: 39-42ms  
1920\*1080 ANativeWindow 8 thread: 39-42ms

640\*480 Canvas: 38-39ms  
640\*480 ANativeWindow thread nélkül: 16-17ms  
640\*480 ANativeWindow 1 thread: 21-22ms  
640\*480 ANativeWindow 2 thread: 13-15ms  
640\*480 ANativeWindow 4 thread: 12-14ms  
640\*480 ANativeWindow 8 thread: 12-14ms

Jól látható, hogy FullHD felbontáson a natív kódnak több mint 2,5-szeres előnye van. Ez az előny 640\*480-as felbontáson 2-szeresre olvad, ami még mindig jelentős előrelépés. Az is látható, hogy a szálkezelést az okoztott overhead miatt, csak akkor érdemes használni, ha valóban szükség van rá. Jellemzően nagyobb felbontásoknál és komplexebb számításoknál ez az overhead eltörpül, így mindenképp érdemes minden magot hajtani. Mint látod ebben az esetben, amikor nem egy szimpla memcpy-vel másolom a pixeleket, már megéri több szálon végezni, bár 2-4 szálnál hiába használsz többet.

#### Folytatás következik

Kicsit hosszúra sikerült a poszt, de úgy gondoltam, hogy a bevezetéshez is szeretnék valami kézzel fogható, hasznos tartalmat produkálni (remélem sikerült), amivel bárki el tud indulni, akit érdekel a téma. Várhatóan a folytatások sem lesznek túl rövidek. Terveim szerint legközelebb néhány képszűrőt fogok implementálni. Tehát folyt. köv.
### Folyamatos működés a MySQL világában
URL: https://blog.fps.hu/folyamatos-mukodes-a-mysql-mariadb-vilagaban/
Last updated: 2026-07-17T08:29:18.000Z
A címben *MySQL* szerepel, de a poszt inkább a *MariaDB* nevezetű forkról fog szólni, és annak különböző nagy rendelkezésre állású megoldásairól, külön kitérve, hol melyik megoldás működik, vagy épp inkompatibilis egymással.

### MariaDB vs. MySQL

Pár szóban a *MariaDB-ről* azoknak, akik nem ismernék. A történet egészen addig nyúlik vissza, mikor az *Oracle* felvásárolta a *MySQL AB-t* a *Sun-on* keresztül. Az eredeti fejlesztőcsapat megalakította a *MariaDB Foundation-t*, és forkolta a *MySQL-t*. Amíg a *MySQL* fejlesztése és funkcióbővítése megmaradt az *Oracle* fejlesztők kezében, azt az *Oracle* üzleti igényei befolyásolják, addig a *MariaDB* fejlesztését a közösség viszi előre, szem előtt tartva, hogy amennyire lehet a *MariaDB* binárisan kompatibilis maradjon a *MySQL-lel*, ellenben sok közösségi igényű újdonsággal kibővítse az eredeti működést.

### High Availability

A rövid kitérő után visszatérve a bejegyzés eredeti témájához. A nagy rendelkezésre állással (*HA - High Availability*) kapcsolatban még tisztázni kell egy alapvető elméletet, a *CAP* tételt.

![CAP tétel választható variációi](https://blog.fps.hu/content/images/2017/04/cap-tetel.png)

A rövidítés a *Consistency* (Konzisztencia), *Availability* (Rendelkezésre állás) és a *Partition tolerability* (Partíció-tűrés) kezdőbetűiből áll össze. Konzisztencia esetén minden egyes lekérdezésnél ugyanazokat az adatokat kell visszaadnia az egész rendszernek, rendelkezésre állás esetén a rendszer minden részének elérhetőnek kell lennie, partíció-tűrés esetén pedig az egész rendszer működőképes marad akkor is, ha a rendszer valamilyen okból kifolyólag szétesik kisebb, önállóan működőképes egységekre. Ebből a 3 tulajdonságból egy rendszerben csak 2 lehet jelen egyszerre.

A relációs adatbáziskezelő rendszerek a *CA* vonalon mozognak, azaz az adatok konzisztensek és elérhetőek, ez felel meg az *ACID* (*Atomicity* – atomicitás, *Consistency* – konzisztencia, *Isolation* – izoláció, és *Durability* – tartósság) elveknek is. A Partíció-tűréssel az a probléma *RDBMS-ek* (Relációs adatbáziskezelő rendszerek) esetén, hogy ha szétesik a rendszer, adminisztrátor legyen a talpán, aki újra összeszinkronizálja a szétesett partíciókat, ezt hívják *Split-Brain* helyzetnek. Ugye senki nem akar ilyet!

Nagy rendelkezésre állású rendszereknél így kulcsfontosságú működés a *fencing*, azaz valahogy a renitens rendszert elkülöníteni a többitől. Ebből következik, hogy legalább 3 elemű rendszernek kell lennie, így többségi szavazás alapján el lehet dönteni, melyik elemet kell kizárni. Ennek a legbrutálisabb, egyben leghatékonyabb esete az, a STONITH (*Shoot The Offending Node In The Head*), azaz egyszerűen lekapcsolják a szinkronból kiesett rendszert. Ez a gyakorlatban úgy működik, hogy a HA kezelő szoftver megkerülve mindent, direktben a szerver menedzsment kapcsolatán keresztül végrehajt egy force shutdown-t. Kész, lehalt, lelőtték, és jó esetben minden megy tovább, csak esetleg kicsit lassabban.

A folytatás ezt követően elég egyszerű, a leállított szerver ténye kivált egy riasztást az adminok felé, hogy leállt, ők elindítják a problémás szervert izoláltan és valamilyen módon átmásolják a szinkronban lévő rendszerből a helyes adatokat. Innentől kezdve a kiesett node visszailleszthető az egész rendszerbe.

Mielőtt fejjel mennél a falnak és az első Google találat után felhúznád az első rendszered, érdemes mérlegelni, mire is van szükséged, és a rendszert használó alkalmazások mit támogatnak. Ebből a megközelítésből számos lehetőséged van, különböző céllal.

### Master-slave replication

A klasszikus felállás, van egy fő szerver, ami dolgozik, és van egy meleg tartalék szerver, ahol minden megvan ugyanúgy, csak nem lehet rá írni. Ezt mindenki ismeri. Még a *MySQL* is.

2 fő felhasználási lehetősége van:

- folyamatos, közel valós idejű mentés biztosítása
- egyszerű terhelés elosztás olvasás intenzív feladatok esetén, mivel a *slave* node használható *read-only* módban

### Master-master replication

A klasszikus *master-slave* replikáció megcsavarva egy kicsit. Ez is működik *MySQL* alatt. Ebben az esetben mindkét szerver írható és olvasható is egyben. A csavar ott van, hogy 1 darab *master-master* replikációs rendszer 2 darab *master-slave* replikációs rendszerből áll össze. Hogyan áll össze ez 2 szerver esetén? – teheted fel a kérdést. Hát egy ügyes trükk alkalmazásával, mindkét node egymás *masterjei* és *slavejei* is egy időben.

És pont itt rejlik az egész buktatója, ami miatt veszélyes. Mivel 2 szerverről van szó, egyszerű többséggel nem lehet eldönteni, kinél vannak friss adatok, kinél nem, így kulcsfontosságú a monitorozás, hogy él-e a szinkronizációs folyamat, illetve ha él is, mennyire van szinkronban, nem laggol, késik-e véletlenül? Hiszen, ha nem vagy arra felkészülve, hogy úgy nyers erőből beletégy sok-sok adatot az adatbázisba, amit már a hálózaton csak lassan bírsz átküldeni, akkor bizony inkonzisztencia lesz. Igazából ez a probléma bármilyen aszinkron replikációnál fennáll.

Felhasználási lehetőség:

- klasszikus terhelés elosztás, mondjuk *round-robinnal*
- *High Availability*, mondjuk *Virtual IP*\-vel és *keepalived*\-vel.

### Multi-source replication

Ez a lehetőség a *MySQL* 5.7-es és a *MariaDB* 10.0-ás verziójától érhető el. Nagyban hozzájárult a lefejlesztéséhez, hogy a *MySQL*\-nél és a *MariaDB*\-nél is rájöttek, hogy azért vannak problémák ezekkel a nagy bináris logokkal, amiken keresztül az adatbázis szerverek kommunikáltak egymással. Ehelyett kitalálták a *GTID* (*Global transaction Identifier*) használatát. A technológia lényege, hogy a bináris logok egyrészt soronként tartalmazzák az adatokat, másrészt az összetartozó tranzakciókat egyedi számsorral jelölték meg, így replikáció esetén eldönthető nagyon egyszerűen, hogy egy adott tranzakció replikálva kerül, vagy sem. Egyszerűen meg kell nézni, hol áll a *GTID*.

Ennél a pontnál van nagy eltérés a *MySQL* és *MariaDB* *GTID* implementációjában, és innentől kezdve ez a két rendszer inkomptabilis egymással.

*MySQL* esetén a *GTID* egy karakterlánc és egy szám azonosító elválasztva egy :-al. Az első fele egy forrás megjelölő azonosító, mely a forrás szervert azonosítja, általában a *server\_uuid* értéke. A másik fele egy tranzakciós azonosító, ami egy szekvencia szám, ami a tranzakciók végrehajtásának sorrendjét adja meg.

*MariaDB* esetén talán picit jobban és átláthatóbban csinálták meg az implementációt. Ebben az esetben a *GTID* 3 db számból áll, - jellel elválasztva. Az első szám egy domain azonosító, ami esetén nagyjából azt képes lefedni, hogy a binlog nem feltétlenül egy sima rendben lévő folyam, hanem akár több folyam is lehet egyszerre. A második szám egy szerver azonosító szám. A harmadik pedig meglepő módon egy tranzakció azonosító.

```
MariaDB [sql3]> show all slaves status\G;
*************************** 1. row ***************************
Connection_name: sql1
Slave_SQL_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_IO_State: Waiting for master to send event
Master_Host: sql1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 1179
Relay_Log_File: sql3-relay-bin-sql1.000002
Relay_Log_Pos: 1464
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Skip_Counter: 0
Exec_Master_Log_Pos: 1179
Relay_Log_Space: 1766
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_Server_Id: 101
Using_Gtid: Current_Pos
Gtid_IO_Pos: 1-101-21,0-103-6,2-102-12
Parallel_Mode: conservative
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 23
Slave_received_heartbeats: 350
Slave_heartbeat_period: 1800.000
Gtid_Slave_Pos: 0-103-8,1-101-21,2-102-18
*************************** 2. row ***************************
Connection_name: sql2
Slave_SQL_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Slave_IO_State: Waiting for master to send event
Master_Host: sql2
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 1392
Relay_Log_File: sql3-relay-bin-sql2.000002
Relay_Log_Pos: 1677
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Skip_Counter: 0
Exec_Master_Log_Pos: 1392
Relay_Log_Space: 1979
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_Server_Id: 102
Using_Gtid: Current_Pos
Gtid_IO_Pos: 1-101-16,0-103-6,2-102-18
Parallel_Mode: conservative
Retried_transactions: 0
Max_relay_log_size: 1073741824
Executed_log_entries: 23
Slave_received_heartbeats: 349
Slave_heartbeat_period: 1800.000
Gtid_Slave_Pos: 0-103-8,1-101-21,2-102-18
2 rows in set (0.00 sec)
```

Maga a *multi-source replication* alapja az, hogy egy *slave* node-nak, több *master* node adja az adatokat. A felhasználási területei inkább már nagyobb rendszerek kapcsán merül fel, például:

- egy folyamatos mentést tárolni az összes adatbázis szerverről, így nem kell mentés céljából bejárni az egész adatbázis farmot
- big data jellegű adatelemzés esetén, ahol esetlegesen az adatbázisok vagy adatbázis táblák particionálva vannak több szerver között, viszont statisztika kinyerése vagy mentés céljából egy helyen meg kell lennie minden adatnak időszakos olvasási elérés miatt

### Galera cluster

A *Galera cluster* a *MariaDB* 10.1 része telepítéstől kezdve érhető el és semmilyen egyéb speciális telepítést nem igényel. A korábbi verziókhoz külön patchelt verzióként telepíthető, ugyanúgy, ahogy a *MySQL*\-hez is.

A rendszer hátránya, hogy kizárólag *InnoDB/XtraDB* engine-nel használható, bár ha összeveted az *InnoDB* és *MyISAM* előny-hátrányait, valószínűleg úgy is *InnoDB*\-t fogsz használni. Néhány megkötése van, mint pl. minden esetben kell primary key, különben nem tudja a *DELETE* metódusokat lefuttatni, és primary key nélküli táblák sorrendje különböző node-okon különböző sorrendben jelenhet meg, de végül is *RDMS*\-ről van szó, nem *NoSQL*\-ről. Másrészt érdemes a potenciálisan ütközést okozó, vagy nagy méretű kéréseket optimalizálni. Érdemes szem előtt tartani, hogy egy sort csak egyszer lehet egy időben módosítani, különben conflict lesz.

![Galera cluster blokkvázlat](https://blog.fps.hu/content/images/2017/04/galera-cluster.png)

Számos előnye van a normál felállásos master-slave alapú replikációval szemben. A *Galera cluster* minden esetben multi-master replikációként lép fel, de egy saját *wsrep API*\-t használ erre, nem a gyárilag beépített mysql replikációt. Mivel a normál *MySQL* protokoll helyett saját megoldáson kommunikál, így képes több mint 2 szerver esetén többségi szavazással (*quorum*) a particionált rendszert fenntartani, illetve új node belépése esetén automatikusan felszinkronizálni azt a teljes clusterhez. A saját *API* használatának másik hozadéka, hogy szinkron replikációt valósít, és erre képes nagy távolságú hálózatokon is, igaz írási folyamatok esetén a gyorsaság az ára ennek. Ezt a teljesítmény csökkenést szokták kompenzálni vegyes megoldásokkal, például adatközponton belül *Galera cluster*, adatközpontok között tradicionális *multi-master* replikáció, így kisebb gondot okoz a hálózati késleltetés.

### ProxySQL

A *ProxySQL* nem klasszikusan egy adatbázis szerver, bár a konfigurációját egy *MySQL* alapú saját adatbázisban tárolja, hanem egy kiegészítő – meglepő módon – proxy szerver bármilyen cluster megoldáshoz.

![ProxySQL forgalomirányítási képességgel](https://blog.fps.hu/content/images/2017/04/proxysql.png)

A *ProxySQL* erőssége abban rejlik, hogy széleskörűen testre szabható, így a felhasználási területének gyakorlatilag a kreativitás szab határt. Nyilván tud tartani szervereket, szerver csoportokat, amikhez kapcsolódik, avagy nem, azok között súlyozni, kapcsolódó felhasználói név alapján forgalmat irányítani. Van lehetőség SQL kérésekre, reguláris kifejezések alapján eldönteni, mely node-hoz menjen a forgalom, így szét lehet választani az írási és olvasási szervert. *Virtuális IP*\-vel lehetőség van nagy rendelkezésre állású rendszert is építeni egy egyszerű *keepalived*\-vel. Ahogy korábban írtam, a beállításait saját magában, *MySQL* alapú adatbázisban tárolja, így azt el lehet érni valós időben távolról is, így dinamikussá lehet tenni a működését. Reguláris kifejezésekkel meg lehet tiltani, hogy bizonyos kérések lefussanak, így akár egy tűzfal szerű működést is ki lehet hozni a rendszerből. Mindezt teszi úgy, hogy kihasználja a jelenlegi modern CPU-k több magos képességét, így nagy rendszerek is építhetőek vele.

### Kooperáció

Jól látszik, hogy számos, egyszerűbb és komplexebb megoldás áll az üzemeltetők rendelkezésre, viszont jól látható cél, felhasználói és üzleti igény nélkül nehéz dönteni. Majdnem minden esetben nem árt, ha az üzemeltetői oldalról valaki leül a vezető fejlesztővel és esetleg az adatbázis tervezővel beszélgetni a készülő űrállomás méretű projektről, mivel az üzemeltetők és a fejlesztők életét is meg lehet könnyíteni, ha közösen dolgoznak. Biztosan fel kell készülniük a fejlesztőknek is arra, hogy az általuk fejlesztett kód képes legyen működni egy megtervezett HA környezetben. De ez már egy másik történet…
### Űr van a piacon
URL: https://blog.fps.hu/magyar-digitalis-ugynokseg-piac/
Last updated: 2026-07-17T08:29:27.000Z
A 2000-es évek elején, amikor már webes projektekkel foglalkoztunk, csak néhányan voltunk a cégben. Ráadásul igencsak jól működtünk. Nagyjából pont fogalmunk sem volt, mit csinálunk, de tettük a dolgunkat, tanultunk. Igen, voltak excelben készült drótvázak, meg flash intro, és oldal betöltés számlálók. :) Így visszatekintve és átgondolva, már tudom mitől voltunk hatékonyak.

Egy apró csapatból álltunk, amiben volt egy projekt menedzser, egy fejlesztő, egy grafikus és **mindannyian terveztünk**, méghozzá közösen, együtt az ügyféllel. Beszélgettünk olyanokkal, akiknek készült, sőt emberek kezébe is adtuk a terméket, ha nem is a tényleges felhasználókéba. Akkor nem tudtuk, hogy gyakorlatilag felhasználói kutatásokat, teszteléseket csinálunk, egyszerűen csak józan paraszti ésszel jót akartunk kreálni. Működött.

### Az első lépcsőfok

Aztán hirtelen nőni kezdtünk, egyre több lett a munka. 10–15 főig gyorsan pörögtek az események. Ekkor jött el az a fejlődési lépcsőfok, amikor rogyadozni kezdtek a projektek. Szükség lett szervezeti felépítésre, középvezetői rétegre. Nehéz ezt megugrani, de sikerült, ha nem is elsőre. Azóta számtalan felállást próbáltunk ki, de az igazit nem találtuk meg. Sok hasonló és nagyobb cég vezetőivel beszélgettem már erről, illetve számtalan cikket, interjút olvastam a nagyvilágban működő cégek vezetőivel. A konklúzió: senki sem találja az ideális modellt.

### A második lépcsőfok

Utána jön a következő fejlődési lépcsőfok. A tisztulásé. A 20–30 fős szervezetben szinte biztosan vannak olyan szereplők, főleg középvezetői szinten, akik több munkakört visznek. Több mindenért felelnek, így valójában egyik területüket sem tudják 100%-osan ellátni. Emiatt komoly feszültségek vannak, és ez erősen kihat a profitabilitásra is. Arról nem beszélve, hogy ezek a „multiarcok” csakhamar durván kiégnek.

Erről a lépcsőfokról úgy lehet tovább lépni, ha minden csapattag egyetlen, jól körülhatárolt és definált feladatkörrel bír. Ergo bővülni kell minőségi kollégákkal. Sokkal. Tekintve, hogy milyen kevés a (jó) szakember, nem egyszerű a feladat. Egyáltalán nem. Vagyis ez egyáltalán nem kizárólag tőke kérdése. Az viszont igen, hogy ekkora méretnél a cég még nem képes akkora bevételt generálni, hogy elegendő mennyiségű pénzt fordítson kutatás-fejlesztésre. Márpedig, ha nincs K-F, akkor nincs fejlődés, nincs innováció. Anélkül viszont garantált a lemaradás.

Nem véletlenül írtam fentebb, hogy több mint 15 éve, hogyan lehettünk hatékonyak. Azt gondolom, hogy pontosan azt a felépítést kell követni. Sejteket kell létrehozni. Sokat. Organikus szervezetet. Design sejt, Web sejt, App sejt, IoT sejt… Mi már át is álltunk, és folyamatosan ezen dolgozunk. Például egy webes sejt az fpsben így néz ki: 1 projekt menedzser, 2–3 webfejlesztő, 1 graphic/UI designer, 1 UX designer. Szerintünk így lehet hasznos és jó terméket létrehozni, méghozzá hatékonyan.

### Magyar digitális „ügynökségek”

Magyarországon elképesztően sok kis cég van, akik nem tudták megugrani az első fejlődési lépcsőfokot. A kis műhelyek nagyszerű munkát végeznek, de nem piaci tényezők. Illetve van néhány UX-re fókuszáló cég, akik egyik hátránya, hogy nem tudják vállalni a fejlesztést. Mondhatod, hogy együttműködnek fejlesztő cégekkel, bevonják a programozókat a tervezési folyamatba, de a tapasztalatom az, hogy ez nem olyan könnyű és egyszerű, mint amilyennek hangzik. Az ideális az, ha házon belül megvan a technológiai tudás is. A másik hátrányuk, hogy nem tudnak több nagy ügyfelet párhuzamosan megfelelően kiszolgálni. Az első lépcső határán lebegők pedig épp a megfelelő minőséggel küzdenek.

Az első két lépcsőfok között már nagyságrendekkel kevesebb cég található. Velük az a baj, hogy bár jó minőséget tudnak garantálni, de nagyobb volument nem képesek kiszolgálni és nem elég stabilak. Sem szervezetileg, sem gazdaságilag.

A második lépcső felett viszont csak néhány cég található, akik időközben mind egy nagyobb multinacionális vállalat részévé váltak és/vagy alapvetően nem magyar piacra dolgoznak. Itt tátong a címben emlegetett űr.

### Kereslet

Jelenleg is óriási a kereslet, ami ráadásul folyamatosan nő. Mire? Főleg tervezésre, azaz designra. Olyan digitális termékekre, melyeket a felhasználók szeretnek, örömmel használnak, számukra értékes és hasznos, hiteles, vonzó, netán érzelmileg kötődnek hozzá. Mitöbb profitot termel a tulajdonosának, az üzemeltetőinek, akik szívesen dolgoznak vele.

Mindeközben ügyfél oldalon sokszor nincsenek tisztában azzal, hogy mennyivel komplexebbek lettek a digitális termékeik, így nemhogy egyszerűbb és olcsóbb lett a tervezés, hanem épp ellenkezőleg: sokrétűbb és ennek megfelelően drágább. Azaz a piac passzívan is bővül. Ha az ügynökségek nem képesek együtt növekedni a feladatok összetettségével, akkor lényegében a meglévő ügyfeleiket sem tudják kiszolgálni.

Az igazság az, hogy igazából nincsenek nagy volumenben dolgozó, magas minőséget nyújtó digitális ügynökségek Magyarországon. Pedig nagy szükség van rájuk. Hogyan tudnám ezt a fajta digitális ügynökséget megfogalmazni?

### Digitális ügynökség

Így: Ember-központú digitális termék tervezéssel és fejlesztéssel foglalkozó ügynökség. Nem média, nem marketing. Ilyen mondjuk az fps. :) Mi meg épp most ugorjuk át a második lépcsőt és fogjuk kitölteni az űrt. Hogyan? **Hamarosan megtudod!**

[a fejléc kép A. L. Crego munkája](http://alcrego.tumblr.com/post/99189130766/la-naus%C3%A9e-original-photo-i-say-lets-evolve?ref=blog.fps.hu)
### Augmented Reality a weben!
URL: https://blog.fps.hu/augmented-reality-a-weben/
Last updated: 2026-07-17T08:29:37.000Z
Néhány napja megjelent egy [függvénytár](https://github.com/jeromeetienne/AR.js?ref=blog.fps.hu), ami futótűzként terjedt el szakmai körökben, és én is azonnal ráfagytam a dologra: Augmented Reality megoldás JavaScript-tel! Noha a dolog nem újkeletű és már korábban is voltak hasonló megoldások, most mégis átléptünk egy mérföldkövet.

### Kezdjük az elején!

Az [Augmented Reality](https://en.wikipedia.org/wiki/Augmented%5Freality?ref=blog.fps.hu) (kiterjesztett valóság) nem új technológia. A kilencvenes évektől aktívan fejlesztik és látványos eredményeket értek el a területen, ám mindig a hardver határozta meg a működését, mivel elég erőforrásigényes.

![már a Vissza a jövőben című filmben is megjelent](https://blog.fps.hu/content/images/2017/03/jaws191.jpg)

A kétezres évektől a fejlődés felgyorsult, köszönhetően az okostelefonok megjelenésének, hiszen egyetlen eszközben volt minden szükséges technológia: processzor, szenzorok (GPS és egyéb mozgást érzékelő szenzorok), kijelző, kiegészülve a kamerával. Viszont a képfeldolgozás és megjelenítés továbbra is sok számítással járt, amit csak natív appokban lehetett elérni. A felhasználási területe rendkívül sokrétű, webshopoktól kezdve az oktatásbon át ipari célok, játékok és a legkülönfélébb vizuális prezentációk megvalósításakor kihasználták, hogy a valóságot „kiegészítsék” számítógép által generált tartalommal. Nekem leginkább az [IKEA alkalmazása](https://www.youtube.com/watch?v=xC6t2eEPkPc&ref=blog.fps.hu) tetszik, amivel előre láthatjuk, hogyan is nézne ki az adott termék a környezetünkben.

### Akkor most mi is az újdonság?

Röviden?

> JavaScript alapokon 60fps-sel futó AR alkalmazás

Évek óta próbálkoznak olyan megoldásokkal, amik webes alapokon (elsődlegseen telefonon megnyitva) hozzák az Argumented Reality hatást, és mindezt akadásmentesen. Született is számos megoldás, de még egyik sem volt annyira stabil és használható, hogy az mindennapi felhasználásra alkalmas legyen, inkább csak tech demók voltak.  
A most megjelent [verzió](https://github.com/jeromeetienne/AR.js?ref=blog.fps.hu) azonban már orvosolta ezeket a problémákat, és a készítő le is mérte, hogy egy két éves készülékén is megfelelő gyorsasággal és pontossággal fut. Mindezt webes környezetben, JavaScript alapokon, megspékelve 3D-s objektumok támogatásával ([three.js](https://blog.fps.hu/irjunk-jatekot-three-js/)).

Egy Augmented Reality alkalmazás működése technikailag úgy néz ki, hogy minden esetben kell egy „marker”, ami egyfajta kontrollpontként szolgál a generált tartalom elhelyezéséhez. A script legenerál egy 3D-s teret, amit megjelenít a kontrollpont helyzetétől és irányától függően, és gyakorlatilag a kamera képére rendereli, így a kettő egyet alkot.

![működés közben](https://blog.fps.hu/content/images/2017/03/augmented-reality-web-threejs-fps-logo.jpg)

Természetesen nem kötelező minden esetben kontrollpont, hanem támaszkodhatunk csupán a szenzorokra is a tartalom „mozgatását” illetően (így működik pl. a Pokémon Go alkalmazás is).

### Ez miért is jó?

Ahogy a fentiekben is írtam, a felhasználási lehetőségek rendkívül sokrétűek. Azzal, hogy eljutottunk oda, hogy webes környezetben is működőképes a technológia, ismét léptünk egyet előre. A felhasználókat bizonyos esetben nehéz rávenni, hogy külön alkalmazásokat telepítsenek, arról nem is beszélve, hogy mennyi plusz költséggel jár egy ilyen lefejlesztése. Viszont egy weboldal részeként már teljesen más a helyzet. A felhasználók meg tudják nyitni a böngészőjükben és azonnal megkapják az „extra tartalmat”. Elég csak belegondolni, milyen mértékben fel lehet dobni egy kiállítást vagy körbejárható módon megjeleníteni bármilyen objektumot, az interaktív játékokról már nem is beszélve.

Én azt gondolom, hogy örüljünk és használjuk ki a lehetőséget!
### Projekt menedzsment? Köszönöm, nem kérem.
URL: https://blog.fps.hu/projekt-menedzsment-koszonom-nem-kerem/
Last updated: 2026-07-17T08:29:47.000Z
Mondja az ügyfél számtalanszor, amikor meglátja tételként az árajánlatban.  
De gondolj bele, amikor 4+ ember dolgozik együtt, ráadásul különböző területek szakértői, ki az, aki összefogja az egészet, hogy ne legyen belőle káosz? Olyan közvetítő közeget képzelj el, ami totális összhangot teremt ahhoz, hogy a digitális termék értéke ne a 0 felé konvergáljon.

### Mi van az emberek fejében?

Amikor megkérdezik, hol dolgozol, elhangzik a cég neve és profilja…  
„Akkor fejlesztő vagy?” – hangzik a kérdés csillogó szemekkel, ebben a pillanatban te vagy az Isten.  
Majd amikor elmondod, hogy te tulajdonképpen PM vagy, kissé csalódottan kapsz egy: „Jaa…”-t, esetleg bővebben: „jaa, értem, az jó…”-t. Itt általában nincs több kérdés, témaváltás következik.

A projekt menedzsment fogalma nem elég ismert hazánkban vagy, aki ismer olyat, aki már hallott róla, az mind más-más területről. Természetesen iparáganként változó, speciális szempontok és módszertan alapján folyik a munka. Még azonos területen belül is óriási különbségek lehetnek, de egy biztos: A projekt menedzsment könnyű, amíg ki nem próbálod.

Gyakori gondolat: „ezt én is meg tudom csinálni”? Rendben, itt egy tervező, grafikus, két fejlesztő, plusz szakmai vezetők. *Hogyan kezdenéd?*

A feladat egyszerű és unalmas: Biztosítsd, hogy a projekt határidőre elkészüljön, persze a minőség nem kérdés és természetesen úgyis van rá valami kész megoldás, ami tökéletesen illeszkedik az adott projekthez. Készítünk egy tervet, ami úgysem változik, hiszen jól kitaláltuk…  
Figyelmeztetlek: egy biztos van, ez pedig a változás.

![projekt menedzser asztalnál, géppel, notesszal dolgozik – illusztráció](https://blog.fps.hu/content/images/2017/03/projektmenedzser-aszatala.png)

### Miért jó neked mégis a projekt menedzsment?

Egy olyan szakmáról beszélünk, ami legfőképpen a tapasztalatokra épül. Egy tanulmány szerint pl.: a szakemberek pontos intuícióit sokkal jobban magyarázza a nagy tapasztalat, mint a heurisztikák. Más területekre is igaz természetesen, erre kifejezetten.  
Mivel nincs két egyforma projekt, a korábbi best practice-ekből célszerű táplálkozni.

Láthatod, hogy mindenképpen hasznos számodra, hiszen már végigvitt párat, és minden erejével azon van, hogy a résztvevőkből a legjobbat hozza ki. Tehát, egy projektben, ahol több ember összehangolt munkájából születik egy termék, ott bizony szükség van rá, így előnyös ez egy webes projektnél is.

Elvárás, hogy a team tagjai mindig legyenek képben, minden információ időben érkezzen az adott feladat felelőséhez, a minőség nyilván nem kérdés: Nagyon jót akarsz.

Ennek érdekében a PM: tervez, szervez, koordinál, ütemez, tisztáz, egyeztet, tájékoztat, határidőket szab, motivál, összehangol, tartja a kapcsolatot, zsonglőrködik mindennel, amivel csak lehet, ugyanis létezik optimális eset, de csak elméletben. Eközben pengeélen táncol, hogy mindig a megfelelő emberek legyenek összekötve a megfelelő időben és hatékonyan tudjanak együtt dolgozni, mert szeretnéd, ha minden az elképzeléseid szerint haladna.  
Nem 7 emberrel kell kapcsolatot tartanod, hanem eggyel.

### Az elejétől a végéig és utána

A PM a projekt elejétől a végéig szerves része a csapatnak, kiveszi a részét a munkából.  
Már az árajánlat kérés/adás során is jelen van, hiszen a csapata fogja megbecsülni a projekted időtartamát és felmérni azt, hogy az igényed technikalilag is megvalósitható-e, egyeztet a megfelelő szakemberekkel, hogy megtudja mennyi az az idő ráfordítás, amivel elkészülhet a projekt.

Elfogadtad az árat. Ettől kezdve már közvetlenül vele kommunikálsz. Elküldi neked a keretszerződést, hogy átnézethesd, kérdések, észrevételek lehetnek, módosítás, közös nevezőre hozás. Bármilyen észrevétellel keresheted, mindig a megoldáson fog dolgozni.  
Ütemezést készít, amelynek változásairól folyamatosan értesülsz.

Tájékoztatja a tervezőket az igényeidről, szervezi a szükséges találkozókat, megbeszéléseket, ellenőrzi, hogy a kolléga, hogyan halad az adott munka szakaszban meghatározott feladatokkal, és amennyiben valami hátráltatja, vagy információra van szüksége, beszerzi.

A kutatási, tervezési és grafikai feladatoknál abban is segít, hogy minél több információ álljon rendelkezésre, minél előbb véleményezhesd a kreatív munkát (drótvázak, folyamatábrák, grafikai tervek) ne csak a végleges tervekkel szembesülj, amikor már meglehetősen nagy erőfeszítés árán lehet csak változtatni a struktúrán, megjelenésen. Hiszen a felhasználóknak, akiknek készül az oldalad, fontos az első benyomás. Ez is meghatározza, hogy maradnak az oldalon vagy sem, veled szeretnének-e dolgozni, egyáltalán kérnek-e ajánlatot tőled stb.

Eközben persze fennáll az az eset is, amikor nem szolgáltatod a szükséges információt (pl.: tartalom, döntések) és nem lehet haladni a tervek szerint. Ilyenkor ülünk és várjuk, hogy hátha észbe kapsz és küldöd. Hát hogyne! Nem igazán kifizetődő, mi is pénzből élünk. Ekkor ki kell találni, mi az, amit előrébb lehet hozni, mit lehet átütemezni, hogy haladjunk is és ne menjen feleslegesen az idő. Ekkor történik a zsonglőrködés, hogyan töltsük produktívan a várakozás időszakát is.

![zsonglőrködés](https://blog.fps.hu/content/images/2017/03/zsongl-r-1.gif)

A fejlesztés során is folyamatosan felügyeli az előrehaladást, szállítja az információt, ami előrébb viszi a projektet. Amennyiben már van olyan része az oldalnak, amit kipróbálhatsz, megnézhetsz, véleményezhetsz, azt megmutatja neked (miután ő is tesztelte) hogyan tudod használni. Eközben persze lesznek észrevételeid, amelyeket összegyűjt és továbbít az illetékesnek.

Megkaptad a béta verziót. Együtt átnézitek, megtanítja, hogyan használd, módosítsd te magad is a tartalmat, hogy ezzel is megkönnyítsük az életed. A tesztjeid és a belső tesztjeink során összegyűjtött információkat, kérdéseket, észrevételeket szintén össze kell gyűjteni és foglalkozni velük, megoldani a felmerülő problémákat.

Úgy érzed, már a közönségednek is megmutatnád az oldalt. Ekkor a rendszergazdát köti össze a megfelelő személlyel, amennyiben tőlünk független, külsős hosting szolgáltatót alkalmazol, esetleg házon belül van a szervered.

Élesben is megy az oldal, öröm, boldogság! Ekkor még nincs vége, mert a projekt lezárulhat, de egy digitális termék fejlesztése sosem ér véget. A felhasználók és a te további észrevételeiddel is foglalkozik, érdekli elégedettek-e, figyelemmel kíséri eléred-e a kitűzött célokat, amiért az oldalad elkészült.

Végül, de nem utolsó sorban, az oldal készítése során keletkezett tapasztalatokat (pozitív, negatív) a csapattal közösen elemzi, ami nagyon fontos a fejlődés érdekében.

Ez persze 1 projekt, általában több megy párhuzamosan, csúsztatva, ha egy valami módosul, akkor minden másra is hatással van. A változás tehát tényleg állandó, és ehhez folyamatosan alkalmazkodni kell.
### 5 + 1 feladat, ha webes projektbe kezdesz
URL: https://blog.fps.hu/5-1-feladat-ha-webes-projektbe-kezdesz/
Last updated: 2026-07-17T08:29:56.000Z
Kiválasztottad a tökéletes csapatot a weboldalad elkészítésére, profik, értik a dolgukat. Leszerződtetek és innentől hátra is dőlhetsz. Heti egy óra státuszt meghallgatsz róla esetleg, de igazából megy minden magától… Ja nem :)

### 1\. Tartalom, tartalom, tartalom

Egy ilyen jellegű projekt elején a legelső amire fel kell készülöd, hogy foglalkoznod kell a tartalommal, méghozzá sokat. Ha teljesen új oldal megalkotásával bíztál meg egy csapatot a site méreteitől függően, a hírlevél feliratkozásra felhívó szövegtől, az adatvédelmi nyilatkozat utolsó soráig elő kell állítanod az oldalak tartalmát. *Na, de az én projektemben copywriter van* – mondhatnád teljesen jogosan – *majd ő megírja, azért fizetek…* Még egy jó szövegírónak is szüksége van alap tartalmi elemekre (interjúk, cikkek, közlemények, nyers szövegek), ami alapján elkészítheti számodra a weboldalad végleges szövegezését.

Munkaerő igény a megrendelő részéről: \~16–80 munkaóra (projekt jellegétől, méretétől függően)

### 2\. Projektfelelős

![You are the most talented, most interesting, and most extraordinary person in the universe.](https://macs320.files.wordpress.com/2015/10/tumblr_n47dz77v8y1qdojzho1_5001.gif)

Ugye te is szereted a tiszta helyzeteket, mikor egy munkafolyamatban minden résztvevőnek megvan a maga szerepe és felelőssége? Ezért nagyon fontos már a projekt elején meghatározni, hogy ki lesz az, aki a ti oldalatokról felelőse lesz a projektnek. Aki akár a különböző részlegek között keringő információk beszerzésével, átadásával, döntések sürgetésével segíteni tudja mindkét csapat munkáját vagy adott esetben valós felhasználók biztosításával tudja támogatni a felhasználói kutatást.

Munkaerő igény a megrendelő részéről: \~10–30 munkaóra / hét (projekt kezdetétől a lezárásáig)

### 3\. Folyamatos rendelkezésre állás

Az egyik legfontosabb eleme a sikeres webes projektnek, hogy mindkét fél elérhető legyen ha szükséges, méghozzá belátható időn belül. Sajnos sokszor előfordul, hogy kulcsfontosságú kérdésekre hetekig nem érkezik válasz a többszöri figyelmeztetés ellenére sem. A projekt manager feladata ez esetben nyilván a munka olyan jellegű megszervezése, hogy ez az információ hiánya ne akassza meg a csapat működését, de ez az állapot kétségkívül nem ideális és nem is tartható fenn sokáig.

### 4\. A döntéshozás művészete

A projekt több hónapos lefolyása alatt sok olyan pont van, ahol döntési helyzetbe kerülsz majd. Különböző habitusú emberek vagyunk, van aki könnyen–, gyorsan dönt, mások körüljárják és megfontolják a helyzetet. Bármelyik típushoz is tartozol fel kell rá készülnöd, hogy sok eldöntendő kérdés fog záporozni feléd. Érdemes meghatározni a hatásköröket, hogy mik azok a döntési pontok, melyekbe más területen dolgozókat, adott esetben akár a CEO-t is szükséges bevonni.

Munkaerő igény a megrendelő részéről: \~3–8 munkaóra / hét (projekt kezdetétől a lezárásáig)

### 5\. Felkészülni a váratlanra

Minden projektnek megvannak azok a pillanatai amire nem számít senki. Előfordult, hogy az ezer éve használt termékadatok nem voltak valósak és a projekt végén indult a nagy kapkodás. Olyan is történt, hogy előkerülhet egy mindvégig „takarásban lévő” döntő szereplő, aki a teljes oldal struktúráját felborította. Ezekre a helyzetekre lehetetlen felkészülni, de az átvészelésükhöz elengedhetetlen a teljes bizalom a csapat iránt, akit érdemesnek találtál a projekt megvalósítására.

### +1\. Mindezek elmaradásának következményei

![I think I got iz. But just in case… tell me the whole thing again, I wasn't listening.](http://getlevelten.com/sites/default/files/inline-images/onboard_0.gif)

Egy webes projekt során megrendelő oldali munkaerő igényeket összeadva jól láthatóan átlag **10–25 munkaórával** lehet számolni **heti szinten**.

Ez nyilván nem feltétlenül egy embernél halmozódik fel, de mindenképpen szükséges megteremteni rá a kapacitást a projekt sikere érdekében. E nélkül akár több hónapos csúszások, várakozások, idegeskedések mérgezhetik meg az amúgy sikeres együttműködést.

Csak egy ideális világban létezik olyan, hogy tökéletes projekt. Mindkét félnek lehetnek elmaradásai, váratlan akadályok kerülhetnek elő. Véleményem szerint a fenti öt pontra való kapacitásbeli és lelki felkészüléssel, hatalmas segítséget tudsz adni annak a csapatnak, akit megbíztál a weboldalatok megalkotásával. Ha mindehhez kölcsönös partnerség és bizalom is járul, akkor minden adott egy sikeres, szerethető projekthez.
### PHP konstansok
URL: https://blog.fps.hu/php-konstansok/
Last updated: 2026-07-17T08:30:07.000Z
PHP-ben általában a [define()](http://php.net/manual/en/language.constants.syntax.php?ref=blog.fps.hu#example-87) függvénnyel szoktunk konstansokat bevezetni. Az 5.3-as verzió óta azonban lehetőség nyílt a – korábban csak osztályokon belül használható – [const](http://php.net/manual/en/language.constants.syntax.php?ref=blog.fps.hu#example-88) kulcsszó segítségével is megtenni ugyanezt. De vajon tényleg ugyanazt csinálják? És igaz a mítosz, mely szerint a const gyorsabb? Spoiler: nem és igen, de csak egy kicsit. :)

Az ötlet, hogy erről cikket írok, a következő szituációban merült fel. Egy kollégával arról beszélgettünk az irodában, hogy érdemes lenne definiálni egy WordPress sablon textdomainjét, vagy sem. Én vetettem fel az ötletet, tehát szerintem igen. Szebb a kód, nem kell több százszor *belehardcodeolni* ugyanazt a stringet a gettext hívásoknál, ezáltal az elírás lehetősége is csökken. Szerinte viszont a define() lassúsága miatt nem érdemes. Ekkor merült fel a kérdés, hogy vajon a const gyorsabb, és ha igen, mennyivel?

### Mi a különbség?

A legfontosabb különbség, hogy míg **a define() futásidőben definiálja a konstansokat, addig a const fordításkor**. Mindkét megoldás rendelkezik előnyökkel és hátrányokkal egyaránt, és ezeket majdnem minden esetben ide lehet visszavezetni. Hogy mikor, melyiket érdemes használni, az a helyzettől függ. Nézzük sorban!

#### Flexibilitás

A define() engedékeny. Bármilyen kifejezést elfogad névként és értékként egyaránt. Csinálhatsz például ilyet:

```php
for( $i=0; $i<5; $i++ ) {
    define( 'NUMBER_' . $i, $i );
}

```

A const ezzel szemben – mivel nem futásidőben jön létre – kizárólag olyan értéket fogad el, amely már fordításkor tudható, tehát statikus számot, szöveget, egy másik konstans értékét, vagy egy ezekből álló tömböt.

```php
const NUMBER = 1; // Oké
const STRING = 'one'; // Oké
const CONST = NUMBER_1; // Oké
const VARIABLE = $numberOne; // Hiba!

```

Szintén ebből adódik a const azon tulajdonsága is, hogy nem deklarálható elágazásban. Ilyet például nem csinálhatsz:

```php
if( ENV == 'stage' ) {
    const DB_HOST = 'stage.example.com'; // Hiba!
} 

```

Ugyanakkor a define() függvénnyel ezt bármikor megteheted, sőt gyakran meg is tesszük. Például:

```php
if( !defined( 'BASEPATH' ) ) {
    define( 'BASEPATH', dirname( __FILE__ ) );
}

```

A consttal szemben a define() lehet *case insensitive*, tehát deklarálhatsz vele olyan konstanst, amely nem érzékeny a kis- és nagybetűkre.

```php
define( 'NUMBER_ONE', '1', true);
echo NUMBER_ONE; // 1
echo number_one; // 1

```

Kijelenthető tehát, hogy a define sokkal engedékenyebb, ezáltal rugalmasabban használható. Ez a rugalmasság azonban növelheti a kód komplexitását. Mivel a const fordításkor jön létre, nem kaphat futásidőben értéket, ezáltal jóval korlátozottabb.

#### Hatókörök

A define() függvénnyel bevezetett konstansok mindig szuperglobálisként viselkednek, ahogyan alapesetben a const kulcsszóval definiáltak is. Utóbbiak azonban lehetnek nem-globális névtérben vagy tartozhatnak osztályhoz is.

```php
namespace Foo\Bar;

define( 'NUMBER_ONE', 1 ); // Globálisan elérhető.
define( 'FOO\BAR\NUMBER_TWO', 2 ); // Fake névtér :) 

const NUMBER_THREE = 3; // Csak a Foo\Bar névtérben érhető el.

```

Ahogyan fent említettem, a const kulcsszóval osztályokhoz tartozó konstansokat is definiálhatsz. Ezek a statikusokhoz hasonlóan nem az osztály egy példányához, hanem magához az osztályhoz tartoznak. Ebből adódóan elérhetőek példányosítás nélkül is.

```php
class SimpleHttpClient {

    const REQUEST_METHOD_GET  = 1;
    const REQUEST_METHOD_POST = 2;
    const REQUEST_METHOD_PUT  = 3; 

    define( 'REQUEST_METHOD_DELETE', '4' ); // Hiba! 
    
    // ... 
}

echo SimpleHttpClient::REQUEST_METHOD_GET; // -> 1

```

Tehát amikor egy konstanst nem a globális névtérben kell létrehozni, akkor csak a const kulcsszó használható.

#### Teljesítmény

Állítólag a const sokkal gyorsabb a define()-nál. Egy gyors Google kereséssel [ellentmondásos](http://stackoverflow.com/questions/7766486/which-is-faster-constants-variables-or-variable-arrays?ref=blog.fps.hu#answer-7766545) [véleményeket](http://shwup.blogspot.hu/2010/04/about-constants.html?ref=blog.fps.hu) találtam, ráadásul ezek mind évekkel ezelőtt íródtak, ezért utánajártam.

Olyan egyszerű benchmark scripteket írtam (pontosabban generáltam), amelyek tömegesen (10 000+) vezetnek be konstansokat, majd ezekkel végeznek mindenféle műveleteket.

Kiderült, hogy a konstansok létrehozásakor **a const nagyjából kétszer gyorsabb**. Mivel a legtöbb projekt nem csak deklarációkból áll, ennek csak akkor van jelentősége, ha több száz vagy több ezer konstansod van. Ekkor viszont ezredmásodpercekben, akár századmásodpercekben mérhető gyorsulást jelenthet. Azért lássuk be, a valóságban elég ritkán jön szembe 10 000 konstans, így – bár a const valóban gyorsabb – **a különbség elenyésző**.

Amikor a konstansok eléréséről van szó, nem mutatható ki teljesítménybeli különbség.

Érdekesség, hogy konstansok helyett hardcode-olt értékekkel feleannyi idő alatt futottak le ugyanazok a műveletek.

Alternatív megoldásként egyébként létezik egy PHP 5.2–5.6 kiterjesztés [hidef](https://pecl.php.net/package/hidef?ref=blog.fps.hu) néven, amely állítása szerint a define()-nál tízszer gyorsabban működik.

Az APC bővítményből elérhető [apc\_define\_constants](http://php.net/manual/en/function.apc-define-constants.php?ref=blog.fps.hu) is hasonló, de az előbbinél kevésbé hatékony.

### Szóval, mikor mit?

Ha szükséged van a define() rugalmasságára, mert futásidőben kell értéket adnod, használd azt! Például amikor az alap útvonalat kell definiálnod egy WordPress plugin konfigurációjakor.

Minden más esetben használd a const kulcsszót, mert

- Ez nem egy függvény, hanem egy kulcsszó. Jobban olvasható.
- Lehet globális, de nem feltétlenül. Tartozhat akár osztályhoz is.
- Egy kicsit gyorsabb is.
### Írjunk játékot! – three.js
URL: https://blog.fps.hu/irjunk-jatekot-three-js/
Last updated: 2026-07-17T08:30:18.000Z
Régóta foglalkoztat a three.js függvénytár, amivel WebGL alapú 3 dimenziós tartalmat lehet generálni. Egy korábbi [kedvcsináló posztomban bemutattam](https://blog.fps.hu/three-js-3d-a-weben-2/), milyen széles is a felhasználhatósága, de szerettem volna valami konkrét megvalósítási példát is hozni az alkalmazására. Számos ötlet közül első körben egy egyszerűbb játék megvalósítását tűztem ki célul, bízva abban, hogy sikerül szemléltetnem a dolog egyszerűségét.

### Alapkoncepció

![játék](https://blog.fps.hu/content/images/2017/02/threejs_game.png)

Nemrégiben véletlenül ráakadtam a Play Store ajánlatát böngészve a [Star Drives](https://play.google.com/store/apps/details?id=sk.inlogic.stardrives&ref=blog.fps.hu) játékra, aminek az egyszerűsége nagyon megtetszett. Kifejezetten alkalmas is arra, hogy egy low-poly verzió szülessen belőle, amit böngészőben is lehet játszani.

- Kell két egymást keresztező röppálya egy-egy bolygóval
- Egy űrhajó, aminek a sebességét tudjuk a fel-le gombokkal változtatni
- Ellenfelek, amikkel nem szabad összeütköznie
- Egy kör a bolygó körül egy pontot ér
- A cél, hogy minél több kört tudjunk teljesíteni ütközés nélkül.

### Megvalósítás

Akár a nulláról is elkezdhettem volna megírni az egészet, egy keresést mégis megejtettem a githubon és rátaláltam egy egyszerű [boilerplate-re](https://github.com/mwcz/threejs-simple-boilerplate?ref=blog.fps.hu), ami a játék több „képernyős” megvalósítását elősegíti, ha mást nem is. Hozzá kell tenni, hogy a boilerplate megoldása nem teszi lehetővé a [three.js inspector](https://chrome.google.com/webstore/detail/threejs-inspector/dnhjfclbfhcbcdfpjaeacomhbdfjbebi?ref=blog.fps.hu) használatát, így egyszerre tettem szert előnyre és hátrányra, mivel az egyes modellek összerakása eléggé pepecs munka. A következőkben a fontosabb részeket taglalom, némi kóddal, és külön-külön megtekinthető pen-ekkel.

### Modellek

![modellek](https://blog.fps.hu/content/images/2017/02/threejs_models-1.png)

A modellek mindegyike egyszerű geometriákból összerakott test. Egyszerűségük miatt választottam ezt a megoldást és el szerettem volna kerülni a [külső objektumok](https://threejs.org/examples/?q=loader&ref=blog.fps.hu#webgl%5Floader%5Fobj) betöltését.

Az újrafelhasználhatóság miatt egy külön *Models* objektumba tettem őket, ami ugyan lehetne szebb, de felhasználás tekintetében így is tökéletes. Az objektum a következő módon épül fel, elkülönítve külön fájlba:

```javascript
var Models = {
    materials : {
        material1 : new THREE.MeshStandardMaterial( {color: 0xfefefe} ),
        material2 : [ ... ],
        material3 : [ ... ],
    },
    spaceShip : function(){
        var spaceShipModel = new THREE.Group();
        [ ... three.js code ... ]
        return spaceShipModel;
    },
    satelliteOne : function(){
        [ ... ]
    }
}

var spaceShip = Models.spaceShip();
scene.add(spaceShip);

```

A bolygók létrehozásakor már előttem volt a koncepció, mivel régebben ráakadtam [erre](http://codepen.io/tr13ze/pen/vKzmgj?ref=blog.fps.hu) a pen-re. A röppálya kirajzolásával kellett kiegészítenem őket, amit a következő kódrészlet oldott meg:

```javascript
var segment = 100, radius = 30;
var lineGeometry = new THREE.Geometry(),
    vertArray = lineGeometry.vertices,
    angle = 2 * Math.PI / segment;
for (var i = 0; i <= segment; i++) {
  var x = radius * Math.cos(angle * i);
  var y = radius * Math.sin(angle * i);
  vertArray.push(new THREE.Vector3(x, y, 0));
}
lineGeometry.computeLineDistances();

lineMesh = new THREE.Line(lineGeometry, new THREE.LineDashedMaterial({ color: 0x6484b7, dashSize: 1, gapSize: 1 }));

```

Hogyan is néz ki egy „bolygó” köré téve? [Itt tudod megnézni.](http://codepen.io/totya24/full/jyvdZb/?ref=blog.fps.hu).

Az űrhajó kitalálásakor előtérbe helyeztem, hogy alapvetően low-poly modellt szeretnék, semmiképpen sem egy külső betöltött, 3D modellezőben elkészített valamit, így valahogy hitelesebb az egész és amúgyis szimpatizálok a [rajzfilmekben látott](https://www.google.hu/search?q=spaceship&espv=2&biw=1280&bih=934&site=webhp&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjZ6Lf-%5FYDSAhWGhRoKHb8cB80Q%5FAUIBigB#tbm=isch&q=cartoon+spaceship) megvalósítással.

![űrhajó](https://blog.fps.hu/content/images/2017/02/threejs_spaceship.png)

A modell nagyrészének kialakítása viszonylag egyszerűen megoldható volt a three.js „primitív geometriáival” ([CylinderGeometry](https://threejs.org/docs/index.html?ref=blog.fps.hu#Reference/Geometries/CylinderGeometry) és [BoxGeometry](https://threejs.org/docs/index.html?ref=blog.fps.hu#Reference/Geometries/BoxGeometry)). Kisebb csavar akkor jött az elemek összeállítása során, amikor nem szabályos téglatestet kellett létrehozni. Ebben az esetben a mesh létrehozása előtt a drótváz (BoxGeometry) vertex-eit kell manuálisan módosítani, ami abszolút nem bonyolult, és pár soros megoldással a megfelelő alakzattá torzítható a váz. Egy téglatest esetén könnyű dolgunk van, hiszen alapesetben 8 pont határozza meg azt, ami egy 8 elemű tömbnek felel meg. A tömb minden egyes eleme egy-egy vertex, ami x,y,z koordinátákkal rendelkezik, így szabadon módosíthatjuk azokat:

```javascript
var object = new THREE.BoxGeometry( 2, 9, 2 );
object.vertices[4].y -= 1; 
object.vertices[4].x -= .5; 
object.vertices[5].y -= 1;     
object.vertices[5].x -= .5;
object.vertices[6].y -= 1; 
object.vertices[6].x += .5; 
object.vertices[7].x += .5;
object.vertices[7].y -= 1; 
object.needsUpdate = true;

```

A kész űrhajó:

See the Pen [threejs low-poly spaceship](http://codepen.io/totya24/pen/pROYqV/?ref=blog.fps.hu) by Zoltan Toth ([@totya24](http://codepen.io/totya24?ref=blog.fps.hu)) on [CodePen](http://codepen.io/?ref=blog.fps.hu).

A bolygók és az űrhajó mellé még szükség van ellenfelekre is, amik műholdak formájában jelennek meg. A változatosság kedvéért kettőt is csináltam, a lehető legegyszerűbb módon, szintén „primitív objektumok” összerakásával.

### Játéktér – scene

A boilerplate támogatja az egyes játékállapotokat, így könnyen elkülöníthető a kezdőképernyő, maga a játék és a játék vége állapot, ráadásul ezek között gyorsan lehet váltani is.

A kezdő és végállapot részletezését nem tartom fontosnak, igazából minkét esetben egy-egy modell van kiemelve, a végén pedig latod, hány pontot szereztél (azaz hány kört tettél meg) és ha az nagyobb a localStorage-ben eltárolt maximumnál, akkor jelzi hogy rekordot döntöttél.

A játékot megvalósító állapot is alapesetben két részre osztható. Inicializálás és a játéklogikát megvalósító loop. Az inicializálás során a következő történik:

- elhelyezem a bolygókat a röppályákkal
- létrehozok egy „kontrollpontot”, amin az űrhajó áthaladása jelent egy teljesített kört
- a röppályára kezdőpozícióba helyezem az űrhajót
- lenullázom a pontokat és az egyes segéd-számlálókat
- definiálom a tömböt, ami az ellenfeleket tárolja majd

### Objektumok animálása

Az objektumok animálása értelem szerűen már a loop-ba kerül, ami mindaddig tart, amíg nem ütközöl egy ellenféllel, de ezt később részletezem.  
A bolygók esetében egyszerű forgatásokról van szó, és hogy látványos legyen, a bolygó és a körülötte lévő „wireframe shield” eltérő irányba mozog.  
Az űrhajó animálása két részre bontható, egyszer mozog egy körpályán, közben pedig a lángcsóváját is mozgatja.

A körmozgás megvalósítása:

```javascript
this.movement += this.multiplier; // sebesség
this.spaceShip.rotation.z = -1 * (Math.PI / 180 * this.movement) + 0.08; // forgatás
this.spaceShip.position.x = -1 * 350 * Math.cos(Math.PI / 180 * this.movement); // pozíció
this.spaceShip.position.y = 350 * Math.sin(Math.PI / 180 * this.movement) - 100; // pozíció

```

A sebességet a *this.multiplier* változó határozza meg, ami a lenyomott gombtól függően (fel, le, semmi) 0.5, 1 vagy 2 lehet. A sebesség változtatásával oldom meg az egész játék lényegét, azaz, hogy minél tovább elkerüld a műholdakkal történő ütközést. A \* this.movement\* egy segédszámláló, ami egyesével növekszik (360-at túllépve nullázódik, de csak a hibakeresés elősegítése érdekében). Gyakorlatilag ez határozza meg, hogy a körpályán milyen szögben áll az űrhajód és ennek megfelelően pozicionálod. A mozgatás mellett mindig irányba is kell forgatni a hajót, hogy előre nézzen, ezt a második sor oldja meg egy kisebb korrigálással. A pozicionálást végző sorokban az egyes szorzók a körpálya sugarát határozzák meg.

A lángcsóva mozgatása sincs túlbonyolítva. Mivel adott egy (kvázi) 0-360 közötti érték, adja magát a szinusz-hullámú mozgás:

```javascript
var multiply = Math.sin(step*30 * Math.PI / 180) + 1; 
this.spaceShip.children[1].scale.set(this.flameMultiplier,1+(multiply * 0.05),this.flameMultiplier);
this.spaceShip.children[1].position.y = multiply*2.05;

```

A fenti kódban a *step* szintén egy segédváltozó, ami egyesével növekszik, és látszik még, hogy nem az egész *spaceShip* objektumot változtatja, hanem csak egy részét, konkrétan egy 3 elemből álló, lángcsóvát. Mivel a scale alapértelmezetten az objektum közepétől számolva növeli a méretet, szükséges a pozíció korrigálása is, hogy a lángcsóva kiindulópontja fix állapotban maradjon.

### Játékmechanika

Az animáláson túl akad még feladat, hogy a játékból játék legyen. Azt, hogy mikor mivel és mi történjen szintén a loopban határozom meg, a végtelenül egyszerű interaktivitást is belevéve, hogy a felhasználó megnyomta-e a *fel*m, vagy *le* gombot. A loopban történő folyamatokat az alábbi folyamatábra szemlélteti vázlatosan:

![játékmechanika](https://blog.fps.hu/content/images/2017/02/game_diagram-1.png)

Érdemes pár kiegészítést tenni a fenti ábrához, a részletek miatt. Az új műholdak létrehozásának elég egyszerű a logikája. Azért ez a csavar, hogy némi fokozat kerüljön a játékba:

- ha a pontszám 1
- ha a pontszám 13-nál kisebb és oszható 3-mal
- ha a pontszám 12-nél nagyobb és osztható 5-tel

Az ütközések vizsgálata a three.js beépített funkcióink köszönhetően relatíve egyszerű, viszont ha növelni akarom a precizitást, akkor az már pluszmunkát igényel. A three.js kezel egy „speciális” geometriát, ami [Box3](https://threejs.org/docs/api/math/Box3.html?ref=blog.fps.hu) névre hallgat. Ez tulajdonképpen egy két térbeli pont által meghatározott téglatest, ami lehetőséget ad arra, hogy megvizsgáljam, hogy átfedésben van egy másik Box3 típusú téglatesttel avagy nincs. Az ütközés vizsgálata a műholdakat bejárva minden esetben lefut a következő kód szerint:

```javascript
var spaceShipBox = new THREE.Box3().setFromObject(this.spaceShip);
var collosion = spaceShipBox.intersectsBox(new THREE.Box3().setFromObject(this.satellite[index]));
if(collosion){
    game.setState('endgame'); 
}

```

Érdemes megemlíteni, hogy a fenti esetben két elég elnagyolt *bounding box* ütközését hasonlítja össze, ami a játék folyamán olyan helyzeteket teremthet, hogy mi úgy látjuk, nem ütköztünk a műholddal, matematikailag mégis, és vége a játéknak. Ezt úgy lehet pontosítani, ha nem a teljes objektumot veszem alapul a Box3 generálásához, hanem csak például az űrhajó testét, így nem növelem feleslegesen az ütközési holttereket egy esetleges antenna vagy apró objektum miatt, ami térben nem foglal el nagy helyet, mégis drasztikusan megnöveli a befoglaló téglatest (bounding box) területét.

![bounding boxes](https://blog.fps.hu/content/images/2017/02/threejs_boundingbox.png)

### A végeredmény

A cikkhez elkészült játék eléggé kezdeti állapotú, de minden hiányosság és bug ellenére játszható.  
[Ezen a linken próbálhatod ki](https://totya24.github.io/astro-drives/?ref=blog.fps.hu), de ha a kódra vagy kíváncsi, elérhető a projekt [githubon](https://github.com/totya24/astro-drives?ref=blog.fps.hu) is, frissítése hamarosan várható.

Sajnos a játék még nincs mobilra optimalizálva és a kód is erősen refaktorálás után kiált:)

Jó szórakozást hozzá, remélem sikerült hasznos információkat átadnom, esetleg felkeltenem az érdeklődésed a téma iránt. A kommentek között várom a kérdésed vagy észrevételed!
### 5 nektek legjobban tetsző poszt 2016-ból
URL: https://blog.fps.hu/5-nektek-legjobban-tetszo-poszt-2016-bol/
Last updated: 2026-07-17T08:30:30.000Z
Elképesztő, hogy milyen sokan jártatok az fps blogon, mennyire sokan olvastátok az írásainkat, amiért nagyon hálásak vagyunk, amit nagyon köszönünk nektek. Gyorsan összegeztük analitika és social megosztások alapján, hogy mely posztok tetszettek nektek leginkább ebben az évben. Íme a TOP5-ös lista. Ha valamelyik írást elmulasztottad, akkor itt a lehetőség, hogy bepótold!

### TOP5 nektek legjobban tetsző poszt 2016-ból

1. [Mennyi az annyi?](https://blog.fps.hu/mennyi-az-annyi/)
2. [Magyar (mobil)web sebesség](https://blog.fps.hu/magyar-mobil-web-sebesseg-ssl/)
3. [CSS – fps módra](https://blog.fps.hu/stiluslapok-fps-modra/)
4. [Hagyjuk már](https://blog.fps.hu/ertheto-kommunikacio-beszelj-vilagosan/)
5. [WordPress?](https://blog.fps.hu/wordpress/)

Köszönjük, hogy velünk voltatok idén is, 2017-ben folytatjuk.  
**Írjatok, kommenteljetek, osszátok!**
### Free Paper Christmas Figures
URL: https://blog.fps.hu/free-paper-christmas-figures/
Last updated: 2026-07-17T08:30:39.000Z
Our present for the world! Free paper figures for Christmas. Angel, Santa Claus and a Xmas tree. Free for personal and commercial use as well.

1. Download the pack
2. Print out the PDF files (A4 size)
3. Cut them out with scissors
4. Stick the parts
5. Put them on your table or hang them on your Christmas tree.
6. Be happy

Here are the instructions how to prepare it:

![DIY – Do it yourself – free paper xmas figures](https://blog.fps.hu/content/images/2016/12/free-paper-christmas-figures-do-it-yourself.png)

[Download for free (0 downloads)](https://www.fps.hu/presentations/free-paper-christmas-figures-fps.zip?ref=blog.fps.hu "Download Free Paper Christmas Figures") 

**Citations are appreciated and appropriate.**  
It is allowed to share with your friends and others if you like it! ;)

Merry Xmas!
### Telefon helyzetének milliméter pontosságú meghatározása valós időben
URL: https://blog.fps.hu/telefon-helyzetenek-millimeter-pontossagu-meghatarozasa-valos-idoben/
Last updated: 2026-07-17T08:30:48.000Z
A címben megfogalmazott igény számtalanszor felmerült már a felhasználók és a fejlesztők részéről is. Olyan cél ez, amit idővel mindenképpen el kell érnünk, hiszen több területen is hasznos lenne. Jól sejted kedves olvasó, a jelenlegi eszközeinkkel egyelőre nem megoldott a probléma, így e poszt témája valójában a miértek boncolgatása technológiai oldalról. Miért is lehet hasznos számodra egy „hogyan ne”, vagy egy „miért nem” jellegű írás?

Felhasználóként azért lehet érdekes számodra, hogy milyen jellegű appok keresésével ne töltsd a drága szabadidőd.  
Megrendelőként jó, ha tisztában vagy a technológiai korlátokkal, hiszen félinformációkból könnyű hibás következtetéseket levonni és rossz irányba indulni egy alkalmazás tervezésénél. A témánkban felvetett probléma alapkoncepciókat képes romba dönteni, esetedben pedig már nem csak a szabadidőd a tét. Fejlesztőként sem érthetsz minden területhez, így az ilyen nem magától értetődő problémák bizony megfoghatnak téged is. Esetedben pedig nem csak az idő és a pénz a tét, hanem a szakmai jóhíred is, hiszen egy jó fejlesztő mindenhez ért (persze nem ¯\\*(ツ)*/¯).

Többször illettek már azzal a kritikával, hogy csak az aktuális ötletre tudok ellenérveket mondani, hogy miért nem működhet, de valódi megoldási javaslatot nem adok a probléma megoldására. Esetünkben megpróbálok alternatív, kevésbé pontos, de használható megoldásokat adni, ezek azonban felhasználási terület és erőforrás függő megoldások.

## Felhasználói igények

Felhasználóktól olvastam és személyesen is hallottam már az igényt, hogy szeretnék a telefonjukat távolságmérésre használni. Természetesen nem az esti futásukra gondoltak, hiszen arra számtalan appot ismer mindenki, hanem mondjuk egy szoba hosszának lemérésére, ahova centiméteres, de inkább milliméteres pontosságra lenne szükség, illetve működnie kellene az égre való rálátás nélkül. Hasonló probléma mondjuk az épületen belül történő navigáció, amire ugyancsak egyre nagyobb igény lenne.

## A GPS korlátai

Az első dolog, ami mindenkinek az eszébe jut a GPS, ami tökéletesen jó kültéri navigációra, a telefonok esetén 3–10m körüli pontosságával. A [Federal Aviation Administration saját adatai](http://www.gps.gov/systems/gps/performance/accuracy/?ref=blog.fps.hu) alapján a komolyabb eszközök 3,5 méternél nagyobb pontosságot biztosítanak, de mértek már 1 méter alatti pontosságot is. Természetesen a telefonokban használt chipek és antennák nem képesek erre a pontosságra még ideális körülmények között sem. Bár így a számok alapján nem tűnik nagynak a telefonok hátránya, ezeket az értékeket egy bizonyos valószínűség mellett adják meg, ami az FAA esetén 95%. Tehát a valós pozíció 95%-os bizonyossággal a mért pozíciótól számított kb. 3,5m-es sugarú körön belül található. Androidos készülékeknél az SDK-tól kapott pontosság érték esetén ez csak [68%](https://developer.android.com/reference/android/location/Location.html?ref=blog.fps.hu#getAccuracy%28%29).

Fix telepítésű földi GPS vevők adataival korrigálva (DGPS – Differential GPS) a GPS rendszer hibáit, a pontosság elérheti akár a 10cm-t is. Mint látod ez a pontosság még messze nem alkalmas arra, hogy a telefonnal helyettesítsd a mérőszalagot, ráadásul épületen belül eleve használhatatlan.

## A gyorsulásmérő

A legtöbb telefonban ma már van egy halom érzékelő, melyeknek az adatait jobbnál jobb dolgokra tudjuk felhasználni. Ilyenek a gyorsulásmérő, a giroszkóp, a mágnesesség érzékelő, nyomásmérő stb. Egyes telefonokban némelyik hiányzik, ilyenkor több más szenzor adataiból származtatva helyettesítik. A gyorsulásmérő azonban minden modern okostelefonban helyet kapott. Fizika óráról még biztos sokaknak rémlik, hogy gyorsulásból és eltelt időből lehet számolni sebességet, sebességből és eltelt időből megtett utat, megtett útból és kezdő pozícióból pedig aktuális pozíciót. Ez elméletben jól hangzik ugyan, de a gyakorlatban ehhez elképesztően pontos mérésre van szükség. A felvezetőből gondolom már sejthető, hogy a telefonokban található gyorsulásmérő ehhez pontatlan.

### Matematikai háttér

Ha a gyorsulásmérő adataiból (tételezzük fel, hogy elég pontos hozzá) szeretnél aktuális pozíciót számítani, akkor a következőket kell tudnod:

Elmozdulást mindig valamilyen más viszonyítási ponthoz képest értelmezünk. Szükség van egy vonatkoztatási rendszerre, amely esetünkben a jól ismert Descartes-féle derékszögű koordinátarendszer. Egy pont helyzetét a koordinátarendszerben egy vektorral (helyvektor) jellemezzük.

Az elmozdulásvektort két időpillanat között a pont helyvektorának változása adja, ami a gyakorlatban a két vektor különbsége.

A sebességet a helyvektor változási gyorsasága, tehát annak időszerinti deriváltja adja.

A gyorsulást a sebességvektor változási gyorsasága, tehát annak időszerinti deriváltja adja.

Mivel a gyorsulásvektorból szeretnénk kiindulni (hiszen ezt kapjuk meg a szenzortól), ezért a sebesség-idő függvényt a gyorsulás-idő függvényből integrálással kapjuk.

![képlet:sebesség számítása gyorsulásból integrálással](https://blog.fps.hu/content/images/2016/12/v-from-a--unstretch.png)

A hely-idő függvényt a sebesség-idő függvényből integrálással kapjuk.

![képlet:elmozdulás számítása sebességből integrálással](https://blog.fps.hu/content/images/2016/12/r-from-v--unstretch.png)

Mivel diszkrét értékekkel dolgozunk, ilyenkor használható valamilyen numerikus integrálási formula. Ilyen esetben én a trapezoid módszert ajánlom.

A sebességvektor x komponense a t1 időpillanatban a következő:

![képlet:sebesség x komponensének számítása numerikus integrálással](https://blog.fps.hu/content/images/2016/12/vx-from-ax-num--unstretch-1.png)

A többi komponenst ugyan így számítjuk.

Jól látható a képlet alapján, hogy az aktuális sebesség vektor nem csak a gyorsulás vektoroktól, hanem az előző időállapotban számított sebességtől is függ. Ez a gyakorlatban azt jelenti, hogy ha a számításokba hiba csúszik, az onnantól halmozódva jelen lesz a teljes mérés során.

A sebességvektorból történő elmozdulás számítást hasonló módon végezzük, elég csak a fenti képletbe behelyettesíteni a gyorsulás helyére a sebességet, a sebesség helyére pedig az elmozdulást. A számítási és mérési hibák halmozódása természetesen ebben az esetben is igaz.

### Milyen mérési hibák jelentkezhetnek?

#### Méréshatár

Készülékenként eltérő a gyorsulásérzékelő méréshatára. Általánosságban ±2g és ±8g méréshatárok között szokott előfordulni, ami kb. ±19 és ±78 m/s^2\. Ha kevesebb gyorsulást mérünk, mert elértük a készülék határait, akkor kevesebb lesz a sebesség is amit mérünk, ami az előzőek ismeretében nyilvánvalóan komoly problémát jelent.

#### Zaj

Minden mérésnél találkozunk valamilyen szintű alapzajjal. A készülékemen, amin teszteltem a szenzort, mindhárom tengelyen ±0.2 m/s^2 között változik a mért gyorsulás, miközben a telefon az asztalon pihen. Mivel egymásra épülő számításokról van szó, a mintavételi frekvenciának megfelelő ütemben minden mérésnél halmozódik ez a hiba.

#### Mintavétel gyakorisága

Ilyen mérésnél az elérhető legnagyobb frekvenciával kell mintavételezni. Az én készülékemen ez 100 Hz, vagyis másodpercenként 100 mintavétel. Soknak hangzik ugye? A gyakorlatban ez rendkívül kevés, ha sebességet szeretnénk számolni belőle, majd abból pozíciót. Gondolj csak bele, ha a mozgás gyorsító fázisát elkapja a mintavétel, de a lassítás olyan gyorsan történik, hogy két mintavétel közé esik és már az utána beálló nyugalmi állapotot mérjük. Ebben az esetben azt érzékeljük, hogy az eszköz felgyorsult X sebességre, majd mivel nem volt lassulási fázis, X sebességgel halad tovább. Láthatjuk, hogy ez komoly probléma.

#### Mintavételi idő pontossága

Ez nagyjából magától értetődő, hiszen ha pontatlan a két mérés között eltelt idő, akkor egy újabb halmozódó hiba kerül a számításba.

### Gyorsulásmérő valós felhasználása

Felmerülhet a kérdés, hogy ha ennyire pontatlan a szenzor, akkor mégis mire használható?  
Ehhez tudnod kell, hogy Androidos készülékeken a gyorsulásmérő adatait többféle képpen is le lehet kérni. Rendelkezésre áll a nyers adat, amiben jelen van a mozgás okozta gyorsulás, valamint a gravitáció okozta fix gyorsulás. Lehetőség van lekérni a gravitációs gyorsulás kivonásával kapott, csak a mozgás okozta gyorsulás vektort, illetve külön csak a gravitációs gyorsulás vektorát. Valós felhasználásnál legtöbbször ez utóbbinak vesszük a legnagyobb hasznát, főleg a magnetométerrel kombinálva, hiszen ebből kiszámítható a készülék orientációja. Általában így szokták helyettesíteni a giroszkópot, amennyiben azt kispórolják a készülékből.

Csak a gravitáció okozta komponenst visszaadó szenzor lekérdezése Androidon:

```java

private SensorManager mSensorManager;
private Sensor mSensor;
mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
mSensor = mSensorManager.getDefaultSensor(Sensor. TYPE_GRAVITY);

```

A mozgás okozta komponens is használható, például lépésszámlálók fejlesztésénél, hiszen ilyenkor elégséges a mozdulat iránya, az elmozdulás nagyságát többnyire előre megadott adatok alapján (tesmagasság, nem stb.) a lépésszámból számítják.

Az Androidnak van származtatott szenzora a lépés érzékelésére, így nem kell annak implementálásával foglalkozni.

```java
mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_STEP_DETECTOR);
```

Látható tehát, hogy kompromisszumokkal használható távolságmérésre, csak nem egészen olyan léptékben és pontossággal, ahogy mi szeretnénk.

Csak a mozgás okozta komponenst visszaadó szenzor lekérdezése androidon:

```java
mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_LINEAR_ACCELERATION);
```

Szokás még a gyorsulásmérőt mozgás alapú vezérlésre is használni. Egyes készülékeken beállítható, hogy elhallgasson a csörgés, ha átfodítjuk a készüléket, vagy nem nyílik a képernyőzár, ha úgy érzékeli a telefon, hogy zsebben van és mozgásban vagyunk.

## Navigáció épületen belül

![Kép: Mobil navigáció wifi elérési pontok segítségével](https://blog.fps.hu/content/images/2016/12/Accesspoint-mobile-position--unstretch.jpg)  
*Forrás: www.cisco.com*

Említettem, hogy egyre nagyobb igény mutatkozik az épületen belüli navigációra, amire a GPS és a gyorsulásmérő szenzor is alkalmatlan. Ennek ellenére nem teljesen veszett ügy. Használható erre a célra a WiFi access pointok jelerőssége, amennyiben tudjuk azok pontos helyzetét, van elég számú access point, valamint kiküszöböljük a falak, illetve a padló és a plafon okozta veszteséget.

Így gondolják ezt az Apple szakemberei is, hiszen aktívan [foglalkoznak a témával](http://appleinsider.com/articles/14/04/15/apple-tech-uses-wi-fi-access-points-for-indoor-navigation-3d-positioning?ref=blog.fps.hu).  
Több szenzor együttes használatával (mondjuk lépésszámláló és orientáció), illetve az épület alaprajzával (nyilván nem közlekedik falakon keresztül az ember) pontosítható a kapott pozíció. Természetesen ez a megoldás is távol áll a milliméteres pontosságtól, továbbra sem alkalmas valódi mérésre, de egy több emeletes több száz négyzetméteres kórházban, vagy plázában történő navigálásra már elégséges lehet.

## Telefon elmozdulásának viszonylag pontos meghatározása

Ez sem lehetetlen feladat, de mint az előzőekben, itt is kompromisszumokra kényszerülünk. A telefon kamerájának képét is felhasználhatjuk néhány referencia pont, vagy ábra segítségével, az orientáció érzékelővel kiegészítve. A módszert többnyire kiterjesztett valóság applikációk fejlesztésénél használják, ahol a kamera képre két- és háromdimenziós elemeket helyeznek. Erre használja a jól ismert [LEGO](https://play.google.com/store/apps/details?id=com.lego.catalogue.global&ref=blog.fps.hu) is.

Akkor lehet még hasznos a módszer, ha a telefont VR headsetként szeretnénk használni és nem csak a forgást szeretnénk érzékeltetni, hanem az elmozdulást is. Hátránya, hogy a kamerakép feldolgozása erőforrás igényes, ami az amúgy is korlátozott képességű készülékeken erősen behatárolja a megjelenített tartalom részletességét, hiszen ennek számítására kevesebb kapacitás marad.
### Hogyan segítsd a fejlesztőt 2.
URL: https://blog.fps.hu/hogyan-segitsd-a-fejlesztot-2/
Last updated: 2026-07-17T08:30:58.000Z
Egy grafikus gondolatai a leadott grafikákról *2\. rész*

> …ha ilyen nyűg ez Photoshop, akkor mi van helyette?

**Semmi. Marad a Photoshop.** Ezt csak azért mondom, mert a cím még mindig az, *Hogyan segítsd a fejlesztőt*. Ahhoz, hogy bevezess egy új célszoftvert, amiből majd a builder felépíti a webes, mobilos felületet, a fejlesztői oldal edukálása is szükséges. Az nagyon örvendetes, hogy te elkezdesz használni egy új eszközt, ami megkönnyíti mindennapjaidat, de ezt a játékot még mindig csapatban játsszuk.

> Összevonhatod a kettőt, de még nem nagyon láttunk olyat, aki magas szinten ért a graphic designhoz és a sitebuildhez is. Valójában ez két szakma: graphic designer és frontendes.

Hangzott a válasz a korábbi poszt végén [Gully](https://disqus.com/home/discussion/fps-blog/hogyan%5Fsegitsuk%5Fegymast%5Fegy%5Fgrafikus%5Fgondolatai%5Fa%5Fleadott%5Fgrafikakrol%5F1%5Fresz/?ref=blog.fps.hu#comment-3006761168) kérdésére, hogy van-e még olyan grafikus, aki nem készít sitebuildet. [Ez hát a könnyek oka!](http://dictzone.com/latin-magyar-szotar/hinc%20illae%20lacrimae?ref=blog.fps.hu) Ki és mire használja? Másra a grafikus és másra a fejlesztő. Alapvetően 5 féle felhasználási módot lehet megkülönböztetni az alkalmazott webes grafikában:

- **UI tervezés** *(Felhasználói felület tervezése)*
- **Grafikai tervezés**
- **Ikon tervezés**
- Képszerkesztés
- Digitális festészet
- +1 a betűtípus tervezés *– de az már egy másik szakma*

Ami számunkra most érdekes – mert a fejlesztő is érintett benne –, az az első három pont.  
Nézzük mik azok az általam ismert programok amik le–, kiválthatják a Photoshopot?

![](https://blog.fps.hu/content/images/2016/11/sketch.png)

### [Sketch](https://www.sketchapp.com/?ref=blog.fps.hu)

[**Ára:**](%28https://www.sketchapp.com/%29) **\~40 000 Ft** egyszeri alkalommal

Mit is mondhatnék? A felülettervezés meghatározó szereplőjévé nőtte ki magát az elmúlt években, és egy nagyszerű alternatíva, **ha Macen dolgozol.** PC-re nem is lesz, mert [speciálisan OS X alapokra építették](https://www.sketchapp.com/support/faq/?ref=blog.fps.hu), habár akkor jó lenne, ha nem lenne bugos, de mik ezek a problémák egy Photoshop összeomláshoz képest?!

A Sketch mostanában verhetetlen a felülettervezésben. Drótvázból könnyen lesz grafikai felület, mindez egy könnyen kezelhető és átlátható felületen, és ha megtanultad az apró trükköket: igazán gyorsan. Egyszerűen [tényleg arra tervezték,](https://www.sketchapp.com/features/?ref=blog.fps.hu) hogy megkönnyítse a mobilra– és webre tervezők életét. Vektoros grafikák és ikonok készítésére is kiválóan alkalmas, de ahogy [ebben az összefoglalóban](http://blog.iconfinder.com/sketch-review-2016/?ref=blog.fps.hu) is olvasható, nem ez az erőssége ennek az appnak.

Ha pedig a Sketch mellé még a [Zeplint](https://zeplin.io/?ref=blog.fps.hu) is használjátok a fejlesztőkkel, akkor lényegesen könnyebb lesz az életetek.

![](https://blog.fps.hu/content/images/2016/11/illustrator.png)

### [Illustrator](http://www.adobe.com/hu/products/illustrator.html?ref=blog.fps.hu#x)

[**Ára:**](https://creative.adobe.com/plans?single%5Fapp=illustrator&promoid=7WQ465TD&mv=other&store%5Fcode=hu&ref=blog.fps.hu) **6 500 Ft/hónap** licencenként

**Illustrator?!** Bármilyen furcsa az Illustrator is egy tökéletes program lehetne. Stílusok, színek, szimbólumok gyors módosítása. Felülettervezésben az artboardok már óriási segítséget nyújtanak, és a csoportos .svg exportálás nélkül nem is tudom, hogy tudtam eddig létezni?!

A vektoros grafikák és [ikonok készítésének](http://blog.iconfinder.com/adobe-illustrator-review-icon-design-2016/?ref=blog.fps.hu) terén 20 év tapasztalattal a háta mögött nem kell túl sokat beszélni róla. A probléma vele, hogy a fejlesztői oldalon kevesen használják olyan magabiztosan, mint a Photoshopot, így bármilyen egyszerű is vele a módosításokat elvégezni, a .psd-ébe kimentett formátumban sajnos elvesznek azok a beállítások, amik a lelkét adták a fájlnak.

![](https://blog.fps.hu/content/images/2016/11/affinity-designer.png)

### [Affinity Designer](https://affinity.serif.com/en-us/designer/?ref=blog.fps.hu)

**Ára:** **\~12–15 000 Ft** egyszeri alkalommal

Októberben élesedett a 1.5-ös verziója Windowsra is. Ha eddig aktív felhasználója voltál a Photoshop és Illustrator kombónak, akkor ezt épp neked találták ki. Számos billentyűkombinációt vettek át, hihetetlenül gyors, egyszerre tudsz benne [vektoros](http://blog.iconfinder.com/affinity-designer-1-5-beta-review/?ref=blog.fps.hu) és raszteres dolgokat szerkeszteni, és az artboardjai intelligensen, reszponzívan kezelik az előre és jól beállított szimbólumokat, elemeket.

Meg kell szokni a használatát, de ez egy gyors folyamat lesz, és ha a fejlesztőkkel együtt elköteleződtök a program használata mellett, akkor nem pluginokkal kell majd asseteket mentegetni. Ezen felül még az átállási szakaszt is megkönnyíti, hogy ha minden kötél szakad .psd-ébe is tudsz exportálni belőle. Hmmm, sokat lehetne róla áradozni, de ha még nem ismerted, az árát tekintve is megér egy próbát.

![](https://blog.fps.hu/content/images/2016/11/avocode.png)

### [Avocode](https://avocode.com/?ref=blog.fps.hu)

[**Ára:**](https://avocode.com/pricing.html?ref=blog.fps.hu) **3 300Ft/hó** felhasználónként

Igazából ez egy kakukktojás, mert nem tudsz benne grafikát készíteni. Ez inkább a korábban említett Zeplin alternatívája, de mivel volt hozzá szerencsénk, beraktam az összefoglalóba. Ahogy a szlogen mondja, ez egy közös felülete a grafikusoknak és a fejlesztőknek.

A program célja, hogy feltöltöd a .psd-ét, majd az átkonvertálja egy olyan formátumba amiből könnyen ki tudja nyerni a builder. Távolságok, eltartások, színek, betűtípus, mindezt akár már CSS-ként is. Plusz előnye, hogy kezeli a smart objecteket, és akár különböző méretben is ki lehet menteni belőle .svg-ként az elemeket.

Sajnos a desktop program kicsit lassú, ha bonyolultabb Photoshop fájlt kell megnyitni vele, és olykor el is hasal a program. Viszont van benne verziókövetés, és külső linket is lehet küldeni a feltöltött fáljról, ahol lehet kommentálni az esetleges változtatásokat, észrevételeket. Összességében egy remek kiegészítő, de a gyermekbetegségei egy profi frontendest inkább csak zavarni fognak.

### +1 [Subform](https://subformapp.com/?ref=blog.fps.hu)

Nagyon szép dolgokat lehet írni és még meggyőzőbb videókat készíteni. Ám, ha csak a töredéke is valóra válik azokból a dolgokból, amiket [ez az app ígér](https://medium.com/subform/hey-ui-ux-designers-stop-pushing-pixels-892b972ebfa6?ref=blog.fps.hu#.hscfe4y90), akkor van remény, hogy végre lesz egy olyan eszköz a grafikusok kezében is, amivel élmény lesz dolgozni mindkét oldalnak.

### Grafikai konvenciók

És hogy miért beszéltem eddig feltételes módban a váltásról? Azért mert hiszek benne, hogy nem a szoftvertől lesz kevesebb a súrlódás közted és a builder között. Minden projekt elején le kell ülni, és lefektetni azokat a direktívákat, amik mentén készülnek majd a tervek. **Íme egy kérdéscsokor**, amiket ha az elején meghatároztok, akár Photoshopban is dolgozhattok az idők végezetéig, csak tartsátok magatokat a vállaltakhoz. Ne feledd, a grafikával nincs vége a munkának!

- Miről készül grafika?
- Milyen grafikai célszoftverben készül a grafika?
- Milyen formátumban történnek a fájlok átadásai?
- Egységes méretezés, segédvonalak, gridek. Állapodjatok meg benne!
- Milyen ikonokat használunk, és azokat hogyan adjuk át?
- Milyen egységes elnevezéseket használunk?
- Hogyan épül fel egy leadott fájl strukturális és elnevezés szinten?
- Milyen leadási paraméterek vannak?
- Milyen ütemben történik az átadás?
- Milyen formában és kitől jönnek a módosítási kérelmek?
- Ezeket mikor és hogyan vezetjük át?
- Mikor lesz elfogadott egy leadott grafika?
- Az utánkövetés hogyan történik?
- A már meglévő styleguide-hoz való igazodás, hogyan fog történni?
- Egyedi elemek hogyan kerülnek átvezetésre?
- Mik lesznek a belső és külső határidők?

*Ha van véleményed, javaslatod, akkor mondd el, ha pedig kimaradt valami, vagy máshogy gondolod, oszd meg velünk, hogy tanulhassunk belőle!*
### Three.js – 3D a weben
URL: https://blog.fps.hu/three-js-3d-a-weben-2/
Last updated: 2026-07-17T08:31:10.000Z
A [Magyarországi Webkonferencián](https://webconf.hu/?ref=blog.fps.hu) tartottam egy előadást a WebGL-ről, three.js-ről és felhasználási lehetőségeiről. Úgy gondoltam, blogposzt formájában is összeszedem az ott elhangzottakat, remélve, hogy sikerül felkeltenem az érdeklődésed a téma iránt.

### A VRML-től a WebGL-ig

Az, hogy a weboldalak komplett 3 dimenziós tartalmat tudjanak megjeleníteni, már a kilencvenes évek közepén felmerült igényként. A probléma megoldására hozták létre a [VRML](https://en.wikipedia.org/wiki/VRML?ref=blog.fps.hu) leíró nyelvet, amihez még külön böngészőkiegészítő kellett az IE és Netscape böngészők mellé, ráadásul eléggé korlátozottak voltak a lehetőségek. A VRML leíró nyelvet később [továbbfejlesztették](http://gun.teipir.gr/VRML-amgem/spec/index.html?ref=blog.fps.hu), majd utódjaként megjelent 2004-ben az [X3D](https://en.wikipedia.org/wiki/X3D?ref=blog.fps.hu), ami a mai napig használatban van, viszont kevésbé elterjedt. Az igazi áttörést a [WebGL API](https://www.khronos.org/webgl/?ref=blog.fps.hu) megjelenése hozta, ami már natív böngészőtámogatást kapott, így nem igényel külön plugin telepítést, továbbá a CPU mellett aktívan használja a GPU-t is.

### Three.js

A WebGL mára minden modern böngészőben [elérhető](http://caniuse.com/?ref=blog.fps.hu#feat=webgl), viszont ha valaki laikusként vág bele a témába, az [első nekifutás](http://webglfundamentals.org/webgl/lessons/webgl-how-it-works.html?ref=blog.fps.hu) könnyen elbizonytalaníthatja a további próbálkozásoktól. Az API teljes körűen eléri az OpenGL funkciókat, viszont ez azzal is jár, hogy egy egyszerű kocka rendereléséhez is több mint [200 sornyi](https://developer.mozilla.org/en-US/docs/Web/API/WebGL%5FAPI/Tutorial/Creating%5F3D%5Fobjects%5Fusing%5FWebGL?ref=blog.fps.hu) kódot kell írni shaderek, bufferek, mátrixok használatával. Többek között a WebGL API használatának megkönnyítése érdekében kezdték el fejleszteni 2010-ben a [three.js](https://threejs.org/?ref=blog.fps.hu) frameworköt, ami ma már a 82\. stabil kiadásánál tart és az egyik leginkább elterjedt függvénytár lett a témában.

> The aim of the project is to create a lightweight 3D library with a very low level of complexity — in other words, for dummies.

A framework közel 500k-s méretével nem tekinthető elhanyagolható adatmennyiségnek, de rendkívül leegyszerűsíti a 3D-s tartalmak generálását és megjelenítését, mindezt megspékelve különböző [renderelő motorokkal](https://threejs.org/docs/?q=ren&ref=blog.fps.hu#Reference/Renderers/CanvasRenderer), így ha véletlenül nem lenne WebGL támogatás, még mindig vissza lehet nyúlni a 2D-s canvas adta lehetőségekhez és nem kell a "Your browser not supported WebGL API" hibaüzenettel beérni. Egy egyszerű kocka mindössze 30 beszédes kódsorból összeállítható, ahogy azt az alább linkelt *pen* szemlélteti.

See the Pen [three.js cube example](http://codepen.io/totya24/pen/oYwWNL/) by Zoltan Toth ([@totya24](http://codepen.io/totya24)) on [CodePen](http://codepen.io). \### Felhasználási területek Mivel az egész technológia Canvas alapú, gyakorlatilag a weboldal bármely részébe könnyen integrálható, akár vegyítve egyéb HTML tartalmakkal. Ebből kifolyólag \[sok helyen\](https://onepagelove.com/tag/three-js) használják a \*\*háttér dinamikus generálásához\*\*. Ezek a megoldások nem túl erőforrás-igényesek, viszont annál látványosabbak és könnyen interaktívvá tehetőek, így a hatás garantált. 

Kiváló megoldás továbbá a régebben használt flash alapú **3D-s termékmegjelenítők** helyett, vagy a kifejezetten 3D-s modelleket bemutató oldalak számára is, mivel a three.js beépített object-loaderrel rendelkezik, így bármilyen 3D szerkesztőből (blender, 3DS MAX, Maya, Sketch Up stb.) exportált modelleket kezelni tudja. Ezt a tulajdonságát használja ki a [Thingsverse](http://www.thingiverse.com/?ref=blog.fps.hu) vagy a [Unity Asset Store](https://www.assetstore.unity3d.com/?ref=blog.fps.hu).

**Adatvizualizáció** során is remekül hat, ha térben jelenítjük meg a prezentálni kívánt adatainkat. Ha belegondolsz, pár sornyi kóddal létrehozható egy térbeli oszlopdiagram, ami interaktív, forgatható, dinamikusan változtatható, a [földgömb](http://makc.github.io/three.js/map2globe/demo.html?ref=blog.fps.hu) felhasználásáról már nem is beszélve.

See the Pen [Chill the lion](http://codepen.io/Yakudoo/pen/YXxmYR/) by Karim Maaloul ([@Yakudoo](http://codepen.io/Yakudoo)) on [CodePen](http://codepen.io). 

Noha a keretrendszert nem kifejezetten játékok fejlesztésére szánták (hiányzik belőle a beépített fizika, ütközéskezelés stb.), mégis leginkább **minijátékok** megvalósítása esetén lehet belefutni a használatába. Az ilyen [fun-projektek](http://codepen.io/Yakudoo/full/YGxYZj/?ref=blog.fps.hu) kigondolása kreativitást igényel, a fejlesztése során sokat lehet tanulni és az eredmény is szórakoztató. A low-poly megoldások kedvelőinek (jelen!) pedig külön kihívás és élmény, hogy a beépített objektumtípusokból összehozzon egy-egy valahogy kinéző mókás karaktert:) A témában [remek cikkek](http://tympanus.net/codrops/2016/04/26/the-aviator-animating-basic-3d-scene-threejs/?ref=blog.fps.hu) születtek, amik jó kiindululópontok az ez iránt érdeklődőknek.

### Experiments

A WebGL és three.js lehetőségei nem merülnek ki az „egyszerű” 3D-s terek renderelésében. Látványos megoldásokat találhatsz a [Chrome Experiments](https://www.chromeexperiments.com/webgl?ref=blog.fps.hu) gyűjteményben, ahol WebGL címkére keresve gyakorlatilag minden második „kísérlet” three.js libet használ. A Google hozzáállását a projekthez mi sem szemlélteti jobban, minthogy a [VR példakódja](https://vr.chromeexperiments.com/?ref=blog.fps.hu) is a szóban forgó keretrendszeren alapul. De a neten böngészve is számos [gyűjteményre](http://tutorialzine.com/2013/09/20-impressive-examples-for-learning-webgl-with-three-js/?ref=blog.fps.hu) bukkanhatsz, a [CodePen-t](http://codepen.io/search/pens?q=threejs&limit=all&type=type-pens&ref=blog.fps.hu) külön kiemelve.

### Amiről érdemes szót ejteni

A 3D renderelés egy sima weboldalhoz képest jelentősen több erőforrást igényel, kőkemény számítások és folyamatos munka a processzoroknak. Ha nem figyelsz oda, könnyen odajuthatsz, hogy leterheled a kliens számítógépét, ami pl. Chrome esetén a kellemetlen sárga értesítőt eredményezheti.

![Google Chrome WebGL crash](https://blog.fps.hu/content/images/2016/11/crash.jpg)

Ez persze nem törvényszerű és kis utánajárással lehet [megoldásokat](http://stackoverflow.com/questions/36416767/optimizing-three-js-text-performance-merge-geometries-shaders-etc?ref=blog.fps.hu) találni az optimalizálási lehetőségekre.  
Fontos megjegyezni, hogy nem a three.js az egyetlen WebGL API-ra épülő framework, komplett [JavaScript játékmotorok](https://html5gameengine.com/tag/webgl?ref=blog.fps.hu) léteznek a technológiát kihasználva és sokuk több lehetőséget kínál, mint a three.js. Azonban a three.js esetében van lehetőség bővítésre. Erre a célra hozták létre a [THREEx](http://www.threejsgames.com/extensions/?ref=blog.fps.hu) projektet, ami sok-sok bővítményt tartalmaz kifejezetten a játékfejlesztéshez.

#### De miért is ajánlom számodra a three.js használatát?

- Már 1-2 óra alatt látványos eredményt érhetsz el,
- Beszédes metódusai miatt könnyű megtanulni és értelmezni,
- [Kiválóan dokumentált](https://threejs.org/docs/index.html?ref=blog.fps.hu#Manual/Introduction/Creating%5Fa%5Fscene), rengeteg tutorial, videó és snippet érhető el hozzá,
- Könnyű [debugolni](https://chrome.google.com/webstore/detail/threejs-inspector/dnhjfclbfhcbcdfpjaeacomhbdfjbebi?ref=blog.fps.hu),
- A legegyszerűbb [loadertől](http://codepen.io/molarmanful/pen/dPWdLy?ref=blog.fps.hu) kezdve, a [komplex 3D-s játék](http://hexgl.bkcore.com/?ref=blog.fps.hu) is elkészíthető vele.

### Végül a prezentáció
### Designverseny, mi?
URL: https://blog.fps.hu/designverseny-mi/
Last updated: 2026-07-17T08:31:20.000Z
Az elmúlt időszakban számtalan web és mobil app designversenyre neveztünk. Nyertünk itt-ott különböző díjakat. \\o/ Ennek ellenére kifejezett problémáim vannak ezekkel a versenyekkel. Nyugi, nem fröcsögöni akarok, szimplán a tapasztalatainkat írom le, és a gondolataimat azzal kapcsolatban, hogy szerintem hogyan lehete jobb. Szándékosan nem vésem ide, hogy milyen oldalakkal, milyen versenyeken szerepeltünk, pontosan az előzőekben foglaltak miatt. Legyen elég az, hogy számos magyar és nemzetközi kihívásban vettünk részt. Mindemellett magam is voltam jó néhányszor zsűritag, ami egyrészt megtisztelő feladat volt, másrészt pedig láttam belülről, mi és hogyan zajlott.

## Mire jó?

A designversenyen indulók számára három dolog érdekes:

1. szeretnék megmérettetni magukat, visszajelzést kapni arról, hol tartanak, mennyire jó digitális terméket képesek létrehozni mind a hazai, mind a nemzetközi színtéren
2. díjakat akarnak nyerni, ami segíti a sales tevékenységüket, és garantál az ügyfeleik számára egyfajta minőséget
3. láthatóságot szereznek maguknak

## Hogyan nyerj?

Végtelenül leegyszerűsítve a győzelemhez szükséges recept:

- ismert márka oldalával, appjával nevezz
- legyen videóháttér a nyitó oldalon
- mindenképp alkalmazz valami látványos és éppen trendi dolgot: pl. parallax effekt, material design
- legyen órási betűkkel kiírva valami – valami megfoghatatlan és érzelemre ható
- legyenek mindenhol nagy és szép fotók, lehetőleg kevés szöveggel
- feltétlen legyenek animációk, mindenhol: pl. csússzanak, fade-eljenek be a szövegek, panelek, blokkok
- használj ikonokat, sőt még annál is több ikont
- természetesen webfontokat használj, lehetőleg egyedit és sokat

## Mi a baj ezzel?

Számomra ez elkeserítő, mert már bocsánat, de az egész az első benyomásról szól, vagy mondhatnám úgyis, hogy a *parasztvakításról*. Márpedig a web design, vagy mobil app design végképp nem erről szól. Igen, fontos az első benyomás, de az csak egy iciri-piciri szelete az egésznek.

Valójában a design elsődleges feladata, hogy megoldjon egy, vagy több problémát. Méghozzá az alkalmazás célközönségének problémáit, és a célcsoportok igényeit kell kiszolgálnia, mindezt úgy, hogy az egész fenntartható legyen, azaz az üzleti célokat is szem előtt tartja. A célok ráadásul mérhetőek is, és mérni is kell azokat. Valahol ott lehet az alap probléma, hogy kizárólag a grafikai designt szemlélik a versenyeken. De könyörgöm, alkalmazott grafikáról beszélünk, aminek célja van, és az egész nem mehet pl. a használhatóság rovására.

A nagyobb versenyeken – hazai versenyeken nem lehet tudni –, négy pontozási kategória van:

- design
- usability
- creativity
- content

Ez rendben van, de sajnos azt látni, hogy vagy nem értenek hozzá a zsűritagok (ugye igen?!), vagy egyszerűen csak gyorsan letudják a rájuk kirótt feladatot, anélkül, hogy időt feccölnének bele. Ez utóbbival sajnos sokszor találkoztam, mikor zsűritag voltam. Részemről hosszú órákat töltöttem el az értékeléssel, vettem rá a fáradtságot, hogy alaposan megvizsgáljam a lehető legtöbb szempontból az alkalmazásokat, és a lehető legobjektívebben értékeljem azokat. Ezzel szemben sokan a határidő estéjén kattintgattak párat, aztán pontozták. Mikor a személyes, közös értékelés zajlott, látszott, hogy azt sem tudják, melyik alkalmazásról van szó. Szomorú. Persze ez nem feltétlen a zsűri hibája, sokkal inkább hiányzik a motiváció, amit a verseny szervezőinek kellene megteremtenie.

  
> Itt lenne az ideje egy komoly webes/mobilos versenyt csinálni idehaza.
> 
> — Kolozsi István (@kolboid) [2016\. október 18.](https://twitter.com/kolboid/status/788420724163739648?ref=blog.fps.hu)

  
## Hogyan lenne jobb?

Nem egyszerű a kérdés, mégis megpróbálom. Kezdem azzal, hogy a fenti négy kategóriát mégis mi alapján pontozzák? Honnan tudja a zsűritag megállapítani, hogy a tartalom megfelel a célközönségnek? Vagy éppen a használt színvilág? Hiszen fogalmuk sincs, hogy kik a célcsoportok, ők mit szeretnek, mit utálnak, milyen nyelvezetet használnak, mik a céljaik, problémáik, amire az alkalmazás megoldást nyújt? Azt sem tudhatják, hogy mik az alkalmazás üzleti céljai. Mit mérnek? Mik a KPI-ok? Ne adj isten, mik az elért eredmények?

Azzal kezdeném, hogy a pályázóktól bekérném ezeket az adatokat. Nyilván a legtöbbnél kiderülne, hogy ilyen adatok egyszerűen nem léteznek. Nos, akkor ne is induljanak. Néhány versennyel találkoztam, ahol ezt szövegesen be kell mutatni – persze röviden – a célközönséget (egy esetben a célt is). Ez legalább már valami. Sajnos, ahogy láttam, nem sokat számít mit írsz oda.

Ez így ebben a formában, túlontúl szubjektív. No persze, ha a zsűritag ért a használhatósághoz, a grafikai designhoz, a keresőoptimalizáláshoz és mindenhez, akkor már vannak objektív szempontok is. Ha ért hozzá. Míg nemzetközi szinten ez sokkal inkább adott, addig a hazai megmérettetéseken nem igazán látom ezt. Elég csak megnézni, hogy kiket kérnek fel. Sokszor látni, hogy üzleti oldalról, illetve marketing oldalról érkezik a legtöbb zsűritag. Nyilván fontos résztvevők, de ők meg nem tudnak dönteni adatok hiányában, így marad a szubjektív véleményük. Ide tartozik, hogy web design esetében meg kellene nézni azt a website-ot mobilon, tableten is, sőt egy böngészőben rápillantani a reszponzivitásra is (ha olyan persze). Sok nyertes oldalt láttam már, ahol tutira nem csekkolta senki.

### Indoklás

Nem lenne rossz, ha indoklást is kapna minden pályázat, mindezt teljesen transzparensen. Mégis miért és hogyan döntött a bírálóbizottság? Kitenném mindenki elé, már csak azért is, mert tanulhatnak belőle, és nem csak a pályázók, de bárki más is. Értem, hogy ez a versenyeztetés üzleti célokat szolgál a szervezőnek, de ha már befizetjük a nevezési díjat (van ahol nem is keveset), akkor legalább ennyi jár(na) érte. Megjegyzem, hogy létezik egyetlen ilyen – szintén hazai – verseny, ahol indoklást kapnak az induló projektek. Szuper, de milyet? Még régebben akadálymentes kategóriában neveztünk oda egy oldalt, amit elutasítottak azzal a felszólítással, hogy nem felel meg a követelményeknek, ami elég vicces annak tükrében, hogy minden terméknél törekszünk az unverzális designra a legjobb tudásunkkal, ebben az esetben többek közt egy vak sráccal is teszteltünk több körben :). Ilyen.

### Teljesítmény

Ha már web designról és mobil app designról beszélünk, akkor egyszerűen nem hagyható ki az alkalmazás teljesítménye, hiszen az is a design része. Találkoztam olyan döntőbe jutott website-tal, ami majd 50MB-ot tölött le csak a nyitóoldal megnézéséhez. Mobil adatforgalmon. Olyanokkal, melyek bár *cukorkát adnak a szemnek* (eye-candy), de olyan lassúak, hogy 5 másodperc után zárom be. Örökre. Azt gondolom, hogy **a teljesítmény, sebesség mindenképp pontozási kategória kell legyen**. Erre vannak is mérőeszközök, sokat nem is kell bajlódni vele.

### Transzparencia

A transzparencia kényes kérdés. Főleg itthon. Mind tudjuk miért. Érdekes módon nemzetközi szinten is csak akkor mutatják meg a zsűri személyes pontjait, ha a pályázott alkalmazás díjat nyert. Érteni vélem az okokat, de sokkal tisztább lenne az egész, ha minden teljesen átlátható lenne.

Előre ki kell tenni, hogy mi alapján fognak pontozni, és hagynám az olyan bullshiteket, mint innovatív megoldások. Nyilván lehet valami innovatív, azoknak inkább egy külön kategória dukálna.

#### Szempontok

Objektív szempontokhoz léteznek használhatósági (usability), keresőoptimalizálási (és nem a haver cégének lefejlesztett SEO ellenőrzője), grafikai (tipográfiai), akadálymentességi ellenőrző listák és nem utolsó sorban sebesség, teljesítménymérő eszközök (azokhoz értékhatárok). Ezeket egészíthetik ki a szubjektív szempontok.

Tudom, hogy egy gondolat motoszkál a fejedben: *Akkor csinálj jobbat!*  
Nos, lehet megpróbáljuk, persze nem fps keretek között…

Neked mik a tapasztalataid? Várom kommentben!
### Hogyan segítsd a fejlesztőt
URL: https://blog.fps.hu/hogyan-segitsd-a-fejlesztot-1/
Last updated: 2026-07-17T08:31:31.000Z
Egy grafikus gondolatai a leadott grafikákról *1\. rész*

Régóta fogalmazódik ez a poszt. Lehetett volna a címe *Designers vs. Developers,* de akkor pont a lényeg veszne el.

Képzeld el, hogy ülsz otthon, és végre csöngetnek. Megjött! Suhan át a gondolat az agyadon, mire már az ajtónál állsz. Kinyitod, és egy futár áll előtted. Felhúzod a szemöldököd, meghallgatod a monológot, és már egy snicerrel térdelsz a dobozok között, harcra készen a bontogatáshoz, beletörődve. Tudod, hogy csak most kezdődik a móka: kinyit, rendszerez, elnevez, kiválaszt, összerak, szétszed, újra… Már megint! Pedig direkt szerelővel kérted. Szereted a boltot, de néha ő nem szeret téged. Sebaj, most is megoldod, csak épp most nem akartad. Most csak szépen a helyére akartad tenni kedved szerint, és csendben gyönyörködni benne. Franc!

És most képzeld el, hogy a csomagban PSD-k vannak. Ismerős? Akkor te vagy az a builder, aki ezt a posztot olvassa. Az, aki leül, és máris csalódottan keresi azokat a klasszikus hibákat, amikről már van egy listád.

Egy lista neked. **Figyelsz graffer?!** Igen, ez most itt neked fog szólni, mert nekünk könnyebb. Nap mint nap használjuk rutinosan, és fel se tűnik, hogy olykor „rosszul” *(én is).* Így mi az fps-nél összeszedtük, én meg megpróbálom elmondani hozzá a miérteket.

> …onnantól kezdve, hogy közösségben dolgozol, megváltoznak a játékszabályok.

[Photoshop etikett.](http://photoshopetiquette.com/?ref=blog.fps.hu) Ez is lehetett volna a cím, de remélem ez már nem csak a könyvjelzők között van, hanem a tudás birtokában is vagy. Ezekből szeretnék most párat kiemelni a fejlesztő kollégák gondolataival.

### „Rectangle38 copy”

![A képen a Photoshop program rétegei, elnevezve és csoportosítva láthatóak.](https://blog.fps.hu/content/images/2016/10/rectangle38-copy.png)

Ez egy layer neve? Komolyan?! Kérlek, ne tedd ezt senkivel! Magaddal se. OK, tudom, hogy te gyorsan és rögtön eligazodsz bármilyen psd-ben, de képzeld el, hogy valaki ebbe a boltba csak vásárolni jött. Szerintem te is szeretnél segíteni neki. Hagyd, hadd tájékozódjon magától, és akkor nem fog kérdezgetni arról, mit hol talál.

Hogy néz ki a szép struktúra? Érthetően elnevezett csoportok, beszédes rétegek és netán színek.

> „A psd felépítése, struktúrája egy nyelv. Az a nyelv, amit csak és kizárólag te beszélsz, az érthetetlen. Semmire sem jó.”

**Tipp:** Én mostanában inkább csak smart objecteket hagyok a gyökérben, amik egyes modulokat foglalnak magukban. Például: *menu, header, footer stb.* Így ha megnyit a builder egy ilyen elemet, akkor már csak az ottani *group* és *layer* struktúrát kell megismernie. Az előnye neked, hogy ha valahol megváltoztatod a forrást, akkor mindenhol változtatsz rajta. Ugye mekkora segítség?

### Szemetes

Szorosan az előzőhöz kapcsolódnak az ottfelejtett rétegek, csoportok. Ha valamire nincs szükséged, töröld őket. A teleszemetelt psd se nem szép, se nem helytakarékos.

### Fontok

Ez külön poszt lehetne, mármint azok használata és hiánya, de ahogy kollégám mondta:

> „Free transform-mal megmágiázott text, mert úgy kifér”

Ilyen még van?! Kérdezem. Persze, jön a válasz. És hogy buildeled le? Sehogy. Nem vicces, mert a builder meg ott ül, és próbál rá megoldást találni.

**Tipp:** Használd a „trackinget”, amiből már le tudja képezni a [„letter-spacinget”.](http://stackoverflow.com/questions/2760784/how-to-calculate-css-letter-spacing-v-s-tracking-in-typography?ref=blog.fps.hu)

### Inkonzisztencia, avagy gondolkozz a fejlesztő fejével

![A képen sok hasonló színű négyzet látható.](https://blog.fps.hu/content/images/2016/10/inkonzisztencia-1.png)

> „Amikor már a hatodik szürkeárnyalatot találod, elbizonytalanodsz”

De idézhetném a másik fejlesztő kollégát is:

> „Ez most szándékos vagy véletlen?”

A fenti két mondat hűen tükrözi azt az állapotot, amikor nincsenek egységesítve a dolgok. Ilyenkor kicsit vissza szoktam sírni a print korszakomat, amikor még Quarkban kellett valamit elkezdeni. Addig nem tudtál színeket használni, amíg nem definiáltál egy színt. A végén lett egy színpaletta, amin elég volt csak módosítani, és meg is történt mindenhol a változás.

**Tipp:** Erre egy jó megoldás a [Prisma plugin,](http://www.codeadventure.com/prisma?ref=blog.fps.hu#installation) csak sajnos fizetős. Ha tudsz jobbat, ne tartsd magadban, és írd meg kommentben!

Persze nem csak a színekkel eshet az ember túlzásba, hanem eltartásokkal, lekerekítésekkel, vonalvastagságokkal és igazából mindennel. A legjobb, ha készítesz magadnak egy listát az összes elemről.

Várj! Erre van a [styleguide.](http://www.fps.hu/style-guide?ref=blog.fps.hu) Vagy ha már egy meglévőből szeretnél kiindulni, [itt vannak a material forrásai.](https://material.google.com/resources/sticker-sheets-icons.html?ref=blog.fps.hu#sticker-sheets-icons-components) Szerintem az a legjobb megoldás – legyen szó bármekkora projektről –, ha már az elején elkezded építeni és folyamatosan bővítgetni a guide-ot, így minimálisra csökkenthetőek az ilyen különbözőségek. Tudom, idő és szokás kérdése, de hidd el, lassan elkerülhetetlen.

### Normal, Dissolve, Darken, Multiply, Effects…

![A képen a Photoshop program olyan rétege látható, ami egy effektet tartalmaz.](https://blog.fps.hu/content/images/2016/10/normal-dissolve-darken-multiply-effects-5.png)

Próbáltad már CSS-ben leképezni ezeket? Körülbelül úgy kell elképzelni, mint amikor RGB-ről CMYK-ra változtatod a színteret. Akkor is kapsz egyből figyelmeztető ablakot, hogy vannak effektek, rétegkeverési módok, amik el fognak veszni, vagy egyszerűen máshogy fognak megjelenni. Tetézve pedig az a legőrjítőbb, ha egy egész *groupra* alkalmazol áttűnést, vagy effektet.

**Tipp:** Egyesíts. Mentsd el magadnak, ha változtatni kell később, de amikor le adsz egy fájlt, akkor már csak azok az effektek maradjanak benne kibontva, amiket elő lehet állítani CSS-ben is. *Ide jó lett volna egy link ami összefoglalja ezeket. Van ilyened?*

### Jó lesz az szemre

Jó hát! Aztán ne panaszkodj, ha valami nem pontosan ott van, ahova „tervezted”.

> Kézzel behúzza, szemre, hogy az a közepe és akkor úgy lesz. De az *nem 50%,* hanem *53%…* A gridrendszerek használatát ez öli meg.

**Tipp:** Tele a net jobbnál jobb rendszerekkel. Válassz egyet, lehetőleg úgy, hogy egyeztetsz előtte a fejlesztővel és utána karcold bele a monitorodba azokat a segédvonalakat!

### Photoshop

Jogosan merül fel a kérdés, hogy ha ilyen nyűg ez Photoshop, akkor mi van helyette? Erről fog szólni a **poszt 2\. része.** Igyekszünk összeszedni azokat a célprogramokat, amik közelebb tudják hozni a grafikust a fejlesztőhöz.

*Ha addig is van véleményed, javaslatod, akkor mond el, ha pedig találkoztál már valamelyik oldalról a fenti problémák egyikével, oszd meg, hátha eljut olyanhoz, aki tanulhat belőle!*
### Gulp, ahogy mi használjuk
URL: https://blog.fps.hu/gulp-ahogy-mi-hasznaljuk/
Last updated: 2026-07-17T08:31:41.000Z
Egy [régebbi bejegyzésben](https://blog.fps.hu/gulp-js-hatekonysagnoveles/) már írtam arról, hogyan könnyítheti meg a Gulp.js használata a front-end fejlesztést, de leginkább csak bemutató jelleggel. Azóta eltelt majdnem két év és túl vagyunk számos nagy projekten, ahol gyakorlatban is használtuk az eszközt, és mára oda jutottunk, hogy el sem kezdünk nélküle fejleszteni. Megpróbálom összegyűjteni az eddigi tapasztalatainkat, és kifejteni, hogy milyen modulokat, miért és hogyan használunk.

### Két év tapasztalatai vázlatpontokban

- kezdetekben leginkább WordPress projektekre húztuk praktikai okokból, azóta általánossá vált
- nem minden kolléga használta, mára minden projekt esetén alkalmazzuk
- ha egy kolléga először találkozik vele, nagyon hamar ráérez és átlátja a működését, a célját
- gyorsabb és kényelmesebb fejlesztést tett lehetővé
- megoldást nyújtott a verziókezelt projektjeink front-end fejlesztés során előkerülő kellemetlenségeire
- átlátható és fenntartható css kódot eredményezett
- elősegítette az újrafelhasználható css kódolást

### Ahogy mi használjuk

Az alábbi linken elérhető egy, az általunk használt konfigokból: [gulpfile.js](http://goo.gl/AQIFIe?ref=blog.fps.hu)  
Azt hiszem, a kód magáért beszél, így nem is megyek bele, inkább a folyamatot írom le, hogy miért lett ilyen.

A gulp használatának kezdetén két fő megoldandó problémát tartottunk szem előtt:

- több fejlesztő is dolgozhasson conflictoktól mentesen ugyanazon projekt front-end kódjain (CSS, JavaScript)
- az oldalbetöltődési sebesség javítása érdekében optimalizáljuk a kódot (minify) és minimalizáljuk a requestek számát.

Az előbbi felvetésekre tökéletes megoldás volt, hogy logikai egységekre bontottuk az oldal által használt css-t (komponensek, tipográfia, grid, helper stb.), továbbá minden oldalhoz tartozó stíluslapok is külön fájlban kaptak helyet. Ezeket összefűztük adott sorrendben (kezdetben a fájlnév kapott prefixet, amivel meghatároztuk a sorrendet, így a reset.css-ből lett 00\_reset.css), majd az eredmény minify után a style.min.css fájlban kötött ki. Ezeket elég egyszerűen meg tudtuk oldani bármilyen „getting started with gulp” tutorial alapján a [gulp-concat](https://www.npmjs.com/package/gulp-concat?ref=blog.fps.hu), [gulp-clean-css](https://www.npmjs.com/package/gulp-clean-css?ref=blog.fps.hu) és [gulp-uglify](https://www.npmjs.com/package/gulp-uglify?ref=blog.fps.hu) modulokkal.

Természetesen itt nem akartunk megállni, hiszen oly' sok helyen kiemelik, hogy a gulp használatával megspórolhatjuk a vendor prefixek használatát ([gulp-autoprefixer](https://www.npmjs.com/package/gulp-autoprefixer?ref=blog.fps.hu)) és elkezdtünk mindent SASS alapokon kezelni (<gulp-sass>), ennek eredményét [az alábbi blogposztban](https://blog.fps.hu/stiluslapok-fps-modra/) olvashatod el.

Valljuk be, a fájlnevek számmal történő megjelölése nem a legelegánsabb mód a sorrend meghatározására, ráadásul megköveteli, hogy egy könyvtárban legyen minden scss fájl. Ennek kiküszöbölésére vezettük be a [gulp-order](https://www.npmjs.com/package/gulp-order?ref=blog.fps.hu) modult, aminek segítségével meghatároztuk az összefűzés sorrendjét.

![Futás közben](https://blog.fps.hu/content/images/2016/10/gulp2.png)

### Extrák

A fent leírtak alapvetően ellátnak minden feladatot, amire szükség van, ám lehetett még szépíteni a dolgok működésén. A [gulp-util](https://www.npmjs.com/package/gulp-util?ref=blog.fps.hu) modul lehetővé teszi az egyes üzenetek színes megjelenését, a kényelmesebb hibakezelést (három beep jelzi, ha valami nem tudott rendesen lefutni) és bekerült egy *help* task is, ami visszaadja a futtatható taskok listáját minimális magyarázattal.

Gyakran használunk svg ikonokat, amik kis méretűek, és hosszas mérlegelés után arra jutottunk, hogy bizonyos esetekben abszolút járható út és plusz szerverhívásoktól mentesíthetjük magunkat, ha ezek is bekerülnek a legenerált css fájlba base64 kódolással, amihez a [gulp-css-base64](https://www.npmjs.com/package/gulp-css-base64?ref=blog.fps.hu) modult használtuk. Ezt persze nem használjuk minden esetben, paraméterrel (komment a szelektor után) letiltható.

Az összefűzés folyamatába beszúrtunk egy source map generálást is ([gulp-sourcemaps](https://www.npmjs.com/package/gulp-sourcemaps?ref=blog.fps.hu)), ami által a DevTools használata során könnyű beazonosítani, hogy az egyes szelektorok melyik forrásfájlban lettek definiálva, így nem kell keresgélni, ha valamihez hozzá akarunk nyúlni.

Mivel elég sok forrásfájlt kell lefordítani minden változáskor, így a folyamatosan futó „watcher” taskok kicsit máshogy működnek, mint az induláskor lefutóak. A szerver tehermentesítése érdekében csak a változott fájlokat dolgozza fel (scss->css) újra, amit a [gulp-newer](https://www.npmjs.com/package/gulp-newer?ref=blog.fps.hu) modul old meg.

### Végszó

Egyértelműen ki tudom jelenteni, hogy a front-end task runnerek (esetünkben a Gulp.js) érezhető mértékben megkönnyítik a front-end fejlesztési munkát. Hamar bele lehet jönni a használatukba, és nem csak a robosztus projektek esetén érdemes alkalmazni őket. Elősegítik az újrafelhasználható és átlátható css kód írását, azon felül folyamatos visszajelzést is kapsz, ha valamit nem megfelelően csináltál ([gulp-csslint](https://www.npmjs.com/package/gulp-csslint?ref=blog.fps.hu)), ezzel is a tiszta (css) kód felé haladva.  
Rengeteg lehetőség és modul van még, amivel méginkább növelni lehet a hatékonyságot, az ftp deploy-on keresztül a nyelvi PO fájlok generálásán át a komplex forráskódelemzésig.  
Ha eddig nem használtál task runnert, tégy egy próbát, nem fogsz csalódni!
### Hagyjuk már
URL: https://blog.fps.hu/ertheto-kommunikacio-beszelj-vilagosan/
Last updated: 2026-07-17T08:31:52.000Z
Ez egy note to myself, neked meg kedves olvasó: FYI. Van egy problémám a széles körben elterjedt bias-szal, miszerint rantolunk össze-vissza, fullon van a beszédünk, írásunk mindenféle idegen és szakmai kifejezéssel. Sorryvagyok, de ez miért jó? Avagy kinek jó? #nooffense

Lassan eljutottunk oda, hogy szakmabeli ismerőseimmel chatelve, egyszerűen nem értem a másikat. Mondom, szakmabelivel. Gugliznom kell ezerrel, hogy felfogjam mit akar mondani. Értem, hogy többnyire rövidebb, kifejezőbb így kommunikálni, de azt hiszem túltoltuk a biciklit. Moderáljuk meg magunkat.

**OK, most fejeztem be és arra bíztatlak téged is, hogy csatlakozz!**

Három lehetséges oka van annak, ha valaki így kommunikál:

#### 1\. Nem ért hozzá

> Amit nem tudsz egyszerűen elmagyarázni, azt nem is érted egészen. – Richard Feynman

Sokszor olvasok különböző felületeken, hallok olyat, hogy értelmetlenül használnak mindenféle jól hangzó kifejezést, buzzwordöt (sicc!).

#### 2\. Direkt csinálja

Méghozzá azért, hogy ne értsék, amit mond. Vagy azért, hogy magát nagyon okosnak, szakmailag felkészültnek tüntesse fel. EGO mesterek, magas lovon ülők, ez nektek szól. Rosszabb esetben azért teszi ezt, hogy megvezesse a másik felet. Remélem ez utóbbi ritka. Ha ilyennel találkozol, akkor **hívd fel a figyelmét, hogy nem érted! Kérd meg, hogy magyarázza el érthetően** és a lehető legegyszerűbben! Ha ez nem megy, akkor nyomban kiderül a turpisság. Igaz nem feltétlen. Az is lehet, hogy a szakértő nem a szavak embere, nem képes a jó kommunikációra. Ez is egy fejleszthető készség. Nem biztos, hogy azt jelenti, nem ért hozzá, sőt. Viszont ez utóbbi eset már inkább a következő ponthoz tartozik.

#### 3\. Nem veszi észre

Bizony. Mikor valaki egy szakterületet a magáévá tesz és elmerül benne, akkor óhatatlanul elkezdi használni a szakkifejezéseket, már csak azért is, mert úgy pontos a mondandója. Arról nem is beszélve, hogy minden anyag angol nyelven áll rendelkezésre, ebből egyenesen következik, hogy az esetek nagy részében egyszerűen nincsenek megfelelő magyar kifejezések. Beég az agyába, azáltal a hétköznapi beszédébe. Érthető. Megjegyzendő, hogy az, aki szakmailag felkészült egy területen, az igényes is arra, amit mond. A szakkifejezések azért keletkeztek, mert pontosan leírják a mögöttes tartalmat. Ha azt leegyszerűsíti, akkor már nem lesz igaz, mert ugyebár „kivéve, ha…”, meg „attól függ…”. Lehet az a jó út, ha lebutítva kommunikálsz, majd utána terelgeted a gondolatokat egyre több kiegészítéssel, hogy kialakuljon a fogalom, amihez a végén eljut a másik fél. Talán ez az út a megfelelő.

### Törekedjünk az egyszerűségre!

Próbáljuk meg. Mindig, mindenhol. A partnered, ügyfeled is boldogabb lesz, egymással is könnyebb lesz a kommunikáció. Ugyan vegyük már figyelembe, hogy kivel és kinek beszélünk. Ennyi. Nem is ragozom tovább, érted te…

Mindenkinek ajánlom Gergely Vera nagyszerű projektjét, amit a [közérthető fogalmazásért](http://kozerthetofogalmazas.hu/?ref=blog.fps.hu) hozott létre. Jó olvasást!
### Magyar (mobil)web sebesség
URL: https://blog.fps.hu/magyar-mobil-web-sebesseg-ssl/
Last updated: 2026-07-17T08:32:02.000Z
Megvizsgáltuk a magyar webet oldalbetöltési sebesség, mobil optimalizáltság, titkosított kapcsolat szempontjából. Egy évvel ezelőtt is megtettük (sajnos kevesebb adattal) és most megismételtük, így van némi összehasonlítás is. Adatok, következtetések, gondolatok következnek.

### Alapok

- [Alexa TOP 500](http://www.alexa.com/topsites/countries/HU?ref=blog.fps.hu) alapján **összesen 304 site**
- kizárólag magyar nyelvű oldalak
- a nagy külföldi tulajdonban lévő oldalakat kihagytuk (Google, Wikipedia, Facebook stb.)
- **2015\. májusában** kezdtük és ismételtük meg **2016\. júniusában** (a leglátogatottabb oldalak listája számottevően nem változott, időközben néhány site megszűnt)
- csakis nyitó oldalakkal foglalkoztunk
- Google PageSpeed Insights eszköz szolgált a méréshez

Ebben a [Google Spreadsheetben megnézheted](https://docs.google.com/spreadsheets/d/1QrjJJqSNhmHHl1Y1oihST5w6uQg6tLkxEeaa-Nqx5z4/edit?usp=sharing&ref=blog.fps.hu) az összes adatot, ha érdekelnek a részletek.

### Oldalbetöltési sebesség

Miért is fontos foglalkozni vele? [Olvasd egy régi posztunkat](https://blog.fps.hu/sebesseg-optimalizalas-gyors-honlap/) erről, ahol a vonatkozó kutatásokat is belinkeltük.

**Mert**

- a Google erős rangsorolási faktorként veszi figyelembe, SEO szempontból kifejezetten fontos
- felhasználói élmény szempontjából: nem vagyunk hajlandóak sokat várni, kilépünk, nem használjuk az oldalt, ha az lassú
- közvetlen hatással van a konverzióra, bármi is legyen az

#### Google PageSpeed Insights

- a Google eszköze, amit a botja is használ
- mobilt és desktopot külön vizsgálja (ahogy a bot is)
- 1–100-as skálán pontozza az oldalakat
- mindkét esetben (mobil, desktop) **85 ponttól boldog a Google**

#### Minimum 85 pont?

Nem olyan egyszerű ezt elérni. Az fpsnél az általános követelményekhez **mobilon min. 70 pont, míg desktopon min. 80 pont** kerül. Mindig törekszünk nagyobb pontszámra, sőt a cél mindig a minimum 85 pont, de…

##### Mi okozza a legtöbb problémát?

- rossz tervezés vagy ügyféloldali „igények”: túl sok egyedi betűtípus (webfont) használata, háttérképek, háttérvideók használata. Webfontoknál megoldható az aszinkron betöltés, de az csúnya eredménnyel jár: előbb megjelenik websafe fonttal, majd betöltés után átáll a kívánt fontra, ami ugrást okoz, durvább esetekben pedig layout átrendeződést.
- nagy képek, melyeket az oldal kezelője tölt fel és kezel (nem optimalizált képek használata). A nagyfelbontású kijelzők miatt akár 3x-os méretben is fel kell tenni képeket, melyeket az ilyen eszközzel rendelkezők le is töltenek.
- third-party JavaScriptek, melyekre szükség van, méghozzá meghatározott helyen kell behúzni azokat. Ezekre a JS-ekre cache ügyben nincs ráhatásod, ha ott nincs elég browser cache idő beállítva, akkor az máris lehúzza a pontszámot. A legviccesebb az, hogy **a Google Analytics mérőkódján is csak 2 óra cache idő van beállítva**, ami önmagában 1 pont levonásával jár (persze ez is megoldható saját hosztolással). Ide tartoznak a különböző hirdetési rendszerek, mérést, rögzítést végző, social media és egyéb embeddelt tartalmakhoz tartozó JavaScriptek (ezek együttesen leginkább a hírportáloknál fordulnak elő).
- nincs elég széleskörű hozzáférés a hosztinghoz, azaz nem tudod magadnak beállítani a cache időt, tömörítést (gzip) és a különböző http fejléceket. A szolgáltató pedig a globális szolgáltatása miatt nem tudja, vagy egyszerűen nem akarja beállítani ezeket.
- szerver válasz ideje, amire ismét nincs ráhatás, bár a jó szolgáltató választása ebben segíthet, ha van rá mód.
- a keretrendszer, CMS is lehet akadály
- „hajtás feletti” CSS és JS legyen a head szekcióban. Legalábbis ezt szeretné a Google, ami teljesen jogos is. Viszont, ha fejlesztés, karbantartás szempontjából vizsgálod meg a site-ot, akkor ez a szeparálás nem szerencsés.

Persze vannak olyan oldalak a világban, akik elérik a 100 pontot, jellemzően saját tervezői és fejlesztői csapattal, mint pl. a [Smashing Magazine](https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.smashingmagazine.com%2F&tab=mobile&ref=blog.fps.hu). Rulez.

### Eredmények

Íme a kutatás eredményei számokban.

#### 2015\. május

- mobilon átlag oldalbetöltési sebesség: 57 pont
- desktopon átlag oldalbetöltési sebesség: 64,19 pont
- az oldalak 25%-a használ responsive megoldást

#### 2016\. június

- mobilon átlag oldalbetöltési sebesség: 60,05 pont
- desktopon átlag oldalbetöltési sebesség: 65,19 pont
- az oldalak 79,61%-a szolgálja ki a mobil eszközökkel rendelkező felhasználókat
- az oldalak 41,78%-a használ responsive megoldást
- az oldalak 37,83%-a használ szeparált, vagy RESS megoldást megoldást (mobil eszközökhöz)
- az oldalak 14,47%-a használ SSL tanúsítványt (https)
- **mobilon** a felhasználó által **letöltött adatmennyiség 3,81MB** átlagosan. A **legdurvább 43MB** :o, de nem ritka a 10MB feletti letöltés sem, ami a mobilos adatforgalmat tekintve elég kemény
- desktopon a felhasználó által letöltött adatmennyiség 4,89MB átlagosan

Ha az oldalbetöltési sebességek szerinti elosztást nézed (növekvően), akkor látszik csak igazán a helyzet.  
Jó, ha **az oldalak 6–15%-a** teljesíti a Google (és a felhasználók) elvárásait.

![2015. május mobil oldalbetöltési sebességek eloszlása](https://blog.fps.hu/content/images/2016/07/grafikon-2015-majus-mobil-1.png)

![2015. május desktop oldalbetöltési sebességek eloszlása](https://blog.fps.hu/content/images/2016/07/grafikon-2015-majus-desktop.png)

![2016. június mobil oldalbetöltési sebességek eloszlása](https://blog.fps.hu/content/images/2016/07/grafikon-2016-junius-mobil.png)

![2016. június desktop oldalbetöltési sebességek eloszlása](https://blog.fps.hu/content/images/2016/07/grafikon-2016-junius-desktop.png)

#### Változás egy év alatt

- az oldalbetöltési sebesség alig változott: **mobil** esetén **+3,05 ponttal** javult, míg **desktop** esetében mindössze **+1 pont** a fejlődés
- jelentős javulás látható a mobilos eszközökkel rendelkező felhasználók kiszolgálásában
- a responsive megoldás egyre inkább teret nyer
- mindössze két oldal állt át responsive megoldásról más technológiai megoldásra, mindezt úgy, hogy mindkét esetben lassabb lett az oldalbetöltési sebesség
- 52 oldal állt át responsive megoldásra, ami sajnos meglátszik az oldalbetöltési sebességeken: mobilon átlagosan 56,21-ről 52 pontra, desktopon átlagosan 62,23-ról 59,5 pontra csökkent

### Következtetések

- foglalkozni kell az oldalbetöltési sebességgel, mert ezek kifejezetten rossz eredmények
- 2016 derekán még mindig sok olyan oldal van, ami egyáltalán nem foglalkozik a mobil eszközök felhasználóival
- **SSL-t nagyon kevesen használnak**, pedig már ez is SEO faktor a Google-nél és a titkosított kommunikáció előnyeit sem használják ki, holott [vannak ingyenes megoldások is](https://blog.fps.hu/ingyenes-ssl-tanusitvany/).
- az állami szektor oldalai nem szolgálják ki a mobilosokat és nem használnak titkosítást.
- [mindhárom technológiai megoldást](https://blog.fps.hu/mobil-web-strategia-responsive-ress/) alkalmazzák Magyarországon a mobil eszközök kiszolgálására

#### Hogyan lehet elérni a jó sebességet?

- az ügyféloldallal meg kell értetni, hogy szükséges ezzel a technológiai korláttal is számolni
- a tervezés során be kell vonni a fejlesztőket, különös tekintettel a frontendesekre, itt is kiemelkedően fontos az együttműködés
- a jó frontend fejlesztés kulcsfontosságú (tekintve, hogy az oldalbetöltési sebesség 80%-ban a kliens oldaltól függ)
- a grafikus(ok)nak nem árt a CSS ismeret, ugyanis törekedni kell arra, hogy a lehető legtöbb grafikai megoldást tiszta CSS-sel meg lehessen valósítani
- a responsive web design bizony nem könnyű dolog: ismét tervezés és frontend
- természetesen a szerver oldal sebességéről sem szabad megfeledkezni: a jó architektúra tervezése, SQL optimalizálás és backend fejlesztés mind szükséges

### E-commerce

Kiegészítésként [kolboid készített egy mini kutatást](https://blog.kolboid.eu/web-shop-vasarlasi-elmeny-ux-ui-problemak-tippek/?ref=blog.fps.hu) (2016\. márciusban), amiben \~50 magyar webshopot vizsgált (GKI 2015 TOP10-es listája és a Black Friday 2015 akcióban résztvevők alapján):

- a **webáruházak 40%-a nincs mobilra optimalizálva**
- a webáruházak csak 24%-a rendelkezik SSL tanúsítvánnyal
- **mobilon** átlag oldalbetöltési sebesség: **58 pont** (termék oldalak)
- **desktopon** átlag oldalbetöltési sebesség: **66 pont** (termék oldalak)

**Van még min dolgozni…**
### 2016 Apple WWDC
URL: https://blog.fps.hu/2016-apple-wwdc-fejlesztoi-szemmel/
Last updated: 2026-07-17T08:32:12.000Z
Június 13–17\. között került megrendezésre az Apple WWDC fejlesztői konferencia, ahol főleg az Apple különböző platformjaihoz tartozó új OS-eket és a velük együtt érkező új funkciókat mutatták be. Az eseményt a [KeyNote](https://developer.apple.com/videos/play/wwdc2016/101/?ref=blog.fps.hu)\-tal nyitották meg.

### watchOS 3

A Keynote-on először a watchOS 3 került bemutatásra, ami az Apple Watch-hoz érkező legújabb operációs rendszer lesz. Az egyik legfontosabb újítása, hogy a már egyszer elindított alkalmazásokat letárolja a memóriában, így nem kell hosszas másodperceket várni arra, hogy újra elinduljanak. Ezen felül kapott egy, az iOS-ben található vezérlőpulthoz hasonló saját vezérlőpultot, illetve az üzenetekre, amikről értesítést kapsz, lehetőséged lesz válaszolnod is előre beállított, vagy az órán kézzel megírt üzenetekkel is. A leghasznosabb funkciónak viszont az új SOS funkciót tartom, annak ellenére, hogy remélem minél kevesebb felhasználónak lesz rá szüksége. Az óra oldalán lévő gombot hosszan benyomva hívást indít a helyi segélykérő szolgáltatásoknak, majd ha annak vége, akkor elküldi nekik a felhasználó helyzetét, értesíti a vészhelyzet esetén értesítendő személyeket, legvégül pedig az egészségügyi adataidat írja ki a kijelzőre. Hirtelen vészhelyzetek esetén rendkívül hasznos funkció lehet.  
Érdekesnek találom az Apple Watch új funkcióit, de fejlesztőként továbbra se látok benne akkora potenciált, hogy komolyabban foglalkozzam vele, pláne ha nem nemzetközi alkalmazás készítésével foglalkozunk, mivel Magyarországon még nem terjedt el annyira az eszköz.  
A watchOS 3 fejlesztői preview már elérhető és az ingyenes frissítés ősszel érkezik.

### tvOS

A tvOS az Apple legújabb 4\. generációs Apple TV-nek az operációs rendszere. Az AppStore bekerülésével megjelentek az alkalmazások is az okos tv-n és ma már 1300 csatorna, illetve 6000 alkalmazás érhető el rajta. Készítettek egy új alkalmazást iPhone-ra, amivel akár a távírányítást is fel lehet váltani. Sirit alkalmassá tették a téma alapú keresésre, Youtube-on történő keresésre és akár élő adásra. Azok az univerzális alkalmazások, amiket a felhasználó letölt az iOS-es eszközén, automatikusan letöltődnek az Apple TV-re is. Fejlesztők számára igazán érdekes lehetnek az új elérhető API-k. A ReplayKitnek köszönhetően az alkalmazásokban egyszerűen elérhetők lesznek a felvételek, illetve az élőközvetítések. A PhotoKittel az alkalmazások hozzáférhetnek a felhasználó képeihez és videóihoz az iCloudon. Végül a HomeKittel olyan alkalmazásokat lehet mostantól fejleszteni, amik hozzáférhetnek és irányíthatják a HomeKites eszközöket az Apple TV-n keresztül.

### Sierra

Az új OSX verzió (amit ezentúl macOS-nek fognak hívni) a Sierra nevet kapta. Új funkcióként került be az Auto unlock, aminek segítségével, ha a felhasználó rendelkezik egy Apple Watch-csal, akkor a mac automatikusan képes autentikálni a felhasználót. A Universal Clipboard segítségével mostantól az összes mac és iOS eszközön keresztül lehet majd másolni és beilleszteni. Az Optimized Storage funkció segítségével a macOS automatikusan feltölti a régen használt fájlokat iCloudba, valamint a már többé nem használt fájlokat letörli (pl.: a böngészős cache-ek tartalmát). Egy további fejlesztés, hogy most már azok az alkalmazások, melyek alkalmasak lehetnek rá, lapokba rendezhetők lesznek csak úgy, mint például a böngészőkben. Bekerült – az iOS 9-ben iPadeken bemutatott – kép a képben funkció is az operációs rendszer új verziójába. Talán a legfontosabb új funkció, ami belekerült Sierra-ba az Siri. Személy szerint én soha nem használtam Sirit a kipróbáláson túl, de aki már hozzászokott a használatához iOS-n, az biztos örülni fog, hogy most már mac-en is elérhető.

Kíváncsian várom a Sierra-t, de a helyzet az, hogy ezek a funkciók nem keltették fel túlságosan az érdeklődésemet iránta. Egyedül az Apple új fájlrendszere az APFS (Apple File System) az, amit kíváncsian várok, de abból is még csak egy fejlesztői verzió fog kikerülni a Sierra-val és ténylegesen csak valamikor 2017-ben lesz elérhető.

A Sierra már elérhető fejlesztői preview-ként, publikus bétába júliusban kerül, ingyenes frissítés pedig ősszel érkezik a késői 2009-es vagy későbbi MacBook és iMac-re, valamint a 2010-es és későbbi MacBook Air, MacBook Pro, Mac mini és Mac Pro-ra.

### iOS 10

Az iOS 10 kapta idén a főszerepet a Keynote-on. Rengeteg kisebb–nagyobb új funkcióval és API-val bővült az iOS 9-hez képest. Újra tervezték a News és a Music alkalmazást, a vezérlőpult új felületet kapott külön felülettel a zenének és a HomeKit eszközöknek. Új alap alkalmazást kapsz, aminek Home a neve és a HomeKit eszközöket lehet irányítani vele.  
A Photos alkalmazásban mostantól a térképen a készítésük helyétől függően is megjelenítheted a képeid, valamint automatikus rendezést kérhetsz a képen szereplő személyek szerint, a beépített arcfelismerő rendszernek köszönhetően. Ugyan ezt a rendszert használva rendezheted a képeid a rajtuk szereplő tájak és objektumok szerint is. Végül pedig a rendszer automatikusan tud készíteni egy összeállítást is a képekből egy adott témán belül, amiből akár egy kisebb videót is képes készíteni.  
A Quicke type-ot továbbfejlesztették és mostantól Siri a tartalomtól függően fog ajánlani lehetőségeket, valamint képes lesz egyszerre több különböző billentyűzettel rendelkező nyelvet is kezelni.

Az eddig felsorolt új funkciók többsége érdekesnek tűnt, ami viszont mint mobil fejlesztőnek különösen felkeltette a kíváncsiságomat, azok az új interaktív értesítések, az új kiegészítések és API-k a Maps alkalmazáshoz, iMessage-hez és a hívásokhoz, valamint a Siri új fejlesztői API-ja.

#### Új interaktív események

Az iOS 10-zel együtt érkezik az új, fejlettebb esemény jelzés, amivel már nem csak egy szöveges üzenetet kaphatsz majd eseményként, hanem akár képeket, gifeket, videókat, audiókat, vagy akár fejlesztők által készített felületeket is megjeleníthetnek benne. Ezek a felületek nem érzékelik az érintéseket, de az esemény felajánlhat különböző válasz lehetőségeket, amiknek hatására frissíthető a felület. Már az iOS 8 óta lehet szövegesen válaszolni egy értesítésre, de csak az utolsó üzenetet láthattad, valamint nem is maradtál utána a beszélgetésben. Az új értesítési rendszerrel a teljes beszélgetést megnézheted értesítésen belül és folytathatod anélkül, hogy belépnél az alkalmazásba.  
További információk: [Advanced Notification](https://developer.apple.com/videos/play/wwdc2016/708/?ref=blog.fps.hu)

#### Maps

Újratervezték a Map felületét, valamint kiegészítették néhány új funkcióval mint pl.: felajánl lehetséges úti célokat az alapján, hogy a nap adott szakaszában hova szokott a felhasználó elmenni, illetve mutatni fogja a forgalmat a kijelölt útvonalon. Az igazán fontos új funkció viszont nem csak a felhasználók számára jött, hanem a fejlesztők számára is, mivel mostantól lehet kiegészítőket írni a Maps alkalmazáshoz, aminek köszönhetően további funkciókkal bővíthető majd az alkalmazás, attól függően, hogy a felhasználó milyen kiegészítőket tölt le hozzá.

#### iMessage

Az iMessage alkalmazás is rengeteg új funkcióval bővült ki. Mostantól támogatni fogja a RichLinket, egyszerűbben lehet majd képeket és videókat küldeni vele, automatikusan fel fogja ajánlani a szövegen belül a emojik beillesztését, valamint rengeteg új effekttel fog bővülni az alkalmazás. Különböző típusú üzenet buborékokat lehet küldeni. Az elküldött, vagy megkapott képeket matricákkal lehet majd kiegészíteni, és akár egész képernyős effekteket is lehet majd küldeni. Számomra viszont a legnagyobb hír itt is az, hogy mostantól ehhez az alkalmazáshoz is készíthetnek a fejlesztők kiegészítőket, amelyeket majd a felhasználók kedvük szerint letölthetnek.  
További információk: [iMessage Apps and Stickers Part 1](https://developer.apple.com/videos/play/wwdc2016/204/?ref=blog.fps.hu), [iMessage Apps and Stickers Part 2](https://developer.apple.com/videos/play/wwdc2016/224/?ref=blog.fps.hu)

#### VoIP API

A fejlesztők számára mostantól lehetőség van olyan API hívásokat is írni, aminek segítségével a felhasználó egy alkalmazás segítségével (pl. Skype) tud hívást indítani vagy fogadni anélkül, hogy előtte az alkalmazást előtérbe kellene hoznia. Az alkalmazáson keresztüli hívás, vagy egyéb opciók mostantól megjelenhetnek akár a kontaktokban is az alap telefon hívás mellett.  
További információk: [Enhancing VoIP Apps with CallKit](https://developer.apple.com/videos/play/wwdc2016/230/?ref=blog.fps.hu)

#### Siri

![alt](https://blog.fps.hu/content/images/2016/06/-j-Siri-api-haszn-lat-k-zben.jpg)

Siri mostantól rendelkezik egy fejlesztői API-val, aminek hála a programozók készíthetnek olyan alkalmazásokat, amiket akár Siri-n keresztül is el lehet indítani és akár különböző funkciókat is használni lehet majd, mint például üzenet küldése egy ismerősnek, vagy vásárlás egy alkalmazáson keresztül. Természetesen lesznek határai ennek a funkciónak is, és mivel a magyar nyelvet még nem támogatja Siri, így magyar alkalmazásoknál nem igazán lesz még létjogosultsága (egyelőre). Nemzetközi alkalmazásoknál viszont egy olyan felhasználónak, aki már hozzászokott Siri használatához, vagy valamilyen testi rendelleneséggel rendelkezik, ami akadályozza a telefon kezelését, rendkívül nagy segítséget is jelenthet, ha minél több funkció elérhető Siri-n keresztül is.  
További információk: [Extending Your Apps with SiriKit](https://developer.apple.com/videos/play/wwdc2016/225/?ref=blog.fps.hu)

Az iOS 10 már elérhető fejlesztői preview-ként, publikus bétába júliusban kerül, ingyenes frissítés pedig ősszel érkezik a 4\. generációs iPad, iPad Air, iPad Air 2, iPad Pro, iPad mini 2, iPad mini 3, iPad mini 4, 6\. generációs iPod touch, iPhone 5, iPhone 5c, iPhone 5s, iPhone SE, iPhone 6, iPhone 6 Plus, iPhone 6s és iPhone 6s Plus-ra.

### Apple File System

Az APFS (Apple File System) egy új generációs fájlrendszer, amit az Apple külön a saját termékeire tervezett, szem előtt tartva, hogy ugyanolyan jól működjön az Apple Watch-on mint ahogy a Mac Pro-n is. Flash/SSD tárolókra lett tervezve és elsődleges szerepet kapott a titkosítás. Több különböző új funkció is be került az új fájlrendszerbe:

- Space Sharing: A különböző partíciók ugyanazzal a szabad területtel rendelkeznek a fizikai tárhelyen. Ez azért lehetséges, mert itt a partíciók nem foglalnak le előre szabad területeket, az APFS partíciói újrapartícionálás nélkül képesek növelni vagy csökkenteni a méretüket.
- Cloning of Files and Directories: Egy „klón” majdnem azonnali másolata egy fájlnak, ami így kevesebb helyet foglal. Amikor módosítanak egy klón fájlt, akkor csak a módosított blokkokat menti le egy új területre a rendszer, így valójában kisebb területet foglal.
- Snapshot: Egy csak olvasható másolata az eredeti fájlrendszernek. Ennek segítségével az operációs rendszer képes hatékonyabb mentéseket készíteni egy fájlrendszer aktuális állapotáról és egy lehetőséget ad arra, hogy visszaállítsd egy meghatározott múltbeli pillanatra.
- Atomic Safe-Save: A csomagok és mappák átnevezése is atomi műveletként történik.

OSX Yosemite, vagy korábbi OSX verziók nem lesznek képesek majd felismerni. A HFS+ fájlrendszerről lehetőség lesz átállni APFS-re anélkül, hogy bármit újra kellene telepíteni. Az APFS 2017-ben fog megjelenni.  
További információk: [Introducing Apple File System](https://developer.apple.com/videos/play/wwdc2016/701/?ref=blog.fps.hu)

### Xcode 8.0

Az új Xcode támogatni fogja Swift 2.3-at és Swift 3-at. A Swift 2.3 egy kisebb kiegészítése a Swift 2.2-nek, ami azért készült, hogy kompatibilis legyen az új SDK-val. A Swift 2.3-as támogatás viszont a jövőbeli Xcode verziókban már nem lesz benne, így érdemesebb inkább Swift 3-ra frissíteni a forráskódokat, amiben az Xcode továbbra is segítőkezet nyújt a Swift migrator eszközzel.

Változások történtek a Signing-ban is. Xcode 8-ban választani lehet majd Automatic Signing és Custom Signing között. Az Automatic Signing-nál az Xcode automatikusan létrehozza és szükség esetén frissíti a fejlesztői provision profile-kat, certificate-eket és entitlement-eket. Custom Signing esetén ezeket mind a fejlesztőnek kell kezelnie ugyanúgy, mint eddig. Fontos megjegyezni, hogy az Automatic Signing csak az Xcode által létrehozott provision profile-okat és certificate-eket fogja módosítani. Ezen felül mostantól egy fejlesztői csapat, egyszerre több fejlesztői certificate-tel is rendelkezhet.  
Az új Xcode mostantól támogatni fogja a kiegészítőket, amivel hivatalosan is lehet új funkciókkal bővíteni, viszont az eddig erre használt nem hivatalos módszerek, mint például az Alcatraz, mostantól nem fognak működni az új System Integrity Protection miatt.

Javítottak az Interface Builderen, aminek hála gyorsabban fog működni, valamint bekerült egy új memória debugger is, amivel a memória szivárgásokat lehet majd könnyebben megtalálni.  
Az Xcode 8 bétája már elérhető a fejlesztők számára, az Apple honlapján.

Az APFS-t leszámítva az összes fent említett szoftver fejlesztői Preview-ja, valamint júliustól a publikus bétája elérhető [ezen a linken](https://developer.apple.com/download/?ref=blog.fps.hu).
### WordPress?
URL: https://blog.fps.hu/wordpress/
Last updated: 2026-07-17T08:32:22.000Z
Noha a WordPress a világ legelterjedtebb tartalomkezelő rendszere, a mai napig megoszlanak a vélemények róla. A marketing szakemberek istenítik, mivel a „pár kattintással saját weboldalad lehet” szlogen igen hangzatos, és alapvetően igaz is lehet. A fejlesztők egy része leragadt a biztonság-technikai kérdéseknél, és egyértelműen ellenzi a használatát. Akárhogyan is nézzük, az [internet weboldalainak negyedét](http://expandedramblings.com/index.php/wordpress-statistics/?ref=blog.fps.hu), nagy látogatottságú portáloktól kezdve az e-commerce oldalakon át a személyes blogokig WordPress motor hajtja.

Rengeteg thread és fórum foglalkozik a WordPress létjogosultságával, és szinte mindig ugyanazok az érvek és ellenérvek jönnek elő. Jó néhány gyakran előforduló felvetést igyekeztem mindkét irányból megvizsgálni a tisztánlátás érdekében.

### Open Source

Fejlesztettél már saját CMS-t (szerintem minden fejlesztő belevág). A tied sem készült el soha? :) A WordPress legnagyobb előnye és egyszerre hátránya is, de mindenképp említésre méltó, hogy több mint 10 éves múltra tekint vissza és több ezren vettek és vesznek részt a fejlesztésében, aminek az eredménye egy folyamatosan fejlődő és rendszeres javításokon áteső rendszer. A *több szem többet lát* elv itt hatványozottan érvényesül és a nyílt forráskódban a hibákat a rosszindulatú felhasználók mellett a segíteni akarók is kiszúrják. Míg egy saját CMS esetén fennáll a veszélye, hogy a (kisebb) bugok javítása idő hiányában elmarad vagy akár fény sem derül rájuk, addig a WordPress esetén garantált az alapos tesztelés és folyamatos fejlesztői közreműködés. A dokumentációról nem is beszélve.

### Biztonsági kérdések

Rengetegen ellenzik a WordPress használatát a biztonsági kockázatra és a támadások statisztikájára hivatkozva. Tagadhatatlanul nagy számokkal lehet találkozni ezen a téren, viszont érdemes megemlíteni, hogy ne is várjon mást az ember annak tudatában, hogy az interneten fellelhető oldalak 26%-át WP motor hajtja. Ugyanakkor valóban túl sok a könnyen támadható oldal, mivel sokan nem fordítanak kellő figyelmet a megfelelő beállításokra és óvintézkedések elvégzésére. Az sem elhanyagolható adat, hogy [a törések több mint 40%-a](https://www.dart-creations.com/wordpress/wordpress-tutorials/the-essential-checklist-to-prevent-your-wordpress-website-from-getting-hacked.html?ref=blog.fps.hu) a nem megfelelő hosting hibája, a másik 60% pedig a gyenge jelszavak, pluginek és template-ek számlájára írható (ez csak egy statisztika a sok közül). Számos kiváló [cikk](https://www.keycdn.com/blog/wordpress-security/?ref=blog.fps.hu) és [könyv](http://www.pdfgallery.net/2015/08/locking-down-wordpress/?ref=blog.fps.hu) fellelhető a témában, amik elengedhetetlen tudásanyagok mindenkinek, akik WordPress alapú oldalakkal akarnak foglalkozni.

![Wordpress biztonság](https://blog.fps.hu/content/images/2016/06/wordpress_biztonsag-1.jpg)

### Folyamatos frissítések

[Gyakran jönnek ki új frissítések](https://wordpress.org/news/category/releases/?ref=blog.fps.hu), ami egyszerre pozitív (hiszen fejlődik a rendszer, javítják a biztonsági réseket), ugyanakkor hátrányod is származhat belőle, ha nem tartod karban az oldalaidat. A 3.7-es verzió óta bevezetésre került az automatikus frissítés, ami jelentősen változtatott a fellelhető verziók eloszlásán, ám rengeteg a magára hagyott oldal, ahol még nem elérhető ez a funkció. Sokan ki is kapcsolják, mivel olyan dolgokat módosítottak, amit a frissítés felülírhat vagy csak egyszerűen túl óvatosak ezzel kapcsolatban (egyébként számos esetben mi is kézzel frissítünk mindent, és utána ellenőrizzük a megfelelő működést). Fontos megjegyezni, hogy a biztonság egyik kulcstényezője a **mindig up-to-date rendszer**.

### Erőforrásigényes

A WordPress univerzálisra lett tervezve, igyekszik minden igényt kielégíteni. Ebből következik, hogy nem minden esetben optimális a működése. Kötött adatbázisszerkezet van, és ha a beépített függvényekből akarsz gazdálkodni, bizony érdekes megoldásokkal és hatalmasra duzzadt táblákkal kell szembesülnöd. Rengeteg esetben érdemes elgondolkodni a projekt kezdetén, hogy biztosan a WordPress a legjobb választás? Egy párszáz termékes webshop még gond nélkül elfut Woocommerce plugin alkalmazásával, ugyanakkor ezer felett már vannak célirányosabb megoldások, de nem csak e-commerce témában lehetne ilyen példát hozni.

### Blogmotor vs CMS

Számtalanszor találkoztam azzal a kifogással is, hogy a WordPress csak egy blogmotor, másra nem is való. Az évek során olyan irányba ment el a fejlesztése (elég csak a custom post típusokra és taxonómiákra gondolni), ami által egyértelműen kinőtte magát a blogmotor kategóriából és egy teljes értékű CMS lett. Nem egy hozzászólásban olvastam, hogy „minden WP oldal egyforma”. Ezért nem a motort tenném felelőssé, hanem az oldal fejlesztőjét. A WordPress egy eszköz és tőled függ, hogy mire használod és hogyan. Érdekes adat, hogy [több mint kétezer hook](http://adambrown.info/p/wp%5Fhooks/hook?ref=blog.fps.hu) (a beavatkozási pontnál nem tudok jobb fordítást) van regisztrálva a rendszerben, így gyakorlatilag a működés minden apró részét felül tudod írni.

### Mindenre van egy plugin

A hivatalos [WordPress plugin adatbázisban](https://wordpress.org/plugins/?ref=blog.fps.hu) több mint 45 ezer bővítmény érhető el. Ez hihetetlen mennyiség és szinte minden felmerülő problémára találsz valamilyen plugint, viszont azt is figyelembe kell venned, hogy rengeteg olyan van, amit több éve nem frissítettek, tele van biztonsági résekkel (amikről könnyen kaphatsz [jelentéseket](https://www.pluginvulnerabilities.com/?ref=blog.fps.hu) is), vagy csak szimplán silány minőségű. Minden elismert szakember azt javasolja, hogy kizárólag gyakran frissített, megbízható fejlesztői forrásból származó bővítményeket telepíts, hiszen elég nagy támadási felületet adhatnak (és még csak aktiválva sem kell lenniük). A pluginekkel való kapcsolatomról [itt olvashatsz](https://blog.fps.hu/a-wordpress-es-a-letoltott-plugin-esete/) egy korábbi írásomban.

![Wordpress pluginok](https://blog.fps.hu/content/images/2016/06/wordpress_plugin.jpg)

### Közösség és támogatás

Kerestél már rá a *wordpress tutorial* kifejezésre? A találati lista mérete mindent elmond arról, hogy csak az nem fog megtanulni WordPress alatt fejleszteni, aki nem akar. Hihetetlen nagy közösség áll a rendszer mögött, számtalan erre specializálódott cég, szakember, blog és portál lelhető fel a témában. Gyakorlatilag a fejlesztés közben felmerülő kérdések 99 százalékára perceken belül lehet választ találni (az más kérdés, hogy nem mindig a legszebb megoldást) és ha nem vagy rest kódolni, könnyen elkerülheted, hogy 15–20 bővítmény legyen az oldaladon telepítve. A [WordPress.org](https://wordpress.org/?ref=blog.fps.hu) folyamatosan aktív és jól használható portál, ahol azonnal foglalkoznak a bejelentett bugokkal és aktívan válaszolnak a feltett kérdésekre. Az sem elhanyagolható, hogy remekül felépített dokumentációval rendelkezik, ami minden fejlesztőnek kötelezően ajánlott kiindulópont.

### Hákolt oldalak

Ugyan a fentebb kifejtettek is fontosak, mégis talán a WordPress-szel kapcsolatos ellenérzések fő kiváltó okának azt tartom, hogy sokan az alapján ítélik meg, milyen oldalakkal találkoztak, melyek WP alatt futnak. Saját tapasztalatom is az, hogy nagyon könnyű olyan WordPress alapú oldalba futni, amin látszik, hogy a készítője nem igazán tudta, mit is csinált. Sok helyen úgy is reklámozzák a motort, amit használva programozás nélkül és minimális befektetéssel lehet saját weboldalt csinálni.

És a recept működik is: Letöltöd a telepítőcsomagot, installálod egy tárhelyre, keresel egy tetszetős sablont (akár fizetőset), aktiválod (sokszor mellé a demó tartalmat is, hogy lásd, mit tud), az oldalak tartalmát módosítod a WYSIWYG szerkesztőben és kész is az alap. Ha valami extra funkció kell, guglizol, az első találatban említett bővítményt feltelepíted és ezzel meg is van oldva.

Tudom, ez így nagyon nyersen hangzik, de meg vagyok róla győződve, hogy nem egy esetben ez történik. És mi ennek a következménye? Irreleváns tartalmak belezsúfolva egy sablonba, ami amúgy teljesen másra lett kitalálva, feleslegesen feltelepített bővítmények által lelassított oldalak, elmaradt beállítások sokasága, ami által pár hónapon belül ellepik az oldal tartalmát az oda nem illő linkek. Ezek összessége pedig növeli az elégedetlen ügyfelek, a megtámadott oldalak és nem utolsó sorban a szkeptikusok számát, akik joggal jelenthetik ki, hogy egy újabb félresikerült oldalba botlottak, ami WordPress-t használ.

### Konklúzió

A WordPress egy eszköz, a sok közül. Egy remekül kitalált és megvalósított rendszer, ami sokrétű felhasználást tesz lehetővé. Az, hogy mire és hogyan használod, csakis tőled függ. Butaság lenne csak ebben gondolkozni, hiszen nem mindenre alkalmas.  
Érdemes megemlíteni a pozitív [példákat](https://vip.wordpress.com/clients/?ref=blog.fps.hu) is, hiszen nem véletlenül választotta a [TED](http://ideas.ted.com/?ref=blog.fps.hu), a [TechCrunch](https://techcrunch.com/?ref=blog.fps.hu) vagy akár a [Smashing Magazine](https://www.smashingmagazine.com/?ref=blog.fps.hu) ezt a technológiát.

> Ha egyetlen szerszámod a kalapács, akkor hajlandó vagy minden problémát szögnek látni.  
> – Abraham Maslow

Bármilyen eszközt is alkalmazol, egy jó site létrehozásához elengedhetetlen több szakember együttműködése és a motor, CMS kérdése ennek a folyamatnak egy kis, ámde fontos szelete.
### Vizualitás
URL: https://blog.fps.hu/vizualitas/
Last updated: 2026-07-17T08:32:32.000Z
Nem tudom, hogy vagy vele, de nekem eddigi pályafutásom alatt még sosem sikerült olyan emailt írni, amit a másik fél úgy értett meg, ahogy azt jómagam gondoltam. Pedig már több mint 20 éve próbálkozom. Hányszor, de hányszor fordult már elő, hogy megbeszéltünk valamit szóban és sok-sok félreértés, neadjisten idegesség után döbbentünk rá, hogy valójában nem is ugyanarról beszélünk. A chatről már nem is beszélve, a metakommunikáció teljes hiánya (ja persze emotikonok, de nem) komoly egymás melletti elbeszélést okoz(hat).

Akkor most nézd meg a képet, ami egyébként a nagyszerű [User Story Mapping](https://www.safaribooksonline.com/library/view/user-story-mapping/9781491904893/pr06.html?ref=blog.fps.hu) c. könyben szerepel, mely Jeff Patton és Luke Barrett munkája. Gyakorlatilag mindent elmesél, amit mondani szeretnék. Röviden:

> Vizualitás a közös platform.  
> – [kolboid](https://twitter.com/kolboid/status/737987005691375616?ref=blog.fps.hu)

Ennyi.

Egyébként az ember a külvilágból származó információk mintegy 60–80 százalékát látása révén érzékeli, az **emberi agy 40%-a kizárólag a látással foglalkozik**. Nem véletlen.

Azaz mindig rajzoljatok, táblára, papírra, bárhova. Számtalanszor bebizonyosodott már, hogy mennyire hatékonyan működik. Nem kell hozzá rajztehetség: egyszerű négyzetek, téglalapok, körök, vonalak, nyilak, feliratok. Hamar kialakul a közös megértés és rengeteg felesleges stressztől kímél meg mindenkit. A rajzolás segít abban, hogy az összefüggéseket mutassa meg és ne vesszetek el a részletekben. A képernyőn mutogatás is többet ér, mint 100 oldal leírt és „tökéletesre” fogalmazott szöveg.

Végére a legfontosabb: **a vizualitás támogatja, hogy könnyen közös álláspontra jussatok**.
### Kapcsolódás API-khoz Android platformon
URL: https://blog.fps.hu/android-halozat/
Last updated: 2026-07-17T08:32:42.000Z
Az API-hoz való kapcsolódás egyik lényeges eleme a mai mobil appoknak. Több könyvtár közül is választhatsz, majd implementálnod, optimalizálnod és tesztelned kell. Összefoglaltam milyen lehetőségek vannak és mire érdemes figyelni.

### Mit szeretnék az API-tól?

Nem csak a backendet fejlesztő kollégának kell tudni, mi kell egy jó API-hoz, hanem a mobilfejlesztőnek is. Javaslatot, visszajelzést kell tudni adni az API készítése és használata közben. Egy mobil platform nem tudja nyújtani ugyanazt a teljesítményt, mint egy asztali. Nem csak a processzor, memória és az akkumulátor korlátozott, hanem maga a hálózat is az. Mivel állandóan mozgásban vagyunk, a hálózat is változik körülöttünk. 2G, 3G, 4G, LTE és WiFi között ugrálunk. Sajnos maga a kapcsolat típusa sem garantálja a hálózat sebességét. Ha egy buszmegállóba éppen beálló buszról mindenki az ott elérhető ingyenes WiFi-re ráugrik az elérhetetlen lesz. Ráadásul magáért az adatforgalomért is fizetni kell.  
Ennek tudatában kell az API-t és az appot megalkotni, megtervezni.

#### 1 lekérés képernyőként

Erre kell törekedni, azaz a felhasználói felületből kell kiindulni fejlesztéskor. Cél, hogy azokat az adatokat, amiket lát a felhasználó egyetlen lekérésből el tudd érni.

![Képzeletbeli Karcsi kedvenc boltjainak listája egy felületen](http://i.imgur.com/KgCaqf9.png)

A fenti felületen több mint 10 lekérést kell indítani a legrosszabb esetben, hogy Karcsi felhasználód kedvenc boltjait lekérd. Hiszen minden képet le kell szedned, a felhasználó nevét, a kedvenc bolt listát és annak elemeit.

#### Paraméterezhetőség

Ha a válaszban olyan mezők is vannak, amit nem használsz fel, akkor azok nem csak az adatforgalmat növelik, de a feldolgozást is lassítják. A legjobb az, ha valamilyen módszerrel leszűkítheted a visszakapott eredményt. Például url paraméterezéssel:  
*[https://api.hu/bolt/azonosíto?mezok=nev,kedvencek\_szama,kep](https://api.hu/bolt/azonos%C3%ADto?mezok=nev,kedvencek%5Fszama,kep&ref=blog.fps.hu)*

#### Denormalizálás

Ha egy válasz csak újabb lekéréssel értelmezhető, az baj. A fenti kedvencek bolt lista rosszabb esetben csak azonosító listát ad vissza:

```json

{
  "bolt_azonositok" : [1234, 5432, 54325, 532, 54324]
}

```

Ebben az esetben neked kell a szerver adatbázisának tábláit összecsatolnod, ami a legrosszabb megoldás. Helyette az API-nak kellene értelmezhető adatokat visszaadnia.

```json

[
  {
    "id" : 1234,
    "nev" : "tesco",
    ...
]

```

Ilyenkor már is megspóroltál egy hívást.

### Könyvtárak

Amint megvan az API, eldöntheted, melyik könyvtárat használod hozzá. Ehhez tisztában kell lenned azzal, hogy milyen API hívások lesznek. Nem minden könyvtárban érhető el minden hívás vagy egyszerűen azok hibásak. Ilyen például fájlfeltöltés vagy a nagyobb méretű fájlok letöltése.

Alapvetően 2 lehetőség van, majd ezen belül lehet válogatni:

- Alacsony szintű HTTP kliensek:
- Apache HttpClient
- HttpUrlConnection
- [OkHttp](http://square.github.io/okhttp?ref=blog.fps.hu)
- Magasabb szintű könyvtárak:
- [Volley](http://developer.android.com/training/volley/index.html?ref=blog.fps.hu)
- [Retrofit](http://square.github.io/retrofit/?ref=blog.fps.hu)

#### Alacsonyabb szintű kliensek

Az Apache klienst a Google eltávolította a 23-as API-ból és a HttpUrlConnection használatát javasolja 9+ API szint fölött. A HttpUrlConnection mint alternatíva nem valami kellemes. Egy hiba felbukkanása esetén valamilyen kerülő megoldást kell alkalmaznod, vagy várhatsz a következő verzióra. Egy külső könyvtárnál, mint az OkHttp, a hibák javítása és a funkciók gyorsan jönnek, ezért érdemesebb azt választani.

#### Magasabb szintű kliensek

Alacsonyabb szintű kliens használatával neked kell minden kivételt lekezelni és a választ is feldolgozni. Követni kell a jó öreg programozási szabályt:  
*Hagyd, hogy a munka nehezét más végezze el helyetted.*

##### Retrofit

A szerver végpontok metódusok, így ezeket könnyen használhatod a kódodban, melyeket egy interface annotálásával egyszerűen létrehozhatsz. Maga a Retrofit kezeli a szervertől kapott válasz átalakítását POJO osztályokká, ami még jobban megkönnyíti a dolgodat. Rengetegen használják így, van is dokumentációja.

##### Volley

A Google által létrehozott Volley-val kicsit több dolgod van. Csak pár előre megírt választípus van, és ezek létrehozásával indul a kérés. Például, ha XML-t szeretnél használni, akkor ennek kezelését neked kell megírni. Dokumentáció nem valami sok, inkább a Stackoverflow és maga a forráskód, amelyekre támaszkodhatsz. Hátrányai ellenére több funkciót tartalmaz, például beépített támogatás van a prioritást beállítani, és újrapróbálni a lekérést akár exponenciális visszalépéssel.

### Implementáció

Itt két dolgot emelek ki, amire figyelni kell. Az egyik a szálkezelés, ami kicsit rafinált dolog Androidon. A másik pedig a lekérések optimalizálása.

#### Szálkezelés

Az egyik legnehezebb dolog, főleg a konfiguráció váltások miatt. A másik szálon indított hívásodat eldobhatod, amint elfordul a kijelző, vagy rosszabb esetben behal az alkalmazás. Ennek megoldására a hívás eredményét cachelni kell, vagy a konfiguráció váltást kell megfelelően lekezelni.

A leggyakrabban használt osztály az AsyncTask. Itt neked kell lekezelni azt az esetet, amikor eltűnik a felület, miközben fut a hívás. Azt is neked kell kezelni, ha meg akarod szakítani ennek a szálnak a futtatását.

[RxJava](https://github.com/ReactiveX/RxJava?ref=blog.fps.hu) is használhatsz, ahol a fel- és leiratkozás elintézi a megváltozó UI problémáját. Ennek a libnek az elsajátítása sajnos nem egyszerű, így többfős csapatban a munkát is megnehezítheti. Szerencsére mára már sok dokumentációt, blog posztot találhatsz róla.

Bármilyen megoldást is használsz, külön szál létrehozásánál mindig figyelj, hogy UI elemeket az ne tartalmazzon. Amennyiben mégis így teszel, a teljes felhasználói felület a memóriában maradhat, miközben a felhasználó már mást lát.

#### Optimalizáció

Nem szabad elfelejteni, hogy az API hívásokat is lehet optimalizálni. A hálózati hívások alkalmával, a hálózattal foglalkozó hardver feléled, majd elküldi a kérést. Ez után megvárja a választ, és még utána 20, vagy akár 60 másodpercig is bekapcsolva marad, fogyasztva az akkumulátort. Ez az egyik legtöbb akkumulátort használó elem a mobiltelefonban.

#### Batching

Amennyiben a várakozási időszakban újabb kérést indítasz, az egész ciklus újraindul. A megoldás, hogy több hívást egyszerre indíts el.

A kulcs ehhez, hogy különbséget tudj tenni azok között a dolgok között, melyeknek most kell történnie és melyeknek elég később. A szerver felé küldött adatok a későbbi kategóriába tartoznak. Nem kell a szervernek azonnal értesülnie arról, hogy valaki kedvencnek jelölt valamit a felületen.

Ezeket a hívásokat külső könyvtárak segítségével könnyen kezelheted:

- [android-job](https://github.com/evernote/android-job?ref=blog.fps.hu)
- [GcmNetworkManager](https://developers.google.com/cloud-messaging/network-manager?ref=blog.fps.hu) (Firebase JobDispatcher)
- JobScheduler (api 21+)

A GcmNetworkManager-hez Google Play Services szükséges, és nem biztos, hogy fel van telepítve, vagy a legfrissebb található a felhasználó telefonján. Ez 21-es API-tól a JobSchedulert használja.

#### Polling

Időnkénti frissítéseket is ki lehet váltani például push használatával. Nem kell 2 percenként kérdezgetni a szervert, hogy van frissítés. Jobb, ha a szerver értesít a változásról. Ha egy ilyen megoldás nem jöhet szóba, ravaszabb is lehetsz a frissítéssel kapcsolatban. Google API segítségével detektálhatod például, hogy éppen milyen tevékenységet végez a felhasználó és eltolhatod a frissítést. Futás közben biztos nem fogja olvasgatni a telefonját. Ha viszont rárakta a töltőre, bátrabban kérdezheted meg a szervert.

### Tesztelés

Tesztelés az egyik legfontosabb dolog hálózat hívásoknál (is). Éles szerveren a legtöbb hibát nem tudod előidézni, így nehéz felkészíteni az alkalmazást az esetleges hibákra. Összetettebb kód esetében több ponton is hibába eshetsz, érdemes tehát valamilyen jó rendszert alkotni.

Egy hívás esetén ezek a főbb pontok:

1. Kapcsolódás a hálózathoz
2. Kapcsolódás a szerverhez
3. Megkapod a választ
4. Válasz feldolgozása

Ennek megfelelően kell tesztelni:

1. Nincs hálózat
2. Nem elérhető a szerver
3. Hibás válasz jön vissza
4. Hiba történik a válasz feldolgozása közben

Retrofit esetén könnyű unit és integrációs teszteket csinálni. Használhatsz egy előre megírt Mock osztályt, aminek megadhatsz választ, HTTP kódot, késleltetést és egyéb hasznos dolgokat.

Volley esetében ez nehezebb. Vannak mock osztályok, amiket a [gitről](https://android.googlesource.com/platform/frameworks/volley/+/2afdd91aba3a7a5396fe96dfe8f930661e56ea9a/tests/src/com/android/volley/mock/?ref=blog.fps.hu) kell összeszedni és kibogarászni.

Összetettebb API-kra a [WireMock](http://wiremock.org/?ref=blog.fps.hu) nevű eszközre vess egy pillantást. Ez tényleges szervert, HTTP szervert hoz létre, ami a kéréseidre adja majd vissza a válaszokat. Olyan hasznos funkciója is van, mint a kérések rögzítése. Curl parancsok eredményeit el tudja tárolni, majd ez alapján válaszol. Mivel külön könyvtárat kell behúzni hozzá és még saját szervert is indít, ezért még nem használtam.

A hálózati hívások debuggolásához proxy szervert is használhatsz. [Charles Proxy](https://www.charlesproxy.com/?ref=blog.fps.hu), [Fiddler](http://www.telerik.com/fiddler?ref=blog.fps.hu) és [mitmproxy](https://mitmproxy.org/?ref=blog.fps.hu) a legnépszerűbbek.

Erről beszéltem az ITrend meetupon, melynek diái:
### Androidos újdonságok a Google I/O 2016-on
URL: https://blog.fps.hu/android-google-i-o-2016-ujdonsagok/
Last updated: 2026-07-17T08:32:51.000Z
Május 18\. és 20\. között megtartották a 2016-os Google I/O-t. Vetek egy pillantást a legújabb Androidos újdonságokra fejlesztői szemmel.

### Android N

Még ezen az éven jön a legújabb Android verzió. A csapat egy [elnevezési játékot](https://www.android.com/versions/name-n/?ref=blog.fps.hu) is elindított mivel nehezen találnak N-el kezdődő fincsi süti nevet.  
Nekünk fejlesztőknek sokkal fontosabb, hogy mik is azok az újdonságok, amikre fel kell készülnünk.

#### Multi-Window

![alt](http://i.imgur.com/HQcH4b5.png)

A felület felosztható lesz két részre, ezáltal még nagyobb fókuszt kap majd egy reszponzív felület tervezése. Még ha a telefon fekvő nézetben van, akkor is álló nézetben lehet majd az applikációd, vagy pont fordítva. Az orientáció tulajdonképpen nem arra vonatkozik, hogy a telefon milyen helyzetben van. Ha az app szélessége kisebb, mint a magassága, akkor állóban, ha nagyobb, akkor fekvőben van.

Amennyiben a cél API-d az N verzió, a multi-window nem fogja figyelembe venni a manifestből kikényszerített orientációkat. Régebbi cél API-k esetén, ha a manifestben kikényszerítettél egy orientációt, akkor nem is lesz ez a funkció elérhető. Sajnos, ha a kódodban *setRequestedOrientation()* hívást használtad annak nem lesz hatása erre a funkcióra és engedélyezve lesz.

3 módja van:

- split screen: osztott képernyő
- freeform: szabadon átméretezhető
- picture-in-picture: TV-n elérhető kép a képben funkció

Több részletet megtudhatsz a [prezentációból](https://youtu.be/yEEy%5F48hoXI?list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&ref=blog.fps.hu) és az [Android dev portálon](https://developer.android.com/preview/features/multi-window.html?ref=blog.fps.hu)

#### Értesítések

Áttervezték az értesítések kinézetét és viselkedését. Szerencsére *NotificationAppCompat* használatával visszafelé kompatibilis lesz minden.  
Jónak ígérkező új funkció az a közvetlen válasz lehetősége az értesítésekből.  
19-es API-tól lekérdezheted azt is hogy engedélyezve vannak-e az értesítések. Eddig, ha a beállításodban be volt kapcsolva, de a felhasználó mégsem kapta meg őket akkor nem tehettél semmit. Most már megjeleníthetsz egy figyelmeztetést, hogy kikapcsolta őket a beállításokban.

Az újdonságokról többet megtudhatsz a [prezentációból](https://youtu.be/6eFQbC5r17w?list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&ref=blog.fps.hu) vagy a [dev portálon](https://developer.android.com/preview/features/notification-updates.html?ref=blog.fps.hu).

#### Képernyő méret

A készülék beállításai között egy új funkció érhető el, amivel megváltoztatható a készülék dpi-je. Ez azzal jár, hogy minden felületi elem átméreteződik. Nagyjából 0.85 és 1.5 szeres szorzó között lehet állítani.

### Play Store Chrome OS-en

Egy éve már lehetett sejteni, hogy nem csak mobilon és tableteken, hanem Chrome OS-en is elérhető lesz a play store. Ez azt jelenti, hogy alkalmazásaidat ott is futtatni tudják majd, mégpedig körülbelül szeptembertől. Sajnos nem minden működhet jól az appoddal ott.  
Nem minden Chrome OS készüléknek van érintős kijelzője, viszont az androidos appok ezt alapból követelik. Hogy ezeken a készülékeken is elérhető legyen, az alábbi sort be kell rakni a manifestbe:

```xml

<uses-feature android:name="android.hardware.touchscreen" android:required="false"/>

```

Ekkor egeret és billentyűzetet használó készülékeken is megjelenik majd az appod.  
Továbbá 3 méretben lehet majd az alkalmazásokat használni. Az ezek közötti átmenet konfiguráció váltással fog történni. Mobilon, ha elfordul a kijelző a dpi-je ugyan az marad, a szélesség magasság pedig felcserélődik. Chrome OS-en mindhárom tulajdonság teljesen megváltozhat.

Jelenleg nagyjából az androidos készülékek 0.1% lehet Chrome OS. Ennek ellenére érdemes figyelemmel követni ezt a platformot is.

Többet megtudhatsz a [prezentációból](https://www.youtube.com/watch?v=ZLYzX0G0YKQ&list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&index=33&ref=blog.fps.hu).

### Support Library

Egy már várt változást is beharangoztak a v4-es support könyvtárral kapcsolatban. A 9-es api alatti támogatást elvetik és felbontják kisebb modulokra. Jelenleg a 23.2.0-ás verzió több mint 9000 metódusból áll. Ezzel könnyebb lesz karbantartaniuk és gyorsabban adhatnak ki új verziókat.

Az utóbbi verziók újdonságairól többet megtudhatsz a [prezentációban](https://www.youtube.com/watch?v=w45y%5Fw4skKs&ref=blog.fps.hu).  
A témák és stílusok használatáról is tartottak [előadást](https://www.youtube.com/watch?v=TIHXGwRTMWI&list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&index=21&ref=blog.fps.hu).

### Android Studio 2.2

Jön az újabb Studio. Javítottak a szerkesztőn és a tesztelésen.  
A preview verziót már eléred a [canary csatornán](http://tools.android.com/download/studio/canary/latest?ref=blog.fps.hu).

###### Layout szerkesztő

Végre elkészült az előző évben bemutatott design és preview ablak. Most már közvetlenül az előnézetben is lehet szerkeszteni a felületet az XML mellett. Egy új blueprint mód kerül hozzáadásra ahol a felület drótvázát láthatod. Design módban megtekintheted az elemek főbb és részletes tulajdonságait. Ami új, hogy ki lesznek töltve a mezők az alapértelmezett értékekkel és végre az olyan konténerek mint a ScrollView görgethetőek.  
Újdonság, hogy lehet a menu és a preferences elemeit is módosítani design módban.

###### Constraint Layout

Kiadtak egy új layoutot, ami első ránézésre nagyon hasonlít az IOS féle Auto Layouthoz. Nagyban épít az új szerkesztőre, ahol is folyamatosan láthatod mi az eredménye ez egyes elemek elhelyezésének. Maga a Constraint layout a layoutjaid laposítását teszi lehetővé, ezzel gyorsabb lesz a megjelenítés. Jelenlegi layoutjaidat is átalakíthatod, szóval érdemes lesz kipróbálni.

[Dokumentációt](http://tools.android.com/tech-docs/layout-editor?ref=blog.fps.hu) és [prezentációt](https://youtu.be/sO9aX87hq9c?list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&ref=blog.fps.hu) is találsz róla.

###### C/C++

Fejlesztettek a debuggoláson. Egyszerre lehet Java és C++ kódot debugolni. CMake támogatás is van már, ami egy népszerű build tool C++-hoz. Az NDK az egyik legelmaradottabb része a környezetnek, ráfér a fejlesztés.

Az NDK-ról szóló [prezentációt is megtekintheted](https://youtu.be/Ok97X9Z4Si8?list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&ref=blog.fps.hu).

###### Kisebb fejlesztések

- Példa kódra való keresés:  
A kontextus menüben elérhető opció az Google által létrehozott példákban keres a kijelölt osztályra.
- Új Lint ellenőrzések, például  
szól, ha statikusan akarunk Context típusú objektumot tárolni.
- Pár új Annotáció, köztük a  
*@Keep* annotációval megvédhetjük metódusunkat a Proguardtól.

###### Apk analyzer

Beépített eszköz lesz arra, hogy feltárd azokat erőforrásokat, amik a legtöbb helyet foglalják az APK fájlban. A metódusok számát is kiírja így könnyebben kizárhatod a felesleges könyvtárakat és a 65 ezres limit alá kerülhetsz.

###### Manifest merger

Vannak esetek amikor app futtatásakor derül ki, hogy olyan engedélyt is kér az applikációd, amiről te nem tudsz. Mostantól láthatod, melyik könyvtár milyen engedélyt hoz magával. Ezt az eszközt a manifest megtekintésekor éred majd el.

###### Tesztestek rögzítése

Fel lehet majd venni Espresso teszteket. Ez jelentősen leegyszerűsíti és megrövidíti majd a felület tesztelését. Ezeket a teszteket akár a Cloud Test Lab-en is el lehet indítani.  
Volt egy [prezentáció az Espresso használatáról is](https://youtu.be/isihPOY2vS4?list=PLWz5rJ2EKKc8jQTUYvIfqA9lMvSGQWtte&ref=blog.fps.hu).

### Play Service 9.0

Firebase nevű szolgáltatást és a Play Service-t olvasztották össze. Sajnos [át kellesz vinni](https://firebase.google.com/support/guides/google-android?ref=blog.fps.hu#migrate%5Fyour%5Fconsole%5Fproject) előbb utóbb a régi cuccokat ide.  
Van viszont pár új ígéretes, ingyenes funkció. Crash report, Analitika, Távoli konfiguráció és a Dynamic linknek nevezett szolgáltatásuk.

### Instant Apps

Telepítés nélküli appok volt az egyik nagy bejelentése a Googlenak a megnyitóban. Egy webes linkre kattintva nem az ahhoz tartó weboldal, hanem a hozzá tartó applikáció nyílik meg. Pontosabban az a része, amelyik azt a tartalmat mutatja, amit meg szeretnél nézni. Az appnak csak azt a részét töltöd le a Google szerveréről, amire szükség van.

Ez funkció a 16-os apitól lesz elérhető majd. Instant appal természetesen nem fogsz tudni hozzáférni az Android api egyes funkcióihoz. Például nem lehet background service-t sem indítani. Elkészítésükhöz nem kell majd szerencsére külön applikációt létrehozni csak a meglévőt felkészíteni rá.

Jelenleg pár fejlesztő bevonásával tesztelik amit folyamatosan bővítenek. Ha érdekel és szeretnél a teszteléshez hozzáférni, [jelentkezhetsz](https://developer.android.com/topic/instant-apps/index.html?ref=blog.fps.hu) az Android dev portálon.
### ThreeJS tapasztalataim
URL: https://blog.fps.hu/threejs-webgl-tapasztalatok/
Last updated: 2026-07-17T08:33:02.000Z
Talán 15 éve próbálkoztam először Turbo Pascal nyelven az axonometrikus ábrázolással. Kb. ennyiben ki is merült a kapcsolatom a 3D-s képalkotással, egészen addig, amíg kaptam egy érdekes feladatot. A projekt elején azt hittem, egy jó library mindenre megoldás, a végére rájöttem, hogy kellő tapasztalat nélkül elég kínkeserves is lehet a folyamat. Okulás gyanánt és akár kedvcsinálóként ajánlom mindenkinek az írásomat :)

### A brief

Kaptunk egy rövid brief-et egy esetleges projektről. A feladat egy egyszerű játék elkészítése, ahol forgó poháron lévő pöttyök eltűnnek, a játékosoknak pedig az a feladata, hogy a hiányzó területekre kattintva pótolják a pöttyöket. Ezáltal pontokat szereznek, és minden kattintáskor gyorsul a pohár forgása. Ha egy körön belül nem tudnak rákattintani a hiányzó részre, a játék véget ér.

### Three.js

A leírást elolvasva azonnal rávágtam, hogy kellemes projekt, új kihívásokkal és a three.js kell nekünk! A [three.js](http://threejs.org/?ref=blog.fps.hu) egy zseniális könyvtár, amivel relatíve egyszerűen lehet 3D-s környezeteket megjeleníteni (ahogy ők írják: "... for dummies"). További előnye, hogy webGL, Canvas, CSS3d és SVG renderelést is támogat. Korábban már ugyan próbálgattam a three.js lehetőségeit, így nem a nulláról indultam, de éles projektben még nem használtam.

### Az alapkoncepció

A fentieket elolvasva, mi sem egyszerűbb, mint megcsinálni a poharat. Két elemből össze is állítható: Egy körgyűrű (tórusz) adja a karimáját, egy nem szabályos henger pedig a testét. Ezeket textúráztam, létrehoztam pár kattintható felületet a megfelelő helyen és meg is voltam. Legalábbis ezt gondoltam az elején.

![a pohár](https://blog.fps.hu/content/images/2016/05/1.png)

### És akkor elkezdtem kódolni...

Maga a three.js környezet létrehozása viszonylag egyszerű feladat. Behúzod a libet, pár kiegészítőt (mivel le kell kezelni azt az esetet is, ha nincs webGL támogatás), definiálod az alapértékeket és kezdődhet is a móka. Egyébként számos [boilerplate](https://github.com/jeromeetienne/threejsboilerplate?ref=blog.fps.hu) és [generátor](https://jeromeetienne.github.io/threejsboilerplatebuilder/?ref=blog.fps.hu) elérhető erre a célra. A két geometriai elem létrehozása, méretezése és pozícionálása nem okozott nagyobb fejtörést, főleg, hogy a three.js kiváló [dokumentációval](http://threejs.org/docs/index.html?ref=blog.fps.hu#Reference/Extras.Geometries/TorusGeometry) rendelkezik. Kis játék a fényekkel és az anyagok színezésével, és elő is állt az alap.

#### Kell rá egy logó!

És el is érkeztem az első részhez, ami már kisebb fejtörést okozott. Mivel a logó maga is kattintható felület, úgy gondoltam, hogy külön geometriai elemként hozom létre azt, így könnyű lesz az interakciót és a láthatóságát lekezelni. Ez mind egyszerűen hangzik, de egy nem szabályos henger esetén már picit problémásabb. Mégsem oldhatom ugye meg egy egyszerű négyzettel, hiszen a felület, amire illeszteni akarom nem egyenes. Szerencsére a poharat felépítő háromszögek (face) koordinátáit könnyen meg lehet határozni, úgy gondoltam, célszerű azokból kiindulnom.

![a logó helye](https://blog.fps.hu/content/images/2016/05/2-1.png)

Örömmel konstatáltam, hogy az első felmerülő problémát rövid idő alatt meg is oldottam, egy újrafelhasználható függvény jött létre eredményeként, amit elő tudtam venni, ha a pohár testén kellett saját geometriai elemeket létrehoznom.  
Már csak textúrázni kell és teljes az öröm, van logó a poháron. Na igen, csak textúrázni…  
Előre definiált geometriai testek esetén nincs ezzel probléma, de ha egyedi elemet hozok létre már nem olyan egyszerű a helyzet. Néhány óra eredménytelen próbálkozás után kellett szembesülnöm azzal, hogy létezik az *UV map* fogalma:) Még szerencse, hogy hozzáértő kollégám a közelben volt és kisegített jótanácsaival. Ha Te sem ismered ezt a kifejezést, pár szóban annyi, hogy az UV map egy olyan mátrix, ami alapján a textúrát ráilleszted egy adott testre. Itt már előkerült a négyjegyű függvénytáblázat is és gyorsan fel kellett frissítenem trigonometriai ismereteimet. Mennyivel egyszerűbb lett volna, ha egy kocka alakú dobozt kell lemodellezni…

#### Pöttyözd be!

Az egész lényege, hogy dinamikusan eltüntethető pöttyök legyenek a poháron, így ez a rész korántsem elhanyagolható. Mielőtt bármit is csináltam volna, két lehetséges megoldás is az eszembe jutott:

1. A pöttyözés szabályosságát szem előtt tartva, textúrával oldom meg és mindig eltakarok egyet
2. Minden pöttyöt egyéni geometriai elemként viszek fel, amik közül egyet mindig eltűntetek

![az egyes pöttyök eltakarása](https://blog.fps.hu/content/images/2016/05/3.png)

A logó kialakításakor szerzett tapasztalatok alapján jobbnak láttam, ha a számomra egyszerűbb, első verziót választom. Maga a pöttyös textúra ráhúzása a pohárra nem volt túl bonyolult, mivel „előre definiált” geometriai test, nem kellett bajlódnom az uv map generálásával, csupán a textúra megfelelő vágásával, hogy ismételhető legyen.

Felesleges lett volna minden pöttyhöz elkészíteni az azt takaró elemet, ezért csak a játékélmény biztosításához szükséges helyeken tettem ezt meg. Ismét a pohár testét felépítő háromszögekből indultam ki, hiszen a fehér poháron egy fehér takaróelem esetén elhanyagolható annak a körvonala, a lényeg, hogy a pötty ne látszódjon. Miután megcsináltam 8–10 ilyen testet, már rendelkezésre is álltak a játékhoz szükséges elemek.

#### Interaktivitás

Az már az kattintások lekezelésének bekötésekor kiderült, hogy mobilon nem lesz elég ha csak egy „pöttynyi” részre lehet tappolni, így minden takaró elemhez létrehoztam egy másik, nagyobb felületű elemet, ami átlátszó volt és a click/touch esemény ahhoz volt kötve.

![interaktív felületek](https://blog.fps.hu/content/images/2016/05/4.png)

A másik érdekesség, amit mindenképpen ki szeretnék emelni, a kattintható felületek viselkedése volt. Az utolsó pillanatig küzdöttem a problémával, hogy a pohár közepétől felfelé elhelyezkedő felületek esetén minden interakciót gond nélkül érzékeltem, a közepétől lefelé viszont már alig-alig sikerült úgy rákattintani egy pöttyre, hogy azt a script is érzékelje. Majdhogynem egy véletlen folytán jöttem rá a megoldásra, amikor a kamerát és a test elhelyezkedését módosítottam. Nem is gondoltam volna, hogy ennyit számít az a minimális eltérés és a pohár ferde vonala, de a középvonal alatti interaktív elemek „kifelé forgatásával” megoldódott ez a probléma is. Erről a problémáról [itt olvashatsz](https://soledadpenades.com/articles/three-js-tutorials/object-picking/?ref=blog.fps.hu) egy részletesebb leírást.

### Mindent összerakva

Íme fenti dolgok egy leegyszerűsített változata, hogy ne csak képeket linkeljek.

See the Pen [three.js cup](http://codepen.io/totya24/pen/KMKOMP/?ref=blog.fps.hu) by Zoltan Toth ([@totya24](http://codepen.io/totya24?ref=blog.fps.hu)) on [CodePen](http://codepen.io/?ref=blog.fps.hu).

  
### Konklúzió

Nem mondom, hogy ha újra el kellene kezdenem, ugyanígy csinálnám, mindenesetre a dolog működik. Azt egyértelműen leszűrtem a projekt kapcsán, hogy ez egy elég mély és bonyolult része a fejlesztésnek, sokat kell matekolni és a hatékony és elegáns megoldásokhoz elengedhetetlen a megfelelő elméleti tudás. De egy újabb sor a TODO listámon, hogy ne hagyjam ennyiben a témát, mert kifejezetten jó móka és [csudajó dolgokat](http://codepen.io/Yakudoo/full/YXxmYR/?ref=blog.fps.hu) lehet összehozni. Megemlíteném, hogy sokat segít a helyzeten, ha van körülötted egy a témában jártas szakember, mert olyan speciális helyzetekkel is találkozhatsz, amikre nem egyszerű megoldást találni a netet böngészve.

Ha sikerült felkeltenem az érdeklődéset, annak csak örülök. Biztos vagyok benne, hogy vannak szebb és jobb megoldások a fenti problémára, ha tudsz ilyet, szívesen várom kommentben. Egyébiránt [itt tudod kipróbálni](https://pottyozz.mcdonalds.hu/?ref=blog.fps.hu) a végeredményt.
### Titkosíts!
URL: https://blog.fps.hu/ingyenes-ssl-tanusitvany/
Last updated: 2026-07-17T08:33:10.000Z
Az utóbbi időben reflektorfénybe kerülő megfigyelési és lehallgatási botrányok nyomán egyre inkább terjed az a nézet, hogy titkosítani kell mindent. Legtöbbször az derül ki, hogy olyan mintha a különböző titkosszolgálati szerveknek korlátlan hatalmuk lenne, és az olyan nagy cégek, mint a Google vagy az Apple is áldozatul tudnak esni lehallgatásoknak. Másrészt a technológia fejlődésével és térnyerésével egyre nagyobb erőforrás és eszközpark áll a különböző hackerek kezében, hogy személyes adatainkat megszerezzék. Főként igaz ez olyan oldalakon, ahol érzékeny adatokat is adunk meg, mint pl. bankkártyaszámot.

Erre a problémára nyújt megoldást a webszerverekbe építhető SSL tanúsítvány. Az alap http protokoll alapvetően titkosítás nélkül, plain-text formában küldi és fogadja az adatokat. Ennek a titkosított verziója a https protokoll, ahol magát a kommunikációs csatornát titkosítjuk a tanúsítványokkal, melyekben legalább egy 2048 bit hosszú kulcspár és a tanúsítvány egyéb adatai pl. aláírója és kibocsájtója biztosítja a kommunikáció megbízhatóságát és nehezített lehallgatását. Nem utolsó sorban a Google is szereti a titkosított weblapokat, keresési találatban előrébb helyezi az tanúsítvánnyal rendelkező honlapokat. Általában ezért a különböző tanúsítványkibocsájtó cégek elég tetemes, akár több száz dollárt is elkérhetnek, cserébe biztosítás jár melléjük.

### Let's Encrypt

Ez a kérdéskör vezette az [Internet Security Research Group](https://letsencrypt.org/isrg/?ref=blog.fps.hu "ISRG") (ISRG) non-profit szervezetet, hogy létrehozza a [Let's Encrypt](https://letsencrypt.org/about/?ref=blog.fps.hu "Let's Encrypt") projektet, jó pár nagy és neves IT cég szponzorálásában. Az ISRG célja, hogy ledöntse a technikai, pénzügyi, oktatásbeli akadályokat, melyek nehezítik a biztonságos kommunikációt az interneten. Ennek az eszmének teljes mértékben megfelel a Let's Encrypt projekt, melynek célja, hogy nyílt, a közösség által épített rendszeren keresztül bárki számára ingyenes tanúsítványokat állítson ki, és azok bárki számára visszaellenőrizhetőek legyenek.

Az fps-nél már egy bő hónapja használunk ilyen SSL certificate-eket, egy két helyen már éles körülmények között is. A rendszer 2016\. április 12-én lépett ki a béta státuszból, így már lehet használni production környezetben is. Annak ellenére, hogy új tanúsítványkibocsájtók, jó [kompatibilitási](https://community.letsencrypt.org/t/which-browsers-and-operating-systems-support-lets-encrypt/4394?ref=blog.fps.hu "Kompatibilitási lista") tulajdonságokkal rendelkeznek, gyakorlatilag mindenféle platform és böngésző támogatja, amit az elmúlt 5-6 évben adtak ki.

Két nagy előnye van a rendszernek az egyéb ingyenes tanúsítványkibocsájtókkal szemben. Egyrészt mindenféle komolyabb regisztrációs folyamat nélkül lehet igényelni, másrészt a certificate-ek igénylésére, megújítására, visszavonására kész [programot](https://github.com/certbot/certbot/wiki/Links?ref=blog.fps.hu "Programok"), [Certbot](https://certbot.eff.org/?ref=blog.fps.hu "Certbot"), biztosít az ISRG. A program szabadon letölthető GitHubról.

Van azonban néhány korlátozása a rendszernek. Egyrészt csak domain alapú rendszerekhez, tipikusan web és levelezőszerverekhez használhatóak a kiállított tanúsítványok, másrészt a kiállított tanúsítványok mindössze 90 napra szólnak, ezzel biztosítva, hogy ha még is ellopnak egy kulcsot, vagy az sérül, hamar inaktívvá válik különösebb beavatkozás nélkül. Fontos szem előtt tartani, hogy nincs wildcard certificate kiállítás, nem korlátlanul kapunk tanúsítványokat, viszont enged összefűzni 100 darab domaint egyetlen certificate alá.

A Certbot, ami kezeli a megújításokat, alapvetően Linux és Unix alapú operációs rendszerekkel működik együtt, és az azokon fellelhető webszervekkel. A tanúsítványok kezeléséhez az [ACME](https://github.com/letsencrypt/acme-spec?ref=blog.fps.hu "ACME") protokolt használja. Alapesetben egy saját webszervert indít a program a szabvány 80-as porton, amin keresztül megy a domain validálás, ám ez nem járható út egy éles rendszeren.

Éles rendszereknél az Apache webszervert támogatja stabilan, de készül az NginX támogatás is, ami még nem stabil. Egyéb webszerver esetén létezik egy webroot funkció, melyet megadva a validációs fájlt a program egy megadott könyvtárban helyezi el, és ezt ellenőrzi vissza a rendszer.

### Hogyan automatizáld a megújítást?

NginX esetén lehet egy ügyes, pár soros kis include-ot csinálni, melyet akármelyik server definícióba betöltve ki lehet szolgálni az összes ilyen domain validációs kérést:

```nginx

location ~ /.well-known {
   allow all;
   root /var/www/letsencrypt;
}

```

Így a következő paranccsal tudsz tanúsítványt igényelni:

```bash

certbot-auto certonly -a webroot --webroot-path=/var/www/letsencrypt/ -d example.com -d www.example.com -d example.hu -d www.example.hu

```

A *certbot-auto renew* paranccsal meg az összes, a szerveren létrehozott Let's Encrypt tanúsítványt lehet megújítja. Figyelni kell azonban, hogy lejárat előtt maximum 30 nappal korábban lehet megújítani, így célszerű a cron folyamatot úgy időzíteni, hogy kb. 15 naponta fusson le, nehogy kicsússz az érvényességi időből.

Ezt követően már csak egy sima SSL server, vagy vhost blokkot kell csinálni, mint bármilyen más esetben, és működik is a friss ingyenes tanúsítványod, pl így:

```nginx

server {
        listen 443;
        server_name www.example.com;

        ssl on;
        ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_dhparam /etc/nginx/dhparam.pem;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_stapling on;
        ssl_stapling_verify on;
        add_header Strict-Transport-Security "max-age=15768000;";
        add_header X-Content-Type-Options nosniff;
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;

        root /var/www/html;
}

```
### Android Architektúrák – MVP
URL: https://blog.fps.hu/android-architecturak-mvp/
Last updated: 2026-07-17T08:33:19.000Z
Az Android platformon nincs semmiféle irányelv előírva, mit is illene tervezési mintaként használni. Így az utóbbi időben különféle megoldások bukkannak fel, mint például a Flux, MVVM, MVP. Ezek közül talán a legnépszerűbb az MVP.

### Mi az MVP?

Egy jól strukturált kódban arra kell törekedni, hogy különböző, elhatárolt rétegekre osszuk fel azt. Ilyen réteg lehet a felület, adatbázis, vagy a hálózati kommunikáció kezelője.  
Az MVP az MV\* csoporthoz tartozó UI tervezési minták egyik variánsa. Ezek segítenek az interfész kódját elválasztani a logikától, így elősegítik a [szerepkörök szétválasztását](https://en.wikipedia.org/wiki/Separation%5Fof%5Fconcerns?ref=blog.fps.hu).

#### Model

Az adat, amit meg fog jeleníteni a felület.

#### View

A felhasználói interface, ami megjeleníti az adatot (model), és továbbítja az eseményeket a presenternek. Általában egy Activity osztály tölti be ezt a szerepet.

#### Presenter

A közvetítő szerepét játssza a model és a felület kötött. Ez dönti el, mi történjen, amikor a felhasználó kapcsolatot teremt a felülettel.

![Model View Presenter diagram](https://blog.fps.hu/content/images/2016/04/fpsblog_kep2.png)

### Miért kell ez neked?

Androidon a probléma abból adódik, hogy az olyan osztályok, mint az Activity, szorosan kötődnek mind a UI-hoz, mind pedig az adatok betöltéséhez. Ez azt okozza, hogy keveredik a felület kódja, az egyébként máshova tartozó kóddal, ugyanazon osztályban.  
Egy nagyobb feladat is kisebb részekre bontva, könnyebben megoldható. Ezt alkalmazva, amennyiben szétválasztod a kódokat különböző rétegekre, máris egyszerűbb lesz:

- Tesztelhetőbb, mert minden osztálynak a többitől elhatárolt feladata van.
- Könnyebb karbantartani, mert az osztályokban egy kódrész módosítása, jobban látható befolyással van más egységekre. A jobb tesztelhetőség, pedig lehetőséget ad a gyorsabb javításra.

### Hogyan kell használni?

Egyszerűen tudod saját magad implementálni. A view osztályoknak egy interfészt kell implementálniuk. Ezen keresztül fog a presenter majd kommunikálni velük. A presenter osztályt is a viewban érdemes először feltölteni.

```java

public class ExampleViewImpl implements IExampleView {

    private IExamplePresenter presenter;
   
    private void initPresenter(){
        presenter = new ExamplePresenterImpl(this);
    }

}

```

A viewnak butának kell lennie, és csak a megjelenítéssel foglalkoznia. Minden eseményt, ami történik, továbbít a presenternek hogy az cselekedni tudjon. Nem szabad elfelejteni, hogy a view-t a felhasználó irányítja, nem pedig a presenter!

A presenter osztályodnak ugyanígy egy interfészt kell implementálnia. Ezen keresztül fog a view kommunikálni vele.

```java

public class ExamplePresenterImpl implements IExamplePresenter {

    private final IExampleView view;
   
    public ExamplePresenterImpl(IExampleView view){
        this.view = view;
    }

}

```

A presenternek nem szabad tudni semmilyen Androidos elemről, mert nem feladata ezekkel dolgozni. Presentere nem csak Activitynek és Fragmentnek lehet, hanem olyan felületi elemeknek is, mint egy TextView. Ennek ellenére egy presenter kezelhet több view-t is. Ha egy regisztráció több képernyőre fel van osztva, akkor elég lehet egy presenter hozzájuk.

Az implementált interfészek leginkább tesztesetek írásánál jönnek jól. Például létrehozhatsz egy saját view-t a presenterednek, hogy minden hívást, minden paraméterrel tesztelhess.

```java

IExampleView mockView = new MockExampleView();
IExamplePresenter testPresenter = new ExamplePresenterImpl(mockView);

```

Egyik nagy problémája az MVP-nek Androidon, a presenter megőrzése konfiguráció váltás esetén. Például amikor fekvő és álló felület között váltasz, akkor a jelenlegi Activity helyett egy új jön létre. Ekkor ugyanazt a presentert kellene visszacsatolni, megőrizve például a másik szálon indított folyamatokat.

Erre több megoldás is van. Pár példa:

- Singleton presenter
- Kitalálni az *onSaveInstanceState(Bundle)* és az *onDestroy()* metódusokból, hogy mikor lesz konfigváltás
- *setRetainInstance(true)* használata Fragmentek esetén
- Loader osztály használata
- Presenter osztályok cache-elése

Mindegyiknek van hátránya. Singleton esetén a presentered nem újra felhasználható, és *static* változó esetén az app élete végéig a memóriában marad. *setRetainInstance(true)* használata esetén a Fragmentre külön megkötések lesznek érvényesek.

#### Könyvtárak

Léteznek könyvtárak, amik segítenek implementálni az MVP-t. Ezek már megoldották a konfigurációváltás problémáját.

- [Mosby](http://hannesdorfmann.com/mosby/?ref=blog.fps.hu)
- [Nucleus](https://github.com/konmik/nucleus?ref=blog.fps.hu)

A Nucleus egy egyszerű lib. Egy rövid dokumentáció van, és példa kód. Itt a presenternek saját életciklusa van.

A Mosby egy jobban dokumentált könyvtár. A presenter megőrzését pedig egy [ViewState](http://hannesdorfmann.com/mosby/viewstate/?ref=blog.fps.hu) funkcióval végzi el.
### Kisvállalati fájl szerver házilag
URL: https://blog.fps.hu/kisvallalati-fajl-szerver-hazilag/
Last updated: 2026-07-17T08:33:28.000Z
A kisebb IT vállalatok a növekedés folytán, hamar eljutnak arra a szintre, hogy egynél több szerverre van szükségük. Különböző fejlesztői szerverekre, build szerverekre. Aztán a GitLab-nak se ártana egy szerver, legalább egy virtuális. Ezeken felül még valahol a cég egyéb adatait is tárolni kell.

Új, nagy szerverek beszerzésére nem mindig van lehetőség, viszont gyakran rendelkezésre áll néhány kisebb, régebbi szerver, melyek ugyan nem a legújabbak, de megfelelően működnek. Azon kívül, hogy bevásárolsz egy nagy szervert, ami tele van merevlemezekkel, néhány egyéb alternatíva is rendelkezésedre áll.

### NAS

Lehetőséged van beszerezni különböző gyártók kész NAS megoldásait, melybe igényeid szerint tehetsz különböző darabszámú és tárterületű HDD-ket. A jobbak (és értelemszerűen drágábbak) RAID kötetet is tudnak összeállítani a rendelkezésre álló merevlemezekből. Ettől függetlenül limitáltak a képességeik, saját operációs rendszerrel futnak, egyszóval meg van kötve a kezed.

Nagy előnyük, hogy dobozos megoldások, egyszerű webes felületen lehet őket kezelni. A főbb fájl megosztó és média szerver funkciókat biztosítják, túl nagy törődést nem igényelnek. Az okosabb operációs rendszerek automatikus biztonsági mentés funkcióval is fel vannak szerelve.

### Open Source

Másik lehetőség, amire igazából ki akartam térni a poszt kapcsán, hogy lehet Open Source alapokon is építkezni. Ez a változat nagyobb szabadságot, és adott esetben nagyobb teljesítményt is jelenthet a dobozos NAS megoldásokhoz képest. Hátránya, hogy nagyobb hozzáértést és parancssori gépelgetést igényelnek.

#### ZFS

Eredetileg a ZFS fájlrendszert a Sun Microsystems kezdte fejleszteni még 2001-ben. A Sun felvásárlását követően az Oracle nyílt forráskódúvá tette a rendszert 2005-ben. A fejlesztését 2010-ben fejezte be az Oracle. Ez az esemény hívta életre az OpenZFS projektet, mint forkot, mely a jelenlegi fejlesztéseket is koordinálja, és a különböző implementációkat fogja össze.

A ZFS egy fájlrendszer és egy logikai kötetkezelő egyben, számos hasznos funkcióval, mint tömörítés, deduplikáció, snapshot lehetőség, hatékony adatvédelem, öngyógyítás, RAID.

Egyetlen dologra kell csak figyelni használatakor. Ha van RAID kártya a szerverben, azt ki kell kapcsolni, mivel a fájlrendszer saját algoritmust használ az adatok tárolására és kezelésére, és a RAID kártya befolyásolja a hatékonyságát. A RAID működését is célszerű ZFS oldaláról megközelíteni. Saját megoldása, saját algoritmusa van erre a célra, ami hatékonyabb, mint pl. a RAID5.

A ZFS-t hatalmas tárkapacitásra tervezték, ízelítőül a számok:

- 281 billió darab fájl lehet egy könyvtárban
- 16 exabyte lehet egy fájl maximális mérete
- 256 zettabyte lehet egy kötet maximális mérete
- 18 trillió darab kötetet tud kezelni

A számokból is látszik, hogy a ZFS képességei bőven túlmutatnak egy kkv cég igényein, akár nagyvállalati környezetben is helyt áll(hat).

Számomra a leghasznosabb funkció, az a különböző szintű gyorsítótárazási megoldások. A ZFS segítségével könnyűszerrel építhetsz hibrid tárolókat. Vegyesen használhatod fájl tárolásra és gyorsítótárazásra a RAM-ot, az SSD-t, a hagyományos HDD-t. Mivel sok különböző logikai egység kezelésére képes, így különböző módokon lehet összeszervezni az azonos sebességű és elérésű háttértárolókat.

Hab a tortán, és ami miatt egy egész szervert kíván, hogy a gyakran használt adatokat elő tudja tölteni. Elsődlegesen az elérhető szabad RAM kapacitást használja erre a célra, de ha az betelt, a kevésbé használt adatokat automatikusan áthelyezi az erre a célra dedikált háttértárra. Erre a célra egy kicsi SSD megfelel, mely biztosítja a gyors elérést. Ennek az SSD-nek nem szükséges redundánsnak lennie, elhalálozás esetén egyedül teljesítménybeli hatása lehet.

Az írási folyamatok naplózását is célszerű külön háttértárra, két kicsi SSD-re kiszervezni. Ezeket viszont már ajánlott redundánsan rendszerezni, mivel ha az írási naplózás közben keletkezik a probléma, a ki nem írt adatok elvesznek.

Ezeket a meghajtókat (gyorsítótár, írási napló) a ZFS rendszer logikailag külön kezeli. Így szükség szerint lehet egyedileg hozzárendelni az egyes kötetekhez.

A különböző logikai kötetek az operációs rendszer oldaláról ugyanolyan könyvtárnak, partíciónak látszanak, mint bármelyik más fájlrendszer esetén. Így lehetőséged van arra, hogy továbbexportáld akár egy NFS szerver, vagy egy SAMBA szerver felé. Ezáltal akár Linuxos, akár Windowsos gépek is el tudják érni a megosztott kötetet.

### Megoldások

#### FreeNAS

A FreeNAS egy FreeBSD alapú operációs rendszer, amely alapértelmezetten ZFS fájlrendszert használ, és a NAS egyszerű kezelhetőségét ötvözi az egyedi megoldások használatával.

#### ZFS on Linux

A ZFS Linux implementációja. A projekt a Linux kernelhez szükséges modulokat tartalmazza. Számos Linux disztribúció számára elérhető csomag formájában, elősegítve a könnyű telepítést.

Linux használata esetén megvan az a lehetőség, hogy könnyebben lehet a szerver számára egyéb, kis erőforrást igénylő funkciókat adni a fájlszerver mellett. Ilyen pl. egy másodlagos belső névszerver.

Az fps-nél mi is a ZFS on Linux implementációt használjuk egy CentOS 7 szerveren, SSD gyorsítótárazással. A fájlrendszer NFS szerverrel van megosztva a hálózaton a webszerverek és verziókövetők felé. Egy esetleges szerver csere, vagy bővítés nem jár azzal, hogy több GB adatot kelljen mozgatni, egyszerűen csak a megfelelő csatoló pontokat kell újra felcsatlakoztatni.
### Hírlevelek webfejlesztőknek
URL: https://blog.fps.hu/a-tartalom-az-oledbe-hull/
Last updated: 2026-07-17T08:33:37.000Z
Ha képben akarsz maradni az újonnan megjelenő technológiákkal, eszközökkel kapcsolatban, és nem akarsz lemaradni semmiről, akkor bizony napi szinten érdemes böngészni a szakmai blogokat és twitter csatornákat. Szerencsére sokan gondoltak az elfoglalt fejlesztőkre, és számos forrás elérhető, ahonnan hetente, vagy akár naponta is hozzájuthatsz a legajánlottabb friss tartalomhoz.

Fontosnak tartom megemlíteni, hogy a következő lista szubjektív, azokat a hírleveleket tartalmazza, amikre magam is fel vagyok iratkozva és hónapok óta kapom őket. Kis kereséssel nagyon jó [gyűjteményeket](https://github.com/vredniy/awesome-newsletters?ref=blog.fps.hu) lehet találni, amiből érdemes szemezgetni, kinek-kinek az igényei szerint.

### The Smashing Email Newsletter

A Smashing Magazine véleményem szerint az egyik legigényesebb online portál fejlesztés témában. Ehhez híven a 2–3 hetente összeállított hírlevelük is csupa érdekes és hasznos tartalommal van feltöltve. Nálam abszolút első helyen van, és lelkesen nyitom meg minden alkalommal, tudva, hogy sohasem csalódom.  
[The Smashing Email Newsletter feliratkozás](https://www.smashingmagazine.com/the-smashing-newsletter/?ref=blog.fps.hu)

### Sidebar

A Sidebar naponta összegyűjti az 5 legérdekesebb linket (inkább front-end és design témában), amit a szerkesztői kézzel válogatnak ki.  
[Sidebar feliratkozás](http://sidebar.io/?ref=blog.fps.hu)

### Web Development Reading List

Heti rendszerességgel küldött, szintén odafigyeléssel és kézzel válogatott linkek. Változatos tartalom, ami a webfejlesztés (majdnem) minden területét lefedi.  
[WDRL feliratkozás](https://wdrl.info/?ref=blog.fps.hu)

### Sitepoint

A Sitepoint a Smashing Magazine mellett szintén figyelemre méltó szakmai oldal, rengeteg hasznos cikkel és leírással. Külön extra, hogy lehetőséged van téma szerint feliratkozni a hírlevelekre 10 kategóriában.  
[Sitepoint newsletter feliratkozás](http://www.sitepoint.com/newsletter/?ref=blog.fps.hu)

### Web Tools Weekly

Heti rendszerességű, tematikus gyűjtemény, javarészt front-end eszközök leírásával.  
[Web Tools Weekly feliratkozás](http://webtoolsweekly.com/?ref=blog.fps.hu)

### JavaScript Weekly

Ha te is olyan JS fanatikus vagy, mint én, akkor mindenképp iratkozz fel erre a hírlevélre. Rengeteg cikk, leírás, library és videó minden héten.  
[JavaScript Weekly feliratkozás](http://javascriptweekly.com/?ref=blog.fps.hu)

### CSS Weekly

Szintén hasznos heti jóság CSS témában.  
[CSS Weekly feliratkozás](http://css-weekly.com/?ref=blog.fps.hu)

### WPmail.me

WordPress fejlesztőknek erősen ajánlott, hetente érkező hírlevél. Kategorizált friss hírek, cikkek, tutorialok, sablon- és bővítményajánlók.  
[WPmail.me feliratkozás](http://wpmail.me/?ref=blog.fps.hu)

### Mito Weekly

Magyar hírlevelekből nem igazán tudok sokat felmutatni (ha te ismersz még ilyeneket, mindenképp oszd meg velem!). A nemrég útjára indult Mito Weekly üde színfolt e téren. Érdekessége a dolognak, hogy a Mito kollégái különböző témákban gyűjtenek linkeket minden héten, így a lehető legtöbb témát fednek le fejlesztéstől az analitikán keresztül a tanácsadásig.  
[Mito Weekly feliratkozás](http://mito.hu/weekly/?ref=blog.fps.hu)

### +fps hírlevél

Ugye nem kell bemutatnom!? Ha nem lenne ismerős, azonnal [kattints ide](https://www.fps.hu/hirlevel/?ref=blog.fps.hu)! :)

A fenti lista közel sem teljes és biztosan vannak még nagyon jó források, viszont azt hiszem, remek kiindulópontok, ha válogatott és valóban hasznos tartalomra vágysz. Amennyiben neked is van kedvenced és nincs a fent leírtak között, oszd meg velünk komment formájában, hagy tudjunk róla minél többen!
### CSS – fps módra
URL: https://blog.fps.hu/stiluslapok-fps-modra/
Last updated: 2026-07-17T08:33:48.000Z
Hozzávalók: a kedvenc text editorod, egy tetszőleges pre-processor és egy csipet npm. Az scss, less vagy styl fájljaid darabold logikai egységekre, melyeket 10 ezredmásodperc alatt összefűzöl. Összefűzés előtt ne felejtsd el folyamatosan fordítani őket. Végül ízlés szerint csatold a projekthez. Üdvözöllek az fps konyhájában!

A [Nevezzük a nevén: BEM](https://blog.fps.hu/bem-css/) c. blog posztom kapcsán vetődött fel, hogy az elnevezésen túl van, akinek inkább a strukturáltság és az újra felhasználhatóság okoz problémát. Az első gondolatom az volt: rendben, akkor beszéljünk a már jól ismert CSS ajánlásokról… Hmmm, inkább mégsem. Helyette megmutatom mi, hogyan csináljuk.

Mi is szembesültünk azokkal a problémákkal, melyek a fenntarthatóságot is gátolták. Az újra felhasználhatóságról meg ne is beszéljünk. Újra és újra bejárni projekt kezdetekor ugyanazokat a rutinokat. Ezért létrehoztunk egy SCSS-en alapuló induló csomagot, amely megadja a struktúrát, az általában szükséges elemeket, és még néhány extrát a kezünk alá.

### Struktúra

Az [SMACSS](https://smacss.com/?ref=blog.fps.hu) (Jonathan Snook) ajánlása is ad egyfajta struktúrát, amit már jól ismerünk: Base, Layout, Module, State, Theme. Ettől nem is tértünk el igazán, hiszen eddig sem szerettük volna feltalálni a spanyol viaszt. A következőképpen néz ki az általunk követett struktúra:

- Base
- reset.scss
- base.scss
- typo.scss
- helper.scss
- Components
- form.scss
- form.input.scss
- form.textarea.scss
- form.checkbox.scss
- navigation.icon.scss
- icons.scss
- \[...\]
- Pages
- \[...\]
- Layouts
- grid.scss
- layout.scss
- Units
- functions.scss
- mixins.scss
- silents.scss
- config.scss
- shame.scss

Nem is annyira más, igaz? A Module-ból Components lett, a Themeből Pages, a State pedig eltűnt. Alapvetően ez a kezdő csomag tartalmi weboldalakhoz készült, így nincs értelme a komponenstől elválasztani az állapotait. Viszont bekerült a Units, amely olyan SCSS-eket tartalmaz, amelyeknek nincs konkrét CSS kimenete. Függvények, mixinek és csendes osztályok segítségével kész megoldásokkal gyorsíthatod a fejlesztés folyamatát.

### Csak át kell írni

Biztos sokat hallottad már ezt a kijelentést, mikor olyan színkód került a kódba, ami nem egyezik meg az ügyfél által megadott design guideline-nal és a grafikus néha elfelejti, de te jól tudod, ez a „Csak átírjuk” valójában x fájl \* y sort jelent, ahol előfordul.  
Ezért került be a gyökérbe egy config.scss, amelyben általános, működés és kimenetet befolyásoló változók vannak.

```css

/**
 * Custom
 */
$responsive:        true  !default;
$use-rem-unit:      false !default;

/**
 * Paths
 */
$path--icon:    '../svg/icons';
$path--svg:     '../svg' !default;
$path--img:     '../img' !default;

/**
 * Colors
 */
 $color--a: #f58427; 
 $color--b: #0077c0;

/**
 * Breakpoints
 */
$breakpoints: (
    'palm' '(max-width: 480px)',
    'lap' '(min-width: 481px) and (max-width: 1023px)',
    'portable' '(max-width: 1023px)',
    'desk' '(min-width: 1024px)'
) !default;

```

Ez csak egy kis betekintés a fájlba. Ide kerülnek az alap töréspontok, amire épül a grid és néhány segédosztály, a font méretek, használt font családok és színpaletta stb. Ezzel elértük, hogy a CSS kódunk könnyen tudja követni a változásokat.

### Írd meg egyszer, használd sokszor!

Vannak olyan elemek, melyeket szinte minden projekt kapcsán újra és újra megírtunk, de miért? Írjuk meg egyszer és használjuk sokszor! Erre kitűnő példa egy hamburger ikon. Szinten minden responsive tartalmi weboldalnál előforduló elem. Megjelenésében teljesen ugyanolyan, néhány tulajdonságtól eltekintve. Ezeket a tulajdonságokat változókba vezettük ki, így az egyedi designhoz csak néhány értéket kell módosítani.

```css

/**
 * Navigation mobile icon
 */

$width:            24px !default;
$height:           20px !default;
$padding:          20px 0 20px 20px !default;
$color:            #fff !default;
$background:       false !default;

$state-color:      false !default;
$state-background: false !default;

$animate-duration: .5s   !default;

```

Most jogosan merül fel benned a kérdés, hogy ezek az előre megírt komponensek bekerülnek CSS kimenetbe, akkor is ha nincs rá szükségünk, és feleslegesen nagy lesz a felhasználó által letöltött adat mennyiség? A válasz: természetesen nem.  
Ezeket a komponenseket feltételhez kötöttük, mely a config.scss-ben adható meg.

**config.sccs**

```css

/**
* Used component
*/
$used-components: (
    navigation-icon: false,
    icons: true !default
);

```

**navigation.icon.scss**

```css

@if map-get($used-components, navigation-icon) {
    .navigation-icon {
        [...]
    }
}

```

Hasonlóan leegyszerűsíthetőek a „tömeg” osztályok, például az ikonok. Az ikonokat egy tömbbe gyűjtjük és *@each*\-el generáljuk le a megfelelő osztályokat.

```css

$icons: (
    ( name: 'file',   
      src: 'icon-file.svg',
      height: 30px, width: 23px, 
      before: true),
      
    ( name: 'pdf',   
      src: 'icon-pdf.svg',
      height: 30px, width: 33px, 
      tag: true),
);

```

Amit meg kell adni az egy hivatkozási név, amely alapján lehet hivatkozni rá. Az elérési útvonalát a *$path--icon* változó adja, melyet a config fájlban hoztunk létre, ezért elég a fájl nevét megadni. A méreteken kívül szükséges még meghatározni, hogy az ikont HTML elemként vagy annak pseudo elemeként (before/after) szeretnénk használni, vagy sem. Utóbbi esetben egy postfixel hozza létre a kapcsolódó osztályt.

**CSS**

```css

.icon--file-b:before {
    display: inline-block;

    width: 23px; 
    height: 30px;

    vertical-align: middle;

    background: url(../svg/icons/icon-file.svg) no-repeat center;
}

.icon--file-b:before {
    margin-right: 15px; 

    content: '';
}

.icon--pdf {
    display: inline-block;

    width: 33px; 
    height: 30px;

    vertical-align: middle;

    background: url(../svg/icons/icon-pdf.svg) no-repeat center;
}

```

**HTML**

```markup

<i class="icon icon--pdf"></i>

```

```markup

<a href="javascript:void(0);" class="icon icon--file-b">css-fps-modra.doc</a>

```

Az első gondolatod talán az lehet, hogy sok a redundáns tulajdonság. Ezek később a CSS minify-olása közben kerülnek összevonásra. Ami még talán érdekes lehet: a sok background-image. Ugyanis minden SVG hivatkozás egy plusz query-t jelent, ami lassítja az oldal betöltődését. Ezt egy [gulp-css-base64](https://www.npmjs.com/package/gulp-css-base64?ref=blog.fps.hu) npm modullal oldottuk meg, mely a fájl elérési útvonalát lecseréli a fájl base64 kódjára. Természetesen így a CSS végkimeneteli fájl mérete megcsalhat, hiszen már tartalmazzák az SVG fájlokat is.

### Segéd osztályok

Előfordult már veled, hogy egy-két soros szöveget kellett középre igazítani, dőltté tenni, vagy csak egyszerűen eltüntetni valamelyik töréspontnál, esetleg beszúrni egy nagyobb eltartást? Ilyenkor vakarod a fejed, hogy minek is nevezd. Kissé jellegtelen, nem tudod logikához kötni. Ilyen esetekre jók az általános segéd osztályok.

Ezekből az alapokon kívül (wrapper, clear, clear-fix…) még négy típust hoztunk létre: text, floating, display, spacer.  
Ezek az osztályok módosítókon keresztül biztosítják az alap rendezési, és megjelenítési tulajdonságokat. Szintén módosítókon keresztül a grid töréspontjaihoz igazíthatóak.  
Hogy néz ki használatban? Egy egyszerű példán levetítve valahogy így:

```markup

<p class="text text--center text--desk-right">text</p>

```

*A szöveg desktop kijelzőkön jobbra rendeződik, mobil eszközökön középre.*

Ami esetleg nem annyira általános az a spacer, elég rugalmas osztály, amivel két elem közötti eltartást implementálhatunk gyorsan. Akár egymás alá is törhetjük azokat, anélkül, hogy grid szerkezetébe helyeznénk.

```markup

<span>text</span>
<hr class="spacer spacer--20 spacer--desk-40 spacer--desk-horizontal" />
<span>text2</span>

```

*A két szöveges elem között 40px eltartást biztosít. Mobile eszközökön pedig a két elemet egymás alá fogja törni, és közöttük 20px lesz az eltartás.*

A spacer méreteit szintén tömbben tároljuk, hisz nem szeretnénk felesleges osztályokat létrehozni.

Természetesen a segéd osztályok CSS kimenete több ízben is feltételhez van kötve. Az első, hogy egyáltalán responsive a projekt, így figyeli a *$responsive* változót. Amennyiben a config fájlban false-ra van állítva, semmilyen töréspontot nem generál le. Figyeli, hogy milyen töréspontok esetén szeretnénk használni azokat *$breakpoint-has-helpers: ('palm', 'lap', 'portable', 'desk') !default;* és végezetül, mely segéd osztályokra van szükségünk.

```scss

/**
* Used helpers
*/
$used-helpers: (
	text:     true,
	floating: true,
	display:  true,
	spacer:   true,
);

```

Ezzel minimalizálva a felesleges osztályokat, hogy valóban csak azok kerüljenek a CSS-be, ami tényleg használatban is van.

### Eszköztár

A pre-processorok rengeteg olyan lehetőséget biztosítanak, amelyekkel csak élnünk kell, és felgyorsíthatjuk a munkánkat. Ilyenek a funkciók, mixinek és csendes osztályok. Ezeket a units könyvtárba gyűjtöttük.

A **mixin**ek egy részét mi írtuk, másik részét már létező mixin könyvtárakból vettünk át. Megszámolni sem tudom hány alkalommal kerestem úgynevezett „CSS triangle generator”-t és mennyivel egyszerűbb beírni: *@include triangle(30px 10px, #fff, top, ':after');*.

Az alap függvényeken kívül létrehozhatsz saját **függvények**et is. Mi is így tettünk. A mi függvénytárunk például szerepel egy *calc-rem* függvény, ami pixel mértékegységet vált át rem-re. A visszatérési értékét változtatja a cofing-ban található *$use-rem-unit* változó. Amennyiben false, a kapott bemeneti pixel értékkel tér vissza.  
Ez miért jó?  
A typo.scss fájlban minden szöveg stílust egy *@mixin text($size, $line, $margin: 0)* mixinen keresztül adunk meg, amely használja a fent említett függvényt. Így a config fájl módosításával bármikor átállhatunk rem mértékegység használatára, amennyiben úgy döntünk.

Amiről még nem esett szó, azok a csendes osztályok, azaz **silent class**ok. Ezek az osztályok nem jelennek meg sehol a CSS kódban. Viszont a tulajdonságok, amelyekkel rendelkeznek, örököltethetőek. Például adott egy kép, amelyet alap állapotban szürke árnyalatosan szeretnénk megjeleníteni, hover állapotában pedig szeretnénk a színét vissza adni:

```scss

@import '../silents/mixins.scss';

img {
    width: 100%;
    height: auto;
    @extend %grayscale;
    
    &:hover {
        @extend %colorful;
    }
}

```

Ezeknek az osztályoknak a számát még bővítjük. Jelenleg olyan prototípusok vannak benne, mint elem középre helyezése, szöveg túlfolyás kipontozása, elem tükrözése, vagy a legegyszerűbb a kör, azaz *%circle*, de még sorolhatnám.

### Ne maradj szégyenben!

Mi az a shame.scss? Az ötlet Harry Roberts, Chris Coyier és Dave Rupert viccelődéséből származik. Végül rájöttek, hogy ez nem is olyan rossz ötlet.  
Elkerülhetetlenek azok a helyzetek, amikor „hackelned” kell, vagy át kell hágnod a saját konvencióidat. Valamit gyorsan fixálni kell, a bemutatóig már nincs elég idő. Az ilyenkor szükséges csúnya megoldások kerülnek a shame.scss-be. A fájl elnevezése már magában beszédes (szégyen), hogy inkább kerüld a használatát.

A tartalma alap állapotban csak egy kommentár:

```scss

@import 'units/mixins.scss';
@import 'units/silents.scss';

/**
* Please, leave me empty!
*/

```

Ne felejtsd el: a shame-ben nem megoldások vannak, hanem „hibák”. Ha használod ezt a fájlt, később mindenképp térj vissza és írj valódi megoldást a gyorsan orvosolt problémára. Nehogy szégyenben maradj!
### Autentikációs rendszerek az fps-nél
URL: https://blog.fps.hu/autentikacios-rendszerek-az-fps-nel/
Last updated: 2026-07-17T08:34:00.000Z
Az fps-nél a projektek fejlesztéséhez számos különböző nyílt forráskódú rendszert használunk, melyekhez fejlesztői és teszt környezetek kialakítására van szükség. Ezen rendszerekhez biztonságos és személyre szabott hozzáférést kell biztosítani a csapattagok részére, nem csak irodán belülről, hanem akár távolról is.

Gyakorlatban ez azt jeleni, hogy egy munkatárs érkezése vagy távozása mindig biztonsági kockázatot jelent, és számos terhet tud róni az üzemeltetésre, mely szemmel tartja, ki és mihez fér hozzá. Két fontos fogalmat tisztázni kell ebben a témakörben, amit gyakran összekevernek.

### Mi is az az autentikáció?

Az autentikáció, más néven hitelesítés, egy olyan folyamat, amely során egy adat vagy entitás bizonyítja a róla állított tulajdonságok valódiságát.

Az autentikációnak 3 típusa van:

- Tudás – valamilyen egyedi információ van a felhasználónál
- Tulajdonlás – valamilyen egyedi eszköze van a felhasználónak
- Tulajdonság – valamilyen egyedi tulajdonsággal bír a felhasználó

### Mi is az autorizáció?

![ábra az autorizáció folyamatáról](https://blog.fps.hu/content/images/2016/02/mi_is_az_autorizacio.jpg)

Az autorizáció folyamata eltér az autentikáció folyamatától. Amíg az autentikáció egy adott személy vagy tárgy hitelességének ellenőrzésére szolgál, addig az autorizáció egy engedélyezési folyamat, melynek során a felhasználó engedélyt kap bizonyos feladatok elvégzésére. Tehát az autorizáció feltétele az autentikáció.

### Honnan is indult ez az egész az fps-nél?

Eleinte volt egy Linuxos fejlesztői szerver, volt hozzá egy Redmine. Ezt követte néhány ügyfél számára hosting szolgáltatás szerverteremben. Mindezekből kifolyólag újabb szerverek kerültek üzembe helyezésre, az ország több pontján is. Ezzel párhuzamosan több fejlesztést és menedzsmentet segítő szolgáltatás került bevezetésre, melyek szintén megkövetelték a felhasználók megfelelő azonosítását.

A legjelentősebb problémát az okozta, hogy az általunk használt rendszerek és szolgáltatások saját, belső azonosítási rendszert alkalmaztak, mely nagyban megnehezítette a felhasználók kezelését. Legszembetűnőbb példa erre az volt, hogy több felhasználónak is több különböző rendszerhez kellett hozzáférnie, vagy amikor változás állt be a csapattársak létszámában. Ilyen esetekben hosszú időt és a jelszavak többszöri megadását vették igénybe a rendszerek.

Számos kutatás és alternatíva keresést követően egyre inkább körvonalazódott, hogy valamilyen LDAP alapú implementáció lesz a megfelelő megoldás az fps számára, mint egy központosított jelszótároló rendszer, opcionálisan kiegészítve Kerberos alap autentikációval.

Az LDAP (Lightweight Directory Access Protocol) egy fa struktúrában tároló kliens szerver címtár protokol, ahol minden elemet egyértelműen meg lehet határozni a hozzá vezető bejárási útvonal segítségével. A Kerberos egy kifejezetten hálózati hitelesítési protokoll, melynek elsődleges célja egy kliens-szerver modell kialakítása volt, ahol mind a kliens, mind a szerver kölcsönös azonosítást biztosít egymás személyazonosságának megállapítására. A Kerberos működési elvét tekintve egy „jegy-alapú” rendszer, amely a felhasználók és a szolgáltatások azonosítását szolgálja.

LDAP alapú implementációk közül 3 megoldás került tesztelésre:

- **OpenLDAP: az első és eredeti LDAP megvalósítás.**  
Nehézkes adminisztráció és telepítés, valamint a nem túl stabil multi-master replikáció miatt nem került bevezetésre
- **389 Directory Server: Red Hat és Fedora égisze alatt fejlesztett megoldás**  
Már könnyebb adminisztrációs lehetőségekkel rendelkezik és multi-master replikációval, viszont nem biztosít egyéb integrált megoldást (pl. Kerberos)
- **FreeIPA: 389 DS-en alapuló integrált megoldás**  
integrált megoldás, LDAP és Kerberos megvalósítással

![FreeIPA server és kapcsolódásai](https://blog.fps.hu/content/images/2016/02/FreeIPA.jpg)

Végül a FreeIPA szoftver csomag került bevezetésre a különböző autentikációs megoldásai, illetve a könnyű telepítés és adminisztráció miatt. Ezzel a szoftvercsomaggal az összes fps által használt szolgáltatás jelszókezelését központosítani lehetett 1 dedikált rendszerrel. Modern webes felületen és hagyományos parancssorból is lehet kezelni, a hálózati számítógépek számára DNS szolgáltatást, tanúsítványkezelést biztosít, emellett FreeOTP alkalmazásokon keresztül, a 2 faktoros autentikációt is támogatja.

Az integrálás első lépéseként a Linux szerverek felhasználó-kezelése került migrálásra a rendszerbe, mely ezt követően ssh kapcsolódáskor Kerberos kulcsokkal azonosította a felhasználókat. Ezt követően a második lépcsőben, miután már minden felhasználó adatai elérhetőek voltak LDAP fa struktúrában, a használt webes szolgáltatásokat (Redmine, Gitlab) könnyű volt illeszteni a rendszerhez. Az LDAP protokol miatt, a jövőben is az ezen szabványt támogató rendszerek integrációja könnyen elvégezhető. A megfelelő hozzáférési jogosultságokat egyszerű keresési feltételekkel, vagy a teljes LDAP fa hozzáférésének egy részfára való korlátozásával biztonságosan lehet szabályozni.

Utolsó lépcsőként a hálózati fájlszerver, az irodai Wifi és a VPN szerver került csatlakoztatásra. Fájlszerverre a Samba szoftvercsomagot használja az fps, mely némi várakozást okozott az implementációban. Mind a Samba, mind a FreeIPA csomag esetén meg kellett várni a 4-es stabil kiadás elkészültét, ugyanis ezen verziókat lehet Kerberos protokolon összekapcsolni. Wifi és VPN megoldásoknál egy kiegészítő programra, egy FreeRADIUS szerverre volt szükség, mely egy csomagban biztosítja az autentikációs és autorizációs folyamatokat a Wifi és a VPN szerverek felé.

A jelenlegi rendszer kellően stabilan működik már több mint egy éve. Az implementálás során rendszeresen felbukkanó probléma volt a Linux, Mac OS X és Windows rendszerek közötti működés, mely általában az egyes operációs rendszereken nem megfelelően megvalósított protokollokra, vagy a különböző cégek jelszó biztonsági házirend-beli eltérésekből adódik. Így pl. a Windows-os világ miatt kénytelen vagyok a jelszavakat egy erősebb és gyengébb titkosítási algoritmussal is tárolni, szerencsére a FreeIPA szerver tudja biztosítani a jelszavak ilyen téren történő szinkronizálását.

A központosítás eredményeként jelentősen csökkent a felhasználók adminisztrálására szánt idő, és nullára csökkent a véletlenül rendszerben hagyott felhasználók száma. Ellenben nem szabad figyelmen kívül hagyni azt a nagyon fontos tényt, mely a központosítás ára, hogy a FreeIPA-t futtató szervert nagyon biztonságossá és védetté kell tenni.
### Mennyi az annyi?
URL: https://blog.fps.hu/mennyi-az-annyi/
Last updated: 2026-07-17T08:34:11.000Z
Uramatyám, ez sokba kerül! Nincs ekkora büdzsénk. Kaptunk olyan ajánlatot, ami ennek a fele. Mégis mi kerül ennyibe? Hangzanak az ismert reakciók az ajánlatra. Biztosan találkoztál már ezzel az érzéssel és merültek fel benned is ehhez hasonló gondolatok. Érthető, viszont érdemes megvizsgálnod, megértened, hogyan lehetséges ez. Ebben segítek most.

Kezdem azzal, hogy 200 milliós, nem ritkán 10–20 milliárdos és sokszor még nagyobb árbevétellel rendelkező cég képviselője vagy. Adott a feladat, hogy egy jól meghatározott céllal webes, mobilos alkalmazásra van szükség. Az éves büdzsé tervezésekor nyilván erre a történetre előre elkülönítésre kerül egy összeg. Sajnos már itt jelentkezik egy probléma. Mégis ki mondja meg, hogy mekkora legyen ez a csomag? Tényleg ért hozzá? Nem kellene bevonni egy külső piaci szereplőt? Tudom, nincs mindenhol ezzel gond, de azok a cégek nem is reagálnak a bevezetőben leírtak szerint.

Szóval, eljön a pillanat, meg kell valósítani a kitűzött projektet, arra ajánlatokat kell bekérni. [A tender kiírással kapcsolatban](https://blog.fps.hu/tervezes-folyamat-tender-palyazat-huzzuk-le/) már leírtam a gondolataim, olvasd el.

Veszek egy projektet, egy webfejlesztést. Persze lehetne akár mobil app fejlesztés is. Tapasztalataim szerint ezek minimum 4 hónapos időtartamot ölelnek fel. Valójában általában hosszabbak, kevés esetben pedig rövidebb, de a könnyedség miatt most legyen 4 hónap.

### Célok

![Rengeteg mindenhez kell érteni, sok szaktudásra van szükség](https://blog.fps.hu/content/images/2016/02/mi-mindenhez-kell-erteni.png)

Alapvetés a részedről, hogy letisztult, cool, sexy legyen a design, természetesen az alkalmazás minden eszközön használható legyen és maximálisan kiszolgálja a felhasználóid. Mindemellett a keresők szeressék az oldalt, és nem utolsó sorban hozza az elvárt számokat. Joggal elvárod, hogy transzparens legyen a teljes folyamat, és ha már letetted egy ügynökség mellett a voksod, akkor az ne dőljön be, tűnjön el a piacról fél éven belül. Sokáig a rendelkezésedre álljon, segítsen a projekt után, optimalizálni, továbbfejleszteni, módosítani stb.

Teljesen **egyetértek a céljaiddal, másként nincs értelme belevágni**. OK. Most leírom, hogy ehhez mire szükség van ügynökségi oldalról.

### Emberi erőforrás

Ebből az irányból közelítem meg, mert a folyamat leírása sokkal bonyolultabb lenne, és mert a korábban linkelt tenderes posztban megtalálod azt. Veszem sorra a szükséges szereplőket, amit most eléggé leegyszerűsítek, a legtöbb szereplő további munkakörökre bontható. Gálánsan eltekintek a keresőoptimalizálással, analitikával, tartalom feltöltéssel, teszteléssel foglalkozó, más a projektet segítő kollégától, mindezt az egyszerűség kedvéért.

#### Projekt menedzser

Vele leszel mindvégig kapcsolatban és még azután is. Az idejének felét biztosan veled és a csapattal fogja tölteni.

- A szerződéskötéssel kezdődik a munkája. 2 hét minimum, mert a jogászaitok átnézik az keretszerződésünket, a megrendelőt, mindent. Néhány ponton egyezkedés lesz, megy a ping-pong. Eközben nyilván a részünkről is szükséges ügyvéd, de ezen most átlendülök. Az aláírást követően ő felel a projektedért.
- Mindenben a rendelkezésedre áll. Biztosítja az átláthatóságot, összeköti egymással a megfelelő embereket, szállítja az információkat mindkét irányban, segíti és szervezi a csapat munkáját.
- A projekt „lezárása” után is kezeli a dolgaid, már csak azért is, mert garanciát vállalunk a termékedre, azaz a lehetséges hibákat ingyen javítjuk.

#### Tervező

Ő lesz az, aki hasonlóan a projekt menedzserhez a folyamat elejétől a végéig jelen lesz, van amikor intenzíven, van amikor csak a háttérben.

- A projekt elején biztosan találkozik veletek. Meg kell értenünk az üzleted, a céljaid, a belső folyamataid. Sokszor ezek az információk több ember fejében vannak meg, amire nagy szükségünk van, hogy értsük az egészet.
- Kutat. Miután szeretnéd, hogy a felhasználóid használják és kedveljék a terméked, nem árt, ha tudjuk kik ők és nekik mik az igényeik. Meg kell néznünk a versenytársaid megoldásait is, már csak azért is, mert a célközönséged valószínűleg járt már ott. Kifejthetem bővebben, felesleges. A lényeg, hogy minimális kutatásra mindenképpen szükség van, különben a fenti céljaid nem teljesülnek.
- Tervez. Összeszedi veled közösen a tartalmaid, tisztázza ki fogja ezeket előállítani és hogyan. Folyamatot tervez, kialakítja a rendszered struktúráját. Skiccel, drótvázakat rajzol. Egyeztet veletek, a projekt menedzserrel, a fejlesztőkkel.
- Validál. A folyamat számos pontján emberekkel (jó esetben valós felhasználókkal) ellenőrzi a terveket, a működést, a már működő alkalmazást és mindig javaslatot tesz módosításokra, hogy az jobb és jobb legyen.

#### Grafikus

Ő izgat téged a legjobban, mert ugyebár mindenki vizuális. Készít egy dokumentumot, ami rögzíti az elrendezéseket, a használandó tipográfiai alapokat, a színeket, a hangvételt, a felületek alapelemeit stb. – közösen a tervezővel. A fontos oldaltípusokra készít grafikailag kidolgozott terveket, aminek nagyon örültök. Itt lesztek igazán aktívak, tehát sok körben egyeztetünk veletek, hogy nektek, a felhasználóknak és nekünk is vizuális élménnyel szolgáljon a megjelenés.

#### Fejlesztők

Akármilyen projekt is legyen, **két fejlesztő** mindig javasolt. Egy olyan arc, aki a háttérprogramozáshoz, meg egy olyan figura, aki a külső felületi dolgokhoz ért inkább. A programozás nem egyszerű feladat. Sok-sok belső tesztelés mellett is biztosan lesznek hibák, melyeket majd ti találtok meg, a felhasználói tesztek hoznak elő, és olyanok is, melyek a projekt indulása után derülnek ki. Teszem hozzá, hogy minden eszközön közösen szeretnénk, hogy működjön az alkalmazás. A mobiloktól desktopig, számos különböző böngésző és verziói. Nem egyszerű. A fejlesztők együttműködnek a tervezővel, a grafikussal és nem utolsósorban a projekt menedzserrel. Itt se feledkezz meg arról, hogy a projekt utáni garanciális hibákat is ők fogják javítani.

#### Rendszergazda

Igen, rá is szükség van. Belső fejlesztői környezetet alakít ki, biztosítja nektek – hogy ti is nyomon követhessétek a fejlesztést – és a fejlesztőknek, hogy dolgozni tudjatok. Ő fogja éles környezetbe helyezni az alkalmazásod, bekonfigurálni a környezetet.

OK, itt az ideje számolni.

### Számolás

Ugyebár az mindenki számára egyértelmű, hogy a szakmájukhoz értő emberek dolgoznak az egyes területeken. Ha mégis egy junior kerül egy posztra, akkor mögötte ott áll (mert ott kell álljon) egy senior, aki segít neki, tehát ugyanott van a dolog. Elképzelhető, hogy polihisztorok is vannak a rendszerben, de egyrészt azon már rég túl van ez a világ, hogy valóban létezzenek, másrészt ha mégis akad(na) ilyen csodabogár, nos ő 2–3x annyit kér(ne) a munkájáért.

![Polihisztorok már rég nincsenek.](https://blog.fps.hu/content/images/2016/02/nincsenek-polihisztorok-2.png)

Tehát **4 hónapos** projekt.

1. A projekt menedzser 4 hónapig végig veletek lesz, amibe nyugodtan vedd bele a projekt utáni kapcsolattartást (alaphangon garancia). Összesen 2 hónap.
2. A tervezőre 1,5 hónapot érdemes számolni.
3. A grafikusra elég 1 hónapot.
4. A fejlesztőkre utánkövetéssel 1,5–1,5 hónapot. Összesen 3 hónap.
5. Rendszergazdát most nagyvonalúan tudjuk be a fentiekbe.

Gyorsan összeadva kijön 7,5 hónap. Ebből dobj le 2,5 hónapot, mert azért egy csapatnak van más dolga is, ami a projekted mellett futhat, de tényleg nagyon minimálisan, mert a te termékedre kell koncentrálni.

**Kijön egy szám: 5 hónap.**

Kiterítve az idősíkot, 5 hónapig dolgozik rajta egy ember. Nyilván eltérőek a fizetések, de most gondolj egy számra, egy átlag nettó fizetésre. Amikor ízlelgeted ezt az értéket, akkor vedd figyelembe, hogy óriási szakember hiány van az IT minden területén, amiről se te, se mi nem tehetünk, ez van. Mehetek tovább?

Most vedd azt, hogy egy cégnek mennyit kell fizetni a nettó bér és egyáltalán egy munkavállaló után, azaz valójában mennyibe is kerül? Segítségként: a nettót nyugodtan szorozd fel 2,5-lel. Megvan?

Most szorozd meg 5-tel. Máris van egy csupasz szám.

És ekkor még egyetlen forint profit sincs rajta. Ti is pénzből éltek, mi is. Továbbá nem szabad megfeledkezni arról, hogy a cég adót is fizet, irodát kell fenntartania, eszközparkkal és azok amortizációjával. Nem árt az eszközpark és az emberek tudásának folyamatos fejlesztése sem. Ez az abszolút minimum, ami szintén terheli a projekted árát pluszban.

Az egyéb költségeink nyilván téged nem érdekelnek, ezért nem is írom le, de ha a céged megnézed, pontosan tudod miről beszélek.

A végére engedj még meg egy utolsó gondolatot. Több okból is Open Source alapokon fejlesztünk. Az egyik legfontosabb számodra, hogy nem kell liszensz díjat fizetned egy saját fejlesztésű keretrendszerért. A többit majd egy másik posztban…
### 2015 válogatott fontjai
URL: https://blog.fps.hu/2015-valogatott-fontjai/
Last updated: 2026-07-17T08:34:20.000Z
Lassan itt az év vége. Ilyenkor előjönnek a szokásos listák, mint top 10, top 100, az év valamije. Nincs ez másként a betűtípusok világában sem, hisz a listákat mindenki szereti. Pláne, ha ingyen letölthető és használható fontokról van szó. Mi most az [Awwwards](http://www.awwwards.com/100-greatest-free-fonts-collection-for-2015.html?ref=blog.fps.hu) 2015-ös listájából szemezgettünk, és kigyűjtöttük neked a magyar ékezetekkel is maradéktalanul rendelkező fontokat.

A licencekre és felhasználhatóságra figyelj, és a linkeken keresd a **HERE, FREE, DOWNLOAD** feliratokat, hogy sikeresen letölthesd a neked megtetsző betűtípust. Van, amikor az alkotó egy megosztást kér, vagy az email címed, de garantáljuk, a kiválasztott betűtípus megszerzése nem vesz többet igénybe egy percnél.

Természetesen az [eredeti listán](http://www.awwwards.com/100-greatest-free-fonts-collection-for-2015.html?ref=blog.fps.hu) található fontokból is szemezgethettek, csak készüljetek fel az üres karakterekre.

### *Jó böngészést, szép plakátokat és még szebb tipókat kívánunk az új évre is!*

![](https://blog.fps.hu/content/images/2015/12/aileron.png)  
**[Aileron](http://tipotype.com/aileron/?ref=blog.fps.hu)** – 1 betű 16 típus.

![](https://blog.fps.hu/content/images/2015/12/bariol.png)  
**[Bariol](https://www.behance.net/gallery/4015111/bariol?ref=blog.fps.hu)** – Egy szépen lekerekített font.

![](https://blog.fps.hu/content/images/2015/12/bebas_tam.png)  
**[Bebas-Tam](https://www.behance.net/gallery/16224141/BEBAS-TAM-%28freefont%29?ref=blog.fps.hu)** – [Marci Borbás ](https://www.behance.net/marciborbas?ref=blog.fps.hu) – Magyar designer -15 fokos dőlésszöggel.

![](https://blog.fps.hu/content/images/2015/12/borg.png)  
**[Borg](https://www.behance.net/gallery/12578815/Borg-Typeface-%28FREE%29?ref=blog.fps.hu)** – [titus prod](https://www.behance.net/titusprod?ref=blog.fps.hu) – Magyar designer dekor betűi. Szerintem találkoztál már vele.

![](https://blog.fps.hu/content/images/2015/12/bukhari.png)  
**[Bukhari](https://www.behance.net/gallery/24966319/Bukhari-Script-Free-Font?ref=blog.fps.hu)** – 375 karakter ínyenceknek.

![](https://blog.fps.hu/content/images/2015/12/didactic.png)  
**[Didactic - 1.5](http://www.tylerfinck.com/didactic/?ref=blog.fps.hu)** – Klasszikus vonalak.

![](https://blog.fps.hu/content/images/2015/12/disclaimer.png)  
**[Disclaimer](http://fontfabric.com/disclaimer-free-font?ref=blog.fps.hu)** – Játék a betűkkel, akár plakáthoz is.

![](https://blog.fps.hu/content/images/2015/12/donau.png)  
**[Donau](http://fontfabric.com/donau?ref=blog.fps.hu)** – Egy Lautrec plakátot?

![](https://blog.fps.hu/content/images/2015/12/dual.png)  
**[Dual](http://charlesdaoud.com/portfolio/dual-typeface/?ref=blog.fps.hu)** – Egyszerűségében szép.

![](https://blog.fps.hu/content/images/2015/12/geomanist.png)  
**[Geomanist](http://geomanist.com/?ref=blog.fps.hu)** – Ezt a helyedben megvenném.

![](https://blog.fps.hu/content/images/2015/12/gogoia.png)  
**[Gogoia](https://www.behance.net/gallery/24260799/GOGOIA-TYPEFACE?ref=blog.fps.hu)** – Úgy tűnik divatba jött idén a ’20-as évek.

![](https://blog.fps.hu/content/images/2015/12/grandhotel.png)  
[\*\*Grand Hotel](http://www.fontsquirrel.com/fonts/grand-hotel?ref=blog.fps.hu)\*\* – Ha kézzel szeretnéd írni.

![](https://blog.fps.hu/content/images/2015/12/kelson.png)  
**[Kelson](http://fontfabric.com/kelson-sans?ref=blog.fps.hu)** – Titillium Web helyett.

![](https://blog.fps.hu/content/images/2015/12/lovato.png)  
**[Lovato](https://www.behance.net/gallery/19391799/The-Lovato-Font-Family?ref=blog.fps.hu)** – Ha szereted a kör alakú „o”-kat.

![](https://blog.fps.hu/content/images/2015/12/madras.png)  
**[Madras](http://fontfabric.com/madras-free-font?ref=blog.fps.hu)** – Kár, hogy csak kétféle ingyenes típusa van.

![](https://blog.fps.hu/content/images/2015/12/myra.png)  
**[Myra](https://www.behance.net/gallery/6367355/Myra-Caps-%28Typeface%29?ref=blog.fps.hu)** – Ismét a ’20-as évek ihlette.

![](https://blog.fps.hu/content/images/2015/12/nexa_rust.png)  
**[Nexa Rust](http://fontfabric.com/nexa-rust-free-font?ref=blog.fps.hu)** – Nagy kedvenc, mind az 5 fajátja. Lumberszexuálisoknak kötelező.

![](https://blog.fps.hu/content/images/2015/12/oranienbaum.png)  
**[Oranienbaum](http://www.dafont.com/oranienbaum.font?ref=blog.fps.hu)** – H2-höz tökéletes.

![](https://blog.fps.hu/content/images/2015/12/ph.png)  
**[PH](http://fontfabric.com/ph-free-fonts?ref=blog.fps.hu)** – Hogy felejtsd el a Chiller-t.

![](https://blog.fps.hu/content/images/2015/12/pirou-1.png)  
**[Pirou](https://www.behance.net/gallery/20090589/PIROU-Free-Font?ref=blog.fps.hu)** – Valaki egy Verne Gyula borítóhoz?

![](https://blog.fps.hu/content/images/2015/12/sprite.png)  
**[Sprite Graffiti](http://fontfabric.com/sprite-graffiti-font?ref=blog.fps.hu)** – Graffitiseknek kötelező.

![](https://blog.fps.hu/content/images/2015/12/stiff_staff.png)  
**[Stiff Staff](http://fontfabric.com/stiff-staff-font/?ref=blog.fps.hu)** – Techno parti *(van még ilyen?)* szórólapjára kívánkozik.

![](https://blog.fps.hu/content/images/2015/12/sverige_script.png)  
**[Sverige Script](http://www.dafont.com/sverige-script.font?ref=blog.fps.hu)** – Csontváry Kosztka Tivadar se írhatta volna szebben.

![](https://blog.fps.hu/content/images/2015/12/voga.png)  
**[Voga](http://charlesdaoud.com/portfolio/voga-typeface/?ref=blog.fps.hu)** – Beszédes név, de mégsem VOGUE.

![](https://blog.fps.hu/content/images/2015/12/zona_pro.png)  
**[Zona Pro](http://fontfabric.com/zona-pro?ref=blog.fps.hu)** – Az az „R” betű ismét csak a 20\. század elejét tükrözi.

## +1

Igaz, nem került fel az Awwwards listájára, de a mi szívünkhöz közel áll:  
![](https://blog.fps.hu/content/images/2015/12/ryman_eco.png)  
**[Ryman Eco](https://blog.fps.hu/kornyezetbarat-betutipus-eco-font/)** – Miért fontos ez?

Mert ők, mi, ti: a jövő. [A Grey London és a Ryman (Dan Rhatigan type designer)](http://www.rymaneco.co.uk/?ref=blog.fps.hu) is felismerte ezt, és egy gyönyörű, környezettudatos és mellesleg ingyenes fontot készítettek, amivel a világ bármely pontján csökkenthető a tintafelhasználás. Mi pedig magyarítottuk nektek. **Használjátok bátran!**
### Reszponzív webtervező eszközök
URL: https://blog.fps.hu/reszponziv-webtervezo-eszkozok/
Last updated: 2026-07-17T08:34:30.000Z
Miért érdekes a reszponzív web tervezés? Nem egy új dolog, már több mint tíz éve jelent meg, de még mindig vet fel kérdéseket, hogyan, mivel és hogyan tervezzünk… A technológia fejlődésével számtalan eszköz jelent meg, amin elérhető az internet. A mobilok fontossága már rég nem kérdés. Az internetezési szokások megváltoztak, így a tervezői eszközöknek is fel kell készülniük, hogy a tervezési folyamat minél hatékonyabb, egyszerűbb, használhatóbb legyen. Mit nevezünk reszponzív tervezésnek? Milyen folyamatokból áll? Milyen problémák merülnek fel? Milyen eszközök állnak a rendelkezésünkre?

### Mi a reszponzív tervezés?

Először a „reszponzív” fogalmat, [Ethan Marcotte – Responsive Web Design](http://www.amazon.com/Responsive-Design-Brief-People-Websites/dp/098444257X/ref=sr%5F1%5F1?s=books&ie=UTF8&qid=1450182520&sr=1-1&ref=blog.fps.hu) könyvében használta és fejtette ki brief formájában miről is van szó – érdemes elolvasni. :)

Egyszerűen fogalmazva: a képernyő méretét figyelembe véve változik a weboldal megjelenése.

Amint megvannak a szükséges információk a tervezés elkezdéséhez: ötlet, üzleti és felhasználó célok, kutatás… megvannak a cél eszközök. Figyelembe kell venni, hogy a használati esetek különböznek egy okosóra, okostelefon, tablet, netbook, asztali nézet, vagy okos TV esetében, de a felületnek fednie kell egymást, mivel részben azonos kódra épül, így a lehetőség korlátozott.

![Az illusztráción matrjoska (kokeshi) baba szerepel, egymásba illeszthető, egyre kisebb babákból állnak.](https://blog.fps.hu/content/images/2015/12/webdesign-tool-02.jpg)

*Az illusztráción matrjoska (kokeshi) baba szerepel, egymásba illeszthető, egyre kisebb babákból állnak.*

Ilyenkor olyan egységeket kell kialakítani, amelyeket a legkisebb eszközön, pl. mobil méreten határozol meg, és a legnagyobb egység között osztod fel. Ezek lesznek a **gridek.** A legáltalánosabb a 12 vagy 24-es felosztás. Nézd meg a [CSS Wizardy Grids](http://csswizardry.com/csswizardry-grids/?ref=blog.fps.hu) rendszerét.

Indulj a legkisebb elemtől és építkezz! » [Luke Wroblewski Mobil First](http://www.amazon.com/Mobile-First-Luke-Wroblewski/dp/1937557022?ref=blog.fps.hu)

##### Tipikus problémák tervezés során

- Csak desktop nézet készül.
- Desktop nézet után készül el a mobil nézet.
- Desktop nézet után minden blokk leugrik egymás alá.
- Mobil, tablet és desktop nézet között nincsenek köztes nézetek, töréspontok tervezve.

#### Milyen általános elvárásaim vannak az ideális tervező eszközzel szemben?

- Artboardok
- Töréspontok
- Köztes nézetek kezelése
- Dinamikus tartalmak használata
- Gridek
- Smart elemek
- Stílusok kezelése

![alt](https://blog.fps.hu/content/images/2015/12/webdesign-tool-03.jpg)

### Milyen eszközöket próbáltam ki?

Az eszközök sokszínűsége miatt 4 csoportba soroltam, az alapján, hogy milyen célt szolgál a szoftver: **tervezői, grafikai, prototípus**, vagy **fejlesztői eszköz** és **online elérhető, vagy sem**.

**Tervezői:** UX-App, UXPin, Axure

**Grafikai:** Adobe Photoshop, Sketch

**Prototípus:** Atomic, inVision, Adobe Edge Reflow, Macaw

**Fejlesztői:** Webflow, Froont, XPRS

**Online elérhető:** UX-App, UXPin, Atomic, inVision, Froont, Webflow, XPRS

*Az eszközök folyamatosan fejlődnek, ezért a poszt a jelen állapotot tükrözi. Így, ami ma érvényes, az lehet, hogy holnap már nem lesz.*

### Tervezői eszközök

#### [UX-App](https://www.ux-app.com/?ref=blog.fps.hu)

![UX-App](https://blog.fps.hu/content/images/2015/12/uxapp.jpg)

Erőteljes prototípus–, interakció tervező, a statikus drótvázaktól, a teljesen interaktív prototípusig. Mindezt kódolás nélkül.

**Pozitív:** Online elérhető és sok előre definiált objektumot tartalmaz. Egyszerű diagram–, és folyamatábra készítésére kiváló.

**Negatív:** Egy projekt egyszerre csak egy nézetet kezel: mobil-tablet, vagy desktop. Nincs köztes nézet, sem átjárhatóság.

**Szerethető:** Nem kell regisztrálni és azonnal elérhető.

**Nehézség:** Körülményesen lehet prototípust, vagy drótvázat készíteni.

#### [UXPin](https://www.uxpin.com/?ref=blog.fps.hu)

![UXPin](https://blog.fps.hu/content/images/2015/12/uxpin.jpg)

UXPin egy felhő alapú drótváz, látványterv, prototípus készítő. Számos funkcióval rendelkezik, mint például prezentáció, felhasználói tesztelés, élő együttműködés.

**Pozitív:** Könnyen kezelhető, átlátható és egyszerűen megtanulható program. Rendelkezésre áll rengeteg beépített objektum, melyek nagyban meggyorsítják a munkavégzést. Ezen felül kezeli a smart objekteket, a különböző töréspontokat, és nem utolsó sorban ügyfél felé is prezentálható formában jeleníti meg a tervezett felületeket.

**Negatív:** Bugos, költséges, és a stílusok kezelése hiányzik.

**Szerethető:** A nézetek között könnyen lehet duplikálni objektumokat, akár az egész tervet. Gyorsan készíthető benne drótváz, vagy prototípus.

**Nehézség:** Alapvetően nem találkoztam ilyennel. Ha megszokja és kiismeri a programot a felhasználó, akkor könnyen kezelhető a funkcionális hibáktól eltekintve.

#### [Axure](http://www.axure.com/?ref=blog.fps.hu)

![Axure](https://blog.fps.hu/content/images/2015/12/axure.jpg)

Az Axure drótváz, prototípus, web és alkalmazás tervező eszköz, amihez nem szükséges kódolási ismeret.

**Pozitív:** Legnépszerűbb diagram, drótváz, prototípus tervező. Egyszerűen használható. Csak a lényeges dolgokat pakolták bele és nem akartak Adobe®Photoshop® [– tudtátok, hogy már csak így írhatjátok le? –](http://www.adobe.com/legal/permissions/trademarks.html?ref=blog.fps.hu) lenni.

**Negatív:** Sajnos nem tartalmaz alapértelmezetten sok beépített elemet.

**Szerethető:** Egyszerűség, előnézeti mód, számos widget elérhető hozzá, és magasfokú támogatottság jellemzi. Pl. Sketch-be is könnyen átvihető a projekt.

**Nehézség:** Az elvárt funkciók nem megfelelően működnek. (bugos)

### Grafikai eszközök

#### [Adobe®Photoshop®](http://www.adobe.com/hu/products/photoshop.html?ref=blog.fps.hu)

![Adobe®Photoshop®](https://blog.fps.hu/content/images/2015/12/photoshop-1.jpg)

A megkerülhetetlen Adobe®Photoshop® CC 2015, a világ leghatékonyabb képkezelési és tervezési alkalmazása, mely nélkül szinte elképzelhetetlenek a különféle kreatív projektek. Asztali számítógépeden és mobileszközeiden egyaránt gyönyörű fényképeket, terveket, többek között webhelyeket, mobilalkalmazásokat, 3D alkotásokat, videókat és egyéb műveket hozhatsz létre. Erre használják sokan, de persze mind tudjuk, hogy valójában képszerkesztésre való. ;)

**Pozitív:** Annak ellenére, hogy egy mammut, azért igyekszik a trendeket követni és folyamatosan fejlesztik. Ha csak egyet kell kiemelnem, végre megjelentek az Artboardok. Hurrá. Összeségében ez a Photoshop®! Bármit elkészíthetsz benne, de biztos ez kell neked? *Jól látszik, hogy inkább trend követő, mint trend meghatározó termék lett belőle.*

**Negatív:** Egy őskövület. Egy robosztus gép. Mind méretében, mind kezelhetőségében sok kívánnivalót hagy maga után, és olykor inkább zavaró a 20 féle megoldás egy problémára, mint sem a könnyedség.

**Szerethető:** A megszokott dolgok, a megszokott helyen. Jó tanár. Ha ismered, könnyen megtanulod a többi hasonló programot is.

**Nehézség:** Az egy külön poszt lenne, majd ti leírjátok. :)

#### [Sketch](https://www.sketchapp.com/?ref=blog.fps.hu)

![Sketch](https://blog.fps.hu/content/images/2015/12/sketch.jpg)

A Sketch egy professzionális digitális grafikai tervező eszköz sajnos egyelőre kizárólag Mac-re.

**Pozitív:** Stílusokat tudsz megadni, és ami ennél is fontosabb, hogy a program úgy jeleníti meg a tervet, mint ahogy ahogy a böngészőben fog megjelenni. Kicsit a web tervezői és a grafikai programok ötvözete, de a mérleg inkább a grafika felé dől el. Nagyon hasznos és jó pluginok vannak hozzá, lásd [Zeplin](https://zeplin.io/?ref=blog.fps.hu).

**Negatív:** Pluginok nélkül nem sok mindent tudsz benne csinálni, például a lekerekítéshez is egy [külön plugin](https://github.com/arjenvr/sketch-radius?ref=blog.fps.hu) szükséges.

**Szerethető:** Egyszerű, átlátható a felülete. Hasonlóan épül fel, mint egy fejlesztői eszköz, ezáltal könnyebben tudsz azonosulni a tervezés során a fejlesztői gondolkodással.

**Nehézség:** Csak Mac-re.

### Prototípus készítő eszközök

#### [Atomic](https://atomic.io/?ref=blog.fps.hu)

![Atomic](https://blog.fps.hu/content/images/2015/12/atomic.jpg)

Az Atomic egy prototípus tervező eszköz, a legrövidebb út ahhoz, hogy gyönyörű interakciókkal lásd el a weboldaladat, alkalmazásodat.

**Pozitív:** Sok sablont és előre definiált animációt tartalmaz.

**Negatív:** Nem tervezői eszköz, hanem inkább egy kész terv alapján tudsz prototípust készíteni benne.

**Szerethető:** Jó a felülete és sok interakciót találsz meg benne.

**Nehézség:** Nehéz kiugrani az előre definiált interakciókból és valami egyedit alkotni.

#### [inVision](http://www.invisionapp.com/?ref=blog.fps.hu)

![inVision](https://blog.fps.hu/content/images/2015/12/invison.jpg)

Az inVision egy erőteljes prototípus, interakció tervező eszköz, számos lehetőséggel és funkcióval.

**Pozitív:** Bővelkedik a jobbnál jobb funkciókban. Például Live Share, ami lehetővé teszi, hogy többen is egyszerre lássátok a tervet, és ha szükséges egyből kommentárt is fűzzettek hozzá. Mindezeken felül, nagy pozitívum, hogy cross-platformon készíthetőek el a tervek. Így a mobilra készült terveket, előnézeti módban mobil nézetben láthatod.

**Negatív:** Bugos. Többször kell ugyanazt beállítani, mert nem menti el. Nem valósan renderel, hogy csak a kirívóakat említsem.

**Szerethető:** [Pluginként](http://www.invisionapp.com/new-features/24/liveshare-ps-real-time-design-meetings-inside-photoshop?ref=blog.fps.hu) be tud épülni a Photoshop®-ba, ahonnan meg tudod osztani a képernyőd, és így élő tervezésre ad lehetőséget. *– Az ügyfelek imádják!*

**Nehézség:** Sajnos korlátozott és pár projekt után, ha közel nőtt hozzád, ki kell nyitnod a pénztárcádat.

#### [Adobe Edge Reflow](https://creative.adobe.com/products/reflow?ref=blog.fps.hu)

![adobe edge reflow](https://blog.fps.hu/content/images/2015/12/edgereflow-1.jpg)

Az Adobe Edge Reflow segítségével, gyorsabban készíthető rugalmas webes felület és valósághű prototípus. Az Edge Reflow közvetlenül kapcsolódik az Adobe®Photoshop® CC alkalmazáshoz, így mindössze egy kattintással lehet statikus tervről, különböző nézetekre, töréspontokra váltani.

*Megjegyzés: 2015\. novembertől az Adobe® megszünteti az Edge Reflow CC továbbfejlesztését.*

**Pozitív:** Hozzá tudsz adni töréspontokat és egyszerre több nézeten is tudod módosítani az objektumokat. Blokkokat és dinamikus tulajdonságokat is kezel, amivel nagyban megkönnyíti a munkát.

**Negatív:** Nem tudsz hozzáírni CSS-t, annak ellenére, hogy CSS-t generál.  
Nem kezel stílusokat, pl. nem adhatod meg egy HTML elemnek, hogy hogyan jelenjen meg (h1, h2, button, a).

**Szerethető:** Egy kattintással módosíthatóak a beágyazott grafikai elemek, még a .psd fájlok is.

**Nehézség:** A köztes nézeteket nehezen kezeli.

#### [Macaw](http://macaw.co/?ref=blog.fps.hu)

![macaw](https://blog.fps.hu/content/images/2015/12/macaw.jpg)

Macaw egy reszponzív weboldal tervező, amely kódolás nélkül hasonló rugalmasságot biztosít, mint egy képszerkesztő szoftver, de ezzel együtt HTML és CSS kódot használ.

**Pozitív:** Egy dokumentumban több oldal hozható létre, több töréspont adható hozzá. Egy elem stílusa, megjelenése több nézeten egyszerre módosítható és webfontokat is kezel.

**Negatív:** Annak ellenére, hogy kezeli a CSS-t és HTML-t, azokat csak beilleszthető és nem szerkeszthető elemekként tudja kezelni. Nem adhatóak meg dinamikus elemek, pl: *height: auto;*. Exportálásban a fontokat nem jól rendereli. Alapértelmezett méretként *(default)* a legnagyobb méretet veszi alapul és jócskán vannak bugok, amik megnehezítik a tervezést.

**Szerethető:** Látványos, átlátható kezelőfelület.

**Nehézség:** Fejlesztői gondolkodás nélkül nehéz benne jól elkészíteni egy oldalt, vagy prototípust.

### Fejlesztői eszközök

#### [Webflow](https://webflow.com/?ref=blog.fps.hu)

![webflow](https://blog.fps.hu/content/images/2015/12/webflow.jpg)

A WebFlow egy felhő alapú szoftver, szolgáltatás, CMS rendszer, melynek segítségével, teljes reszponzív weboldal készíthető el, kódolási ismeret nélkül. Főként tervezők számára készült. A vizuális szerkesztő, hasonlóan épül fel, mint egy grafikai alkalmazás. Ezenkívül dinamikus tartalom is kezelhető, ami vizuális felületen módosítható. Éppen most jelent meg hozzá a [3D transzformációk kezelésenek](http://3d-transforms.webflow.com/?ref=blog.fps.hu) lehetősége.

**Pozitív:** Dinamikus elemekből rakható össze. Gridek, beépített sablonok, képek könnyű kezelhetősége. Alapvetően egy izgalmas és tervező-barát program.

**Negatív:** Csak náluk hosztolhatóak a tervek és egyes funkciókat csak fizetős formában érhetsz el.

**Szerethető:** Vizuális CMS – Az objektumokat a kész felületen módosíthatod.

**Nehézség:** A tervezést nehezíti, hogy az objektumok nehezen optimalizálhatóak az egyedi töréspontokon.

#### [Froont](http://froont.com/?ref=blog.fps.hu)

![froont](https://blog.fps.hu/content/images/2015/12/froont.jpg)

Froont egy felhő alapú reszponzív tervező eszköz, grafikusok számára, melynek segítségével landing page-ek, kiadványok készíthetőek. A tervezett statikus oldalak exportálhatóak vagy hosztolhatóak.

**Pozitív:** Sablonokból, dinamikus elemekből épülnek fel a tervek, amik a későbbiekben megkönnyítik a módosítást.

**Negatív:** Nem igazán személyre szabható. Előre definiált töréspontok, amik nem módosíthatóak, és mindezek mellett egyes szolgáltatások fizetősek.

**Szerethető:** Látványos, vizuális szerkesztő felület, ahol a grafikai megjelenésen tudod módosítani az objektumokat.

**Nehézség:** Ez a program is elhanyagolta és inkább lekorlátozta az optimális működés érdekében az egyedi nézetek személyre szabható kezelhetőségét.

#### [XPRS](http://www.imxprs.com/?ref=blog.fps.hu)

![xprs](https://blog.fps.hu/content/images/2015/12/xprs.jpg)

Az XPRS az egyszerű és élvezetes weboldal készítésről szól, amely mindenki számára elérhető. Kódolási ismeret nélkül készíthető tejes reszponzív weboldal. Beépített blog és e-commerce szolgáltatás áll a felhasználó rendelkezésére.

**Pozitív:** Kódolás nélkül, kész a weboldal. Mondja a marketing szöveg. *Biztos?!*

**Negatív:** Sablonok alakíthatóak át. Csak alapértelmezett töréspontokat kezel. Kizárólag náluk hosztolható és a tetejében egyes funkciók használhatatlanok.

**Szerethető:** Egyszerű, élményszerű szerkesztő felület, ahol a kész oldalon módosíthatóak az objektumok.

**Nehézség:** Az egyedi elemek készítése kínszenvedés. Inkább bezárod a programot, mint hogy elkészíts egy egyedi elemet.

### Végszó

Azért nem találkozhattál a poszt során a személyes benyomásaim pontszerű értékelésével, mert úgy gondolom, hogy: **Ne az eszköz határozza meg, hogy a feladathoz mit használsz, hanem a feladathoz válassz megfelelő eszközt.** Ezért inkább te is a projekthez igazítva válassz megfelelő software-t, amit magabiztosan használsz, és ne vessz el az alkalmazások adta lehetőségek, vagy épp hiányosságok halmazában. A végére pedig egy klasszikus. Sose feledkezz meg a már jól bevált eszközökről sem. **Papír és ceruza!** Még mindig egy jó kombináció a tervezéshez. :)

### Te milyen eszközöket használsz?

Írd meg kommentben!
### 40 lined vector christmas icons for free
URL: https://blog.fps.hu/40-lined-vector-christmas-icons-for-free/
Last updated: 2026-07-17T08:34:38.000Z
Our present for the world! Free vector based (pdf) lined icons for Christmas. Download and use it wherever and whenever you want. Free for personal and commercial use as well.

![Lined vector christmas icons preview](https://blog.fps.hu/content/images/2016/01/fps-line-christmas.png)

[Download for free (0 downloads)](https://www.fps.hu/presentations/christmas-lined-icons-fps.pdf?ref=blog.fps.hu "Download 40 lined vector christmas icons pack for free") 

It is allowed to share with your friends and others if you like it! ;)

[Have you got our flat vector Christmas icons? Download as well!](https://blog.fps.hu/free-christmas-flat-icons-vector/)
### Android 6.0 Marshmallow
URL: https://blog.fps.hu/android-60-marshmallow/
Last updated: 2026-07-17T08:34:48.000Z
Közel egy hónapja kerültek piacra a Nexus új készülékei (Nexus 5X, Nexus 6P), és ez számunkra azért is fontos, hiszen most már hivatalosan is elkezdte „térhódítását” az Android új operációs rendszere (Android 6.0), amelyet **Marshmallow** névre kereszteltek. Az új OS-t próbálgatva, be kell látni, hogy külsőségekben nem sok változást hozott, megmaradtak a Lollipopnál is bevezetett Material designnál, ami kapott pár kiegészítő elemet. Természetesen ez nem azt jelenti, hogy az OS fejlesztői a korábbi rendszer klónjának javítását szeretnék lenyomni a torkunkon, ugyanis történtek jelentősebb változások. Ezek a fejlesztések főleg a „háttérben”, a rendszer stabilabb, biztonságosabb működésére irányultak. Ezek közül szedtem össze pár érdekesebb változtatást fejlesztők számára, amire érdemes és jó ha odafigyelsz a jövőben.

### 1\. Alkalmazás engedélyek

Egyik legnagyobb változást az alkalmazás engedélyek módosítása hozta. Ha korábban telepítettél egy appot a Google Play-ről, telepítés előtt engedélyezni kellett az összes – az alkalmazás számára szükséges – hozzáférést, és csak ezután lehetett a telepítést folytatni. Tehát, ha a felhasználó szeretné használni az appot, eddig nem volt más választása, el kellett fogadnia az összes engedélykérést. Sajnos ez biztonsági kockázatot jelent. Főképp, ha az app a felhasználók személyes adataival dolgozik.

Az Android M-től kezdve az alkalmazás engedélyeket két csoportra bontották, [normál](http://developer.android.com/guide/topics/security/normal-permissions.html?ref=blog.fps.hu) és **biztonsági szempontból veszélyes** engedélyekre. A normál engedélyeket az app azonnal megkapja, ezzel szemben a biztonsági szempontból veszélyes engedélyeket, az app futása közben (az adott funkció esetén) kéri a felhasználóktól. Vagyis mostantól le kell kezelned, hogy mi történjen, ha egy implementált funkcióhoz (biztonsági szempontból veszélyes engedélyt igénylő) nem kapsz engedélyt a felhasználótól. Az Android M előtti alkalmazások esetén, ha bizonyos funkcióktól megvonunk engedélyeket, értelemszerűen az adott funkció nem megfelelő működését, bizonyos esetekben akár összeomlását is eredményezheti. Érdemes tehát felkészítened a korábbi appjaid az Android M-en való futtatásra, hiszen ha a felhasználók megvonnak olyan engedélyeket, amelyekkel veszélyeztethetik az app zökkenőmentes működését, azzal a felhasználói élményen esik csorba.

![Permission request](https://blog.fps.hu/content/images/2016/01/gyortea.png)

Az alkalmazás engedélyek később, bármikor módosíthatóak a készülék beállítások menüjében, így felhasználóként egy figyelmetlenségből történő elutasítást később is korrigálhatsz, ha arra a funkcióra mindenképp szükség lenne.

### 2\. Energiatakarékosság, üzemidő javítás

Az Androidos készülékek nagy hányada szenved az egyre kisebb üzemidőtől, amely valljuk be, elég bosszantó. Ennek érdekében tettek lépést a Google fejlesztői két új energiatakarékos mód (Doze, Sandby) bevezetésével, amely nagyságrendekkel megnövelheti az eszközök készenléti idejét.

Számunkra az **Doze mód** az érdekes. Működését úgy képzelheted el, hogy az Android figyeli a készülék mozgásérzékelőjét és amennyiben azt érzékeli, hogy egy ideje nem használod a készüléket, egyszerűen egy ún. „alvó módba” megy át. Valójában „lelövi” a készülék összes háttértevékenységét, vagyis erre az időre

- felfüggeszti az internet kapcsolatot,
- figyelmen kívül hagyja az összes [wake loc](https://developer.android.com/reference/android/os/PowerManager.WakeLock.html?ref=blog.fps.hu)k kérelmet,
- az [AlarmManager](https://developer.android.com/reference/android/app/AlarmManager.html?ref=blog.fps.hu)ben beállított riasztásokat elhalasztja, legalább is a következő időszakig, amíg felébred,
- nem fog WiFi kapcsolat után keresni,
- nem engedi az ún. [sync adaptereket](https://developer.android.com/reference/android/content/AbstractThreadedSyncAdapter.html?ref=blog.fps.hu) futni,
- nem engedi a [JobScheduler](https://developer.android.com/reference/android/app/job/JobScheduler.html?ref=blog.fps.hu)öket futni.

Első hallásra brutális megkötés, hiszen sok app épül arra, hogy a háttérben szinkronizálja magát egy központi adattárral, vagy riasztja a felhasználóját egy beállított dátum előtt stb. Szerencsére a Doze módot úgy alakították ki, hogy bizonyos időszakonként egy rövid időre a rendszer kilép a Doze módból. Ilyenkor minden függőben lévő munkát elvégez, legyen szó akár riasztásról, akár háttérben történő adatszinkronizációról. Viszont ez az időablak, ahogy haladunk előre az időben, mindig egyre távolabb és távolabb helyeződik. Nagyon jól szemlélteti az időablakok elhelyezkedését az következő ábra. 

![Doze mode](https://blog.fps.hu/content/images/2016/01/doze-mode.png)

Mostantól nem építhetsz arra, hogy egy frissítés például 5 percenként le fog futni, ami nem feltétlenül lehet probléma, hiszen ezzel értékes időt nyerünk a készülék készenléti idejének, és valjuk be, amíg a telefon az asztalon hever, nem foglalkozol azzal, hogy vajon frissültek az adatok a készüléken. Vannak esetek, ahol sajnos nem kedvező a Doze mód, lásd riasztások. Az Android se szeretné a fejlesztők kezét teljesen megkötni, így például az említett riasztások esetén is biztosít számodra kiskapukat. Érdemes a funkciód Doze módra történő felkészítése esetén ránézni az Android devportálra, hátha ajánlanak valamilyen megoldást az adott problémára.

Nem maradt más hátra, mint a kilépés a Doze módból, ami értelemszerűen akkor történik, ha a felhasználó ismét elkezdi használni a készülékét, például megmozdítja, vagy feloldja a képernyőzárat, esetleg csatalkoztatja hálózati töltőhöz. Ilyenkor minden alkalmazás végleg kiugrik a Doze módból és újra a normális, korábban megszokott módban működhetnek, mindenféle korlátok nélkül.

Érdekesség, hogy a Google csinált egy kísérletet két Nexus 9-es készülékkel. Az egyik készüléken Android L, a másik készüléken Android M operációs rendszert futtattak. A kísérlet végeredményeként azt tapasztalták, hogy az Android M-es készülék üzemideje kétszer akkora volt, mint az Android L-es társáé, tehát van potenciál az Android M Doze módjában.

A másik energiatakarékos mód (Standby) esetén, az Android a felhasználói szokásokat figyeli, azaz a felhasználó az egyes alkalmazásokat mennyire gyakran használja az adott készüléken. A továbbiakban ezeknek az adatoknak a birtokában dönti el, hogy egyes alkalmazásokat mennyire korlátoz le. A Doze mód esetén említett időablakot itt is használja a rendszer, annyi különbséggel, hogy ebben az esetben csak napi egy ilyen időablak létezik, és az is csak akkor, ha egy alkalmazás elég régóta van már Standby módban. Ebben az esetben az alkalmazások csak hálózati töltő csatlakozását követően léphetnek ki Standby módból.

### 3\. Megszűnik az Apache HTTPClient támogatása

Érdemes elgondolkodni azon, hogy hálózati kommunikációra milyen segéd osztályt is használj a jövőben, ugyanis Android M-től kezdve megszüntetik a HTTPClient támogatását. Helyette a [HttpURLConnection](https://developer.android.com/reference/java/net/HttpURLConnection.html?ref=blog.fps.hu) osztályt favorizálja az Android, mivel sokkal hatékonyabb az Apache megoldásánál, mind a forgalom – lásd válaszok cachelése stb. –, mind pedig energiatakarékosság szempontjából. Ha ezzel mégsem győztek volna meg téged, vagy csak túl nagy meló lenne átírni a korábbi alkalmazásaid, elég csak kiegészíteni a projekted build.gradle álományát az alábbi függőséggel, és mintha mi sem történt volna, továbbra is használhatod az Apache HTTPClient osztályát.

```java

android {  
    useLibrary ‘org.apache.http.legacy’  
}

```

### Újdonságok, érdekességek

A változtatások melletr természetesen jöttek újdonságok is az új verzióba. Itt is pár érdekesebb feature-t gyűjtöttem ki, amelyek egyes esetekben érdekesek lehetnek számodra és a felhasználók számára is egyaránt.

#### 1\. Ujjlenyomattal történő azonosítás támogatása

Végre az Android M-től bekerült egy rég várt funkció, amely a fejlesztők számára számtalan új fejlesztési lehetőséget rejt. Képzeld el a szituációt, hogy akár biometrikus adat segítségével is authetnikálhatod a felhasználóid, hiszen felhasználhatod alkalmazásaidban a készülék ujjlenyomat olvasó funkcióját. Nyilván, hogy ezt kipróbálhasd, a készülékednek támogatnia kell az ujjlenyomat olvasást. A jövőbe egyre több és több ilyen készülék fog megjelenni, köszönhetően a Google elég erőteljes lobbijának és támogatásának. Addig is kipróbálhatod az [Android devportálon található mintakód segítségével](https://developer.android.com/samples/FingerprintDialog/index.html?ref=blog.fps.hu), már ha van hozzá olyan készüléked, amely hardveresen is támogatja az ujjlenyomat olvasást.

![fingerprint](https://blog.fps.hu/content/images/2016/01/fingerprint.png)

#### 2\. Direkt Megosztás

Aki korábban már használt megosztást saját alkalmazásaiban, azok számára érdekességnek számíthat, hogy bevezettek egy új megosztási formát. Android M-től olyan alkalmazásokat is készíthetsz, amelyekből kijelölhetsz más alkalmazásokat, például közösségi alkalmazások (Facebook, Google+, Linkedin, twitter stb.), ahol tartalmakat oszthatsz meg. A megosztás nem a hagyományos módon a felhasználó hírfolyamára történik, hanem direkten egy közösségi partnerének. A példa kedvéért képzelj el egy egy olyan alkalmazást, amely dokumentumokkal dolgozik. Ezen dokumentumokat a felhasználók megoszthatják egy, vagy több ismerősükkel. Erre [egy példát is készített az Android, nézd meg](http://developer.android.com/samples/DirectShare/index.html?utm%5Fcampaign=marshmallow-samples-915&utm%5Fsource=dac&utm%5Fmedium=blog).

![Direct share](https://blog.fps.hu/content/images/2016/01/direkt-megosztas.png)

#### 3\. App Linking

Nagyon hasznos, ha egy webes tartalmat mobilon próbálunk elérni és az egy jól ismert alkalmazáson belül tekinthető meg, a webes böngésző helyett. Ez nem egy újkeletű dolog, ugyanis az említett metológia (deep link) korábban is beállítható volt az alkalmazásokban. Ezt a sztorit továbbpörgette az Android és egy sokkal hatékonyabb megoldást kínálnak a fejlesztők számára, webes tartalmak linkelésére. Igaz még nem sikerült kipróbálnom, de első ránézésre nagy a hasonlóság a [Facebook App Links](http://applinks.org/?ref=blog.fps.hu) megoldásával. Bővebb [leírás a Facebook App Links-ről, olvasd](https://developer.android.com/training/app-links/index.html?ref=blog.fps.hu).

#### 4\. Alkalmazás adatainak biztonsági mentése

Végül a kedvencem, hogy bekerült egy olyan funkció, amivel a rendszer biztonsági mentéseket készít az adott alkalmazás adatairól, beállításairól. Hogy miről készül mentés, az beállítás kérdése. Ezeket a backupokat a rendszer teljes egészében a felhőben tárolja méghozzá úgy, hogy az adatokat a felhasználó Google fiókjához párosítja. Így ha a felhasználó készüléket cserél és újratelepíti az appot, megkímélheted egy újrakonfigurációtól, hiszen a felhőből letölti az app korábbi beállításait, és lényegében ugyanott folyathatja, ahol a másik készüléken abbahagyta. Erről [bővebb információ az android dev portálján, olvasd](https://developer.android.com/training/backup/autosyncapi.html?ref=blog.fps.hu).

Összegezve, az új rendszerrel szemmel láthatóan a stabilitás irányába ment el a Google. Mindenki maga döntse el, hogy mennyire szerethető, vagy sem. Úgy gondolom, hosszabb távon mindenképpen hasznosabb egy stabilabb rendszer, még ha az a korábbiakhoz képest plusz munkával is jár, lásd alkalmazás engedélyek, vagy energiatakarékos mód.
### Nevezzük a nevén: BEM
URL: https://blog.fps.hu/bem-css/
Last updated: 2026-07-17T08:34:57.000Z
Mi is az a [BEM](https://en.bem.info/method/naming-convention/?ref=blog.fps.hu)? A kifejezés egy mozaikszó, mely a Block Element Modifier összetételre utal. Egy módszer CSS osztályaid elnevezésére, amely több jelentést és nagyobb átláthatóságot biztosít más fejlesztők számára. Sokkal informatívabb, ami a BEM elnevezést ideálissá teszi nagyobb projekteken dolgozó fejlesztők számára.

A módszert a Yandex Internetes cég csapata találta ki még 2009-ben, fő céljuk a fejlesztési folyamatok gyorsítása és a fejlesztők közötti csapat munka megkönnyítése volt.

### Minek nevezzelek?

A módszer alapvetése, hogy a felület összetartozó elemeit blokkokba csoportosítva összefogja. Így az elnevezés során, minden elem hordozza magával a blokk nevét is, melyhez tartozik. Ennek teljesüléséhez szeparálnod szükséges a blokk és az elem megnevezését. Erre a dupla aláhúzást határozza meg (\_\_) a módszer. A következő példa jól szemlélteti ezt:

```markup

<nav class="menu__frame">
  <ul class="menu">
       <li class="menu__item">…</li>
       <li class="menu__item">…</li>
   </ul>
</nav>

```

Előfordul, hogy egy adott elem egyes tulajdonságaiban eltér a többitől, ezeket a tulajdonságokat egy módosítóval tudod hozzárendelni, amit egyszerű aláhúzással jelöl (\_). Visszatérve az előző példához, a következőképpen fog kinézni:

```markup

<li class=“menu__item menu__item_current”>…</li>

```

Nem csak egy elem rendelkezhet módosító osztállyal, hanem maga a blokk is, amennyiben az egész blokk megjelenésén szeretnél módosítani.

```markup

<nav class=“menu__frame”>
   <ul class=“menu menu_hidden”>…</ul>
</nav>

```

A BEM kétféle módosítót különböztet meg, logikai (block-name\_mod-name) és kulcs-érték típusú módosítókat (block-name\_mod-name\_mod-value). Előbbi megmutatkozik a fenti példában, a kulcs-érték típusú pedig így néz ki:

```markup

<nav class=“menu__frame”>
   <ul class=“menu menu_theme_morning-forest”>…</ul>
</nav>

```

Amit érdemes még megemlíteni, az a prefix-ek használata. A BEM ugyanis meghatároz négy használható előtagot, melyek az osztály jellegére utalnak:

- **b**\-class-name: blokk
- **h**\-class-name: pisztolytáska (holsters), több összetartozó elem összekapcsolására használható
- **l**\-class-name: layout
- **g**\-class-name: globális stílusok

```markup

<nav class=“b-menu__frame”>
   <u class=“b-menu”>…</ul>
</nav>

<section class=“g-cleared-container”>…</section>

```

![BEM](https://blog.fps.hu/content/images/2015/12/bem.png)

Természetesen van néhány alapvető megkötés, melyeknek meg kell felelned az osztályok elnevezése során, ezek a következők:

- az elnevezés számokból és kisbetűs latin karakterekből állhat
- az egybefüggő szavakat kötőjellel választhatod el (-)
- a blokkok, elemek és módosítók elnevezésének mindenképp beszédesnek és informatívnak kell lennie

### Ahány ház, annyi szokás

Több alternatív elnevezési séma létezik, melyek mind a BEM módszerben meghatározottakon alapulnak.

Az egyik – talán legelterjedtebb – a [Harry Roberts’ style](http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/?ref=blog.fps.hu), mely a következő mintát követi: *block-name\_\_elem-name–mod-name*. A legfőbb eltérés, hogy a logikai módosítókat két kötőjellel (–) jelöli, illetve a kulcs-érték módosítók használatát elhagyja.

A legegyszerűbb alternatíva a **CamelCase style**, amiről a neve szinte mindent elárul. Az egybefüggő szavak szeparálására kötőjel helyett CamelCase-t használ.

Egy másik stílus az úgynevezett **“Sans underscore” style**, amely a szóösszetételek elválasztását a CamelCase style-hoz hasonlóan határozza meg. A blokkok és elemek szeparálására kötőjeleket használ (-), és a módosítókat Harry Roberts’ style alapján definiálja, azzal a kivétellel, hogy kulcs-érték módosítókat is használ. Így a minta a következőképpen fog kinézni: *blockName-elemName–modName–modValue*.

Ahogy az elnevezési sémára, úgy a prefix-ekre is születtek alternatívák. Közülük, amit a leghasznosabbnak találok, azok az állapotjelzők, melyeket egy *is-* előtag jelöl. Ezekhez az osztályokhoz állapotokat köthetsz pl.:

```markup

<nav class=“mobile-navigation is-active”>…</nav>

```

```css

.mobile-navigation {
   display: none;
}
.mobile-navigation.is-active {
   display:block;
}

```

Személy szerint a legbarátságosabb sémának a Harry Roberts féle stílust találom, úgy gondolom, hogy mindenki szabadon kiválaszthatja a neki megfelelőt, vagy saját kénye-kedve szerint alakíthat ki egy új sémát, más jelölési rendszerrel, ami egyedülálló, de következetesen érvényesíti a BEM szemléletmódját.

Mindazonáltal, ne felejtsd el, hogy ebben a kérdésben a csapatnak kell konszenzusra jutnia, hisz a fő cél, a csapatmunka megkönnyítése.

### Miért használnám…

… egyébként is ronda. Azt hiszem talán ez az egyetlen negatívum, ami a BEM ellen szól. Bár az is igaz, hogy ezt szinte minden bejegyzés, vagy cikk ki is emeli, ami a témáról ír.

Első benyomásom nekem sem volt másképp, az alulvonással jelölt szerkezetekkel és hosszú osztály nevekkel mondhatni nehezen sikerült megbarátkoznom, de úgy gondolom, hogy a megannyi előnyéért érdemes megkötnöd ezt a kompromisszumot.

#### Rendben, de mik is ezek az előnyök?

**A BEM módszert követve**

- elkerülheted a leszármazottként történő hivatkozásokat
- elkerülheted azt is, hogy a későbbi módosítások rákényszerítsenek kilométer hosszú szelektorok írására
- végül elkerülheted, hogy a CSS tulajdonságok *!important*\-tal küzdjenek meg egymással az életben maradásért.
- az osztályaid egységet képezve sokkal átláthatóbbá teszik CSS kódod és nem mellesleg a HTML-ben felépített struktúrát is.
- a kódod sokkal átláthatóbbá válik, az idő folyamán törlésre kerülő blokkokhoz tartozó osztályok könnyen azonosíthatóvá válnak, így a kódbázisod nem válik robusztussá.
- a blokk név jelölésével kikristályosodnak az osztályok közötti függőségek is. Például egy *list\_\_item* osztály esetén tudod, hogy függ a *list* osztálytól.
- sokkal bátrabban fogsz a meglévő kódodhoz nyúlni, hiszen egy sor átírása után nem kell azzal szembesülnöd, hogy megváltoztak olyan elemek is, amelyekhez hozzá sem szerettél volna nyúlni.

### BEM\_\_preprocessor–sass

Aki már használt CSS preprocessorokat, annak nem kell bemutatni számtalan előnyét. Ezek közül az úgynevezett Nesting az, amit szeretnék kiemelni, mivel használatával még átláthatóbbá teheted a CSS kódodat, mégpedig így:

```css

CSS
.article {…}
.article__title {…}
.article__lead {…}

SCSS
.article {
   […]
   &__title {…}
   &__lead {…}
}

```

Találkoztam már olyan megoldással, amely Mixinek használatával határozta meg az osztály neveket. Erről a [css-tricks.com-on](https://css-tricks.com/snippets/sass/bem-mixins/?ref=blog.fps.hu) többet is olvashatsz. Személyes véleményem az, hogy a BEM és a Mixenek együttes alkalmazása feleslegesen túlbonyolítja a kódot, illetve annak átláthatóságát rontja. Ezzel pont a BEM egyik fő célja sérül.

### Végszó

A BEM egy hasznos és hatékony módszer. Mi sem bizonyíthatná jobban, hogy egyre több projektben tűnik fel. Jó példa rá a [BBC weboldala](http://www.bbc.com/?ref=blog.fps.hu), vagy a [Drupal 8](https://www.drupal.org/node/1887918?ref=blog.fps.hu). Használata egyszerű, bevezetése időigényes, viszont ez az idő mindenképp megtérül a projektek során, így mindenkinek csak ajánlani tudom használatát.
### Légy natív naiva
URL: https://blog.fps.hu/nativ-js-rulez/
Last updated: 2026-07-17T08:35:06.000Z
Bevezetésként fontosnak tartom leírni: szó sincs róla, hogy a jQuery ellen lennék. Nagyon jól kitalált keretrendszer, ami jelentősen megkönnyíti a fejlesztők életét és hatékonnyá teszi a munkát. A poszt tartalmát sem arra szeretném kihegyezni, hogy mindenképp cseréld le, csupán arra akarok rávilágítani, hogy vannak alternatívák, és a kevesebb néha bizony több.

Számos blog poszt látott napvilágot, melyekben a jQuery-hez hasonló libeket mutatják be, táblázatos összehasonlításban, azok előnyeivel és hátrányaival egyetemben, sőt azokból is akad (én magam is írtam: [jQuery kód optimalizálása címmel](https://blog.fps.hu/jquery-kod-optimalizalas-javascript/)), melyek a [natív megoldásokat](http://youmightnotneedjquery.com/?ref=blog.fps.hu) mutatják be. Most kicsit más irányból közelítem meg a témát, és felmerült bennem az ötlet, hogy megvizsgálok jó pár oldalt és összeszedem, mik azok a jQuery metódusok, amiket a legtöbbször használnak a fejlesztők.

### „Így írtok ti”

A vizsgált oldalak az [Alexa Magyarországra vonatkozó leglátogatottabb oldalak](http://www.alexa.com/topsites/countries;0/HU?ref=blog.fps.hu) listájából kerültek ki, a külföldi oldalakat mellőzve. 50 oldalt emeltem ki, amik használnak is jQueryt, ezek listáját [ebben a gistben találod](https://gist.github.com/totya24/676aa85805504cfa318c?ref=blog.fps.hu). Annál lustább vagyok, minthogy egyenként végignézzem az egyes JavaScript fájlokat, így írtam rá egy gyors [scriptet](https://gist.github.com/totya24/08d7ff81bbf0a588bced?ref=blog.fps.hu), ami korántsem tökéletes, viszont a tesztelt oldalakon a valóságnak megfelelő eredményeket adott vissza.

Az 50 legtöbbször használt jQuery metódus (a vizsgált oldalak tekintetében) a következő:

![jQuery használati lista](https://blog.fps.hu/content/images/2015/12/kep.png)

Noha 50 oldal vizsgálata nem ad reprezentatív statisztikát, szinte biztos vagyok abban, hogy még több oldal esetén sem változna jelentősen az első 10 helyezett.

Az eredmény azért is lehet érdekes, mert azt tükrözi, hogy számos fejlesztő leginkább alapvető DOM manipulációra és tulajdonságok kinyerésére használja a jQuery függvénytárat. Valljuk be, hogy ilyen alapvető dolgokhoz talán túlzás behúzni egy akár [100Kbyte méretet is meghaladó](https://mathiasbynens.be/demo/jquery-size?ref=blog.fps.hu) külső libraryt.

Tapasztalataim alapján sokszor az is közrejátszik, hogy a jQuery használata egyfajta megszokássá vált, nem is mérlegeled, valóban szükség van rá, hiszen a számos boilerplate és kiinduló projekt alapértelmezetten tartalmazza, és ha már ott van, akkor rutinszerűen azt használod. Kényelmes, hiszen egyszerű a használata, ha valami bonyolultabb megoldásra van szükség, elég csak böngészni a pluginek között és biztos találsz valami számodra használható megoldást, amit esetenként kisebb-nagyobb workaroundok alkalmazásával működésre bírsz.

Az sem elhanyagolható, hogy a front-end álláshirdetések 90%-a feltételként vagy előnyként hozza fel a jQuery ismeretét, így kijelenthető, hogy általánosan elfogadott és elvárt a függvénytár ismerete, ami mára már idejétmúlt hozzáállást képvisel. Legalábbis számomra.

### Böngészőkompatibilitás

Évekkel ezelőtt még komoly kihívást jelentett az egyszerűbb JavaScript metódusok cross-browser használata, köszönhetően leginkább az Internet Explorer és Safari sajátos megoldásainak, amelyek egy része még ma is aktuális, ám a böngészők fejlődése eljutott oda, hogy jelentősen csökkent a szükséges hackek száma. Sokan ezért is választották a jQuery-t (többek között én is), mert egyszerű és gyors megoldást adott a fenti problémák áthidalására.

Azonban jó pár éve léteznek egyszerű megoldások, [polyfillek](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills?ref=blog.fps.hu) az egyes fallbackek lekezelésére és a JS motorok sajátosságainak kiegyenlítésére. Ezeket a [megoldásokat](https://github.com/inexorabletash/polyfill?ref=blog.fps.hu) egyszerűen elérheted és összeválogathatod, hogy a fejlesztéshez szükséges metódusok minden böngésző alatt rendelkezésre álljanak.

### Alternatív keretrendszerek

Tagadhatatlanul kényelmesebb és célravezetőbb megoldás, ha bonyolultabb dolgokat is el akarsz érni, hogy komplett keretrendszert használj a projektjeidben. Ha nem ragaszkodsz a jQueryhez, számos kisebb méretű, de ugyanolyan hatékonyan használható library áll rendelkezésre. Régóta létező lehetőség a [Zepto.js](https://github.com/madrobby/zepto?ref=blog.fps.hu), kicsit újabb, de szintén felkapott megoldás a [Sprint.js](https://github.com/bendc/sprint?ref=blog.fps.hu), de kedvedre válogathatsz a neked megfelelő libek közül a kifejezetten ilyen célra létrehozott [gyűjtőoldalon](http://microjs.com/?ref=blog.fps.hu) is.

Nem egy projekt során tapasztaltam, hogy ha az elején kijelentettük, hogy nem akarunk jQuery-t használni, viszont tudtuk, hogy mire van szükség (DOM manipuláció, AJAX, modal stb.), gyorsan össze lehetett válogatni a függvénytárakat, amiket gond nélkül használtunk a fejlesztés során. És minden esetben kisebb kódbázissal és fájlmérettel értünk a végére, mintha a jQuery valamelyik verziójára esett volna a választás.

### Légy natív!

Majdnem két éve egy meetupon szegezték nekem a kérdést, hogy miért vagyok annyira a jQuery ellen és miért furcsállom, hogy mindenhol kiemelik az ismeretének szükségességét. Akkor is azt mondtam, hogy kicsit aggasztónak találom, amikor egy kezdő fejlesztő a JavaScript nyelv tanulásakor rögtön a jQuery-t veszi kiinduló pontnak (találkoztam ilyen esettel nem is egyszer). A véleményemhez mára méginkább ragaszkodom, hiszen a JavaScript egyre inkább elterjedt és közkedvelt nyelv lett, felhasználása pedig már régóta nem arra korlátozódik, hogy a weboldaladon megjeleníts, vagy eltüntess egy elemet (elég csak az Angular, node.js, React.js, npm csomagok használatára gondolni).

Ha jQuery után a navít JS használata mellett döntenél, kiváló kiindulópont a [youmightnotneedjquery.com oldal](http://youmightnotneedjquery.com/?ref=blog.fps.hu), ahol konkrét kódrészletek formájában kaphatsz segítséget az egyes metódusok átírásához.

Összegezve a fentieket, csak ajánlani tudom, hogy mélyedj el a JavaScript nyelv szépségeibe (és sötét bugyraiba), és amikor csak lehet a natív megoldásokat alkalmazd. Úgyis olyan felkapott a „kézműves” jelző, miért ne lehetne a te kódod is az ;)
### Hogyan változtatja meg a tartalom előállítást a mobil egyre nagyobb térnyerése?
URL: https://blog.fps.hu/mobil-es-a-tartalom-eloallitas/
Last updated: 2026-07-17T08:35:18.000Z
Az elmúlt három-négy évben sokszor hallhattuk, hogy ez a mobil éve, illetve a következő év már biztos a mobil éve lesz. 2015-ben szerintem már kijelenthetem, hogy ez már tényleg a mobil éve. Miért gondolom mindezt? 

Az idei [Internet Hungary](https://www.internethungary.com/?ref=blog.fps.hu "Internet Hungary web site")\-n erről a témáról tartottam előadást.

Januárban a [Pew Research](http://www.journalism.org/2015/04/29/state-of-the-news-media-2015/?ref=blog.fps.hu "Pew Research tanulmány") az USA-ban vizsgálta, hogy mennyien olvassák a különböző híroldalakat mobil eszközról. 50 vezető híroldalt vizsgáltak, ebből 39 esetében nagyobb volt a mobilos forgalom, mint a desktopos. Áprilisban a Google lefuttatta a köztudatban [mobilbarát](http://googlewebmastercentral.blogspot.hu/2015/04/faqs-april-21st-mobile-friendly.html?ref=blog.fps.hu "Google mobilbarát algoritmus frissítés") néven emlegetett algoritmus frissítését, melynek lényege, hogy azokat a weboldalakat, amelyeknek nincs mobilbarát verziója, hátrébb sorolja a mobilos keresési találati listán. Májusban szintén a Google háza tájáról érkezett a [bejelentés](http://searchengineland.com/its-official-google-says-more-searches-now-on-mobile-than-on-desktop-220369?ref=blog.fps.hu "Google bejelentés a mobil keresésekről"), hogy immár 10 országban, köztük az Egyesült Államokban és Japánban már meghaladja a mobilról indított keresések száma a desktoposat. 

A mobil ma már mindenhol jelen van, része az életünknek. Bárhol, bármikor tudunk tartalmat fogyasztani. Világviszonylatban mintegy három milliárd mobil eszköz van forgalomban, ennek kétharmada okostelefon, egyharmada tablet. Egy idei, az NMHH részére készített [tanulmányból](http://nmhh.hu/dokumentum/166308/internet%5F2014%5Fwebre.pdf?ref=blog.fps.hu "NMHH tanulmány PDF-ben") kiderül, hogy a magyar 14 évnél idősebb internethasználók 59%-a rendelkezik okostelefonnal, és 22% él tablettel rendelkező háztartásban. Ezeket az eszközöket több mint 80%-ban használják internetezésre is.

### Hogyan változtak meg a tartalomfogyasztási szokások a mobil jelenlétével?

Mobilon [többféleképpen fogyasztunk tartalmat](http://rabbitblog.hu/2015/09/24/ha-eddig-nem-foglalkoztal-a-mobillal-most-fogsz/?ref=blog.fps.hu): útközben navigálunk a segítségével, híreket olvasunk, social médiát használunk, játszunk, emailezünk, munkahelyen a munkához vagy a privát dolgokhoz, este pedig multi-screenként tévénézés közben. Nemcsak böngészünk, hanem applikációkat is használunk. A magyar felhasználók elsősorban Facebookot használnak, Vibert, valamilyen időjárás appot, FB messengert és Youtube-ot. Kategóriákat tekintve játékokat, valamilyen social appot és időjárást. A Gemius adatai alapján a mobil eszközök esetében a reggeli és esti időszak kiemelkedő, a használat intenzitása szerint a reggel inkább az okostelefonoké, míg az este a tableteké. 

### Miben más mobilos tartalom a desktoptól?

Egy-két éve még gyakran előfordult, hogy a mobilos verzió „butított” volt, rövidebb szövegekkel, részleges funkcionalitással. Ez eleve rossz hozzáállás volt, ugyanis nem eszközre készítünk tartalmat, hanem a felhasználóknak, akik minden szolgáltatást és tartalmat szeretnének elérni függetlenül a használt technológiától. Ma már szerencsére egyre ritkábban találkozom ilyen oldalakkal.

A mobil eszköz sok szempontból más, mint a desktop: kisebb a kijelző, a linkekre/gombokra tappolunk nem kattintunk, beépített billentyűzetet használunk, ami nehézkesebb, mint a normál billentyűzet használata, figyelnünk kell az akkumulátor élettartamára és még sorolhatnám. A fizikai korlátokból és a használati helyzetből adódóan is másképp viselkedünk mobilon. Másképp használjuk és sokkal többet a keresőt (a mobilról indított keresések 40%-a lokális jellegű), más szavakkal, kifejezésekkel keresünk, másképp jutunk egyik tartalomról a másikra (hivatkozásokon illetve keresőn keresztül). Ezen korlátoktól függetlenül viszont ugyanazt a felhasználói élményt kell nyújtanunk, mint desktop esetén.

### Mire kell figyelni, ha mobilra készítünk tartalmat?

![Wikipedia Dr. House szócikke desktopon és mobilon](https://blog.fps.hu/content/images/2015/12/dr_house.gif)

Az eszköznek megfelelő megjelenítés nagyon fontos. A mobile first elvet alkalmazzuk tervezéskor. Technológiailag ez többféle lehet: responsive design, szeparált oldalak (m.valami.hu) natív applikációk. 

**Megjelenésben:**

- jól olvasható, kontrasztos, jól áttekinthető
- a kijelző méretének megfelelő betű és képméret
- a szövegek megfelelően legyenek tagolva, rövidebb bekezdések, közcímek
- jól tappolható gombok, linkek
- különösen fontos az oldalbetöltődési sebesség (3 másodperc)

**Szövegezésben:**

- minőségi tartalom (egyedi, nem összeollózott; érthető megfogalmazás; megbízható)
- keresőoptimalizált (szeparált oldalaknál a link átirányításokra illetve a canonical tagekre figyelni kell, natív appoknál már lehet az app indexinget használni a deep linkekre)
- legyenek kulcsszavas közcímek (nem olvasunk, hanem scannelünk, ezért fontos)
- lokális keresések miatt mikroformátumok használata javasolt

A tartalom előállításnál MINDIG a felhasználó legyen a központban, akit eszköztől függetlenül kell a megfelelő információval kiszolgálni.

Összegzésként elmondhatom, hogy figyelni kell a mobilra, de jelentősen nem változtatta meg a tartalom előállítási szokásokat. Ám a technológia folyamatosan fejlődik, jönnek az új eszközök, amelyek viszont alapjaiban változtathatják meg a tartalom előállítást. Én már várom ☺
### Third-party JS
URL: https://blog.fps.hu/third-party-js/
Last updated: 2026-07-17T08:35:28.000Z
Gyakran van arra szükség, hogy third-party alkalmazásokat integrálj az oldaladba. Remarketing, mindenféle analitika, különböző mérések, adserverek kódjai stb. Hasznos eszközök ezek és óriási szükség van rájuk, viszont már nem először futunk problémába. Most éppen egy remarketing kód okozott galibát.

Történetesen ugyanazt a JavaScript változót használja a befűzött harmadik féltől származó JS kód, mint amit maga a web site is. A kódot behúzva a site fontos funkciói nem működnek. Azt gondoljuk, hogy a third-party JS-ek fejlesztőinek kell felkészülnie erre a lehetőségre, azaz nekik kell olyan kódot írni, ami biztosan nem fog ütközni a befogadó oldalak kódjával. De hogyan lehet ezt elérni?

A probléma egyébként abból fakad, hogy mindkét fél nagyon helyesen minimalizálja a JS kódját (minify). A minify-oló eszközök pedig lecserélik a változók neveit a lehető legrövidebbekre úgy mint a, b, c, d… Ha a minify mindkét oldalon megtörténik, elő is áll(hat) az ütközés a nem várt eredményekkel. Még egyszer: a third-party fejlesztőinek kell ezzel kezdeniük valamit. Két lehetőség van az ütközések elkerülésére.

### Hosszabb, beszédes és egyedi változó nevek használata.

Például:

```javascript

var google_conversion_id = 978986647;

```

Igen nagyobb méretű lesz a JavaScript, de legalább nem lesz ütközés.

### Objektumba foglalja a kódját.

Pont úgy, mint ahogy például a Google teszi. Azzal, hogy minden funkció és változó egy objektumon keresztül érhető el, tulajdonképpen egy névteret hoz létre, ezzel jócskán csökkentve a más kóddal történő összeakadás esélyét.

```javascript

var namespace = {
       func: function() { … },
       value: 123
   };
namespace.func();

```

Ez a poszt egy kérés, hogy egyszerűbb legyen mindenki élete. Szándékosan nem írtuk a szolgáltatást, ami a gikszert okozta és ne is kérdezd. Kommentben írjátok meg, ha már volt hasonló kellemetlenségetek!
### API és frontend hatása az üzemeltetésre
URL: https://blog.fps.hu/api-frontend-uzemeltetes-devops/
Last updated: 2026-07-17T08:35:37.000Z
Számos belső problémával néznek folyamatosan szembe az IT cégek. Az egyik ilyen nagy fontosságú probléma, az ős ellenségek – a fejlesztők és a rendszergazdák – ellentéte. A két külön munkakör emberei nehezen értik meg egymást, egyszerűen azért, mert mások az érdekeik, céljaik.

A technológiai fejlődéssel egyre olcsóbban egyre több erőforrás áll rendelkezésünkre, a fejlesztők és az általuk használt megoldások kicsit elkényelmesedtek, pazarlóbbak lettek. *„Elfér még az a pár felesleges objektum a memóriában, majd később optimalizáljuk, vagy veszünk még memóriát a vasba”* mondják, vagy gondolják a fejlesztők. A másik véglet a rendszergazdák, üzemeltetők, akik ezeknek a plusz memóriáknak a kiosztását és beszerzését is intézik többek között. Az ő mondásuk rendszeresen a manapság divatos minimalizmusra épít, *„minek csili-vilinek lenni, parancssorban is működik gond nélkül, és különben is, lehet még ott egy pár byte-ot faragni”*. A fejlesztő szeret minél magasabb szintű nyelven, minél könnyebben programozni, a rendszergazda szeret minél egyszerűbb, hatékony alkalmazást üzemeltetni.

### DevOps

A kommunikációból adódó nehézségek szülték a DevOps fogalmát (developer and operator), akik olyan emberek, akik ugyan nem hardcore coderek, vagy a legszebb felületet programozzák, és nem a legjobb üzemeltetők, akik a legnagyobb szabású infrastruktúrát rakják össze és működtetik, de mindkét világban jól elboldogulnak, beszélik mindkét nyelvet, ezzel hozva hatékonyságot a szervezetek életébe.

Fontos, hogy egy devop tud segíteni mindkét csapatnak akár egy tervezési folyamatban, vagy egy krízishelyzet kezelésekor, jelezve az adott csapatnak, hogy *„hé fiúk a másik csapatnak ezzel nagy fejfájást fogtok okozni”*. A tervezést fontos kiemelni, hisz nem csak azt kell megmondani, hogy egy gomb piros vagy zöld legyen, hanem hogy az a gomb mit és hogyan fog működni, milyen folyamatok játszódnak le a hatására. Egy nagy csapatmunka, ahol minden szereplő véleményét meg kell hallgatni, hogy senki érdeke ne sérüljön, vagy legalábbis egyenlő mértékben sérüljön, ne boruljon fel a kényes egyensúly. Fel kell mérni mire van tudásbeli erőforrás, a projekt milyen eszközöket igényel, és ennek a legoptimálisabb metszetét kell megtalálni.

A nem megfelelő eszközök használatából adódó hibákat a legnehezebb kijavítani vagy korrigálni. Nem utolsó sorban tudni kell, mit szeretne az ügyfél. Biztos mindenki találkozott már azzal a vicces képsorozattal, hogy egy projectben résztvevők hogyan képzelik el az ügyfél kívánságait. „Ne tervezzünk űrhajót, ha az ügyfélnek egy kenura van szüksége és pénze.”

[![Klasszikus hinta példa egy projektre](https://blog.fps.hu/content/images/2015/12/Tree-Swing-Cartoon.png)](http://www.moderntoad.com/2012/01/16/6/?ref=blog.fps.hu "Kép forrása")

Két személyesen is érintett esettanulmány is alátámasztja, hogy a fejlesztési projektek nem mindig mennek simán.

#### Első eset

Tipikus eset, hogy mindenki minden adatot most és rögtön, de minimum azonnal akar. Ez az üzemeltetők és a beszerzők rémálma. Nincs az a szerver, amit ne lehetne valós idejű adatokkal túlterhelni.

Felötlik egy szuper ötlet, gyönyörű szépen megtervezik a designerek és UX-esek, a fejlesztők kitalálják hogyan fog működni, nekik ezt hogy a legegyszerűbb megvalósítani. Még API-t is terveznek hozzá, meg mobil alkalmazást. Minden adott a nagy sikerhez. Elkészülnek, tesztelgetik, szépen is működik… a fejlesztői teszt hálózaton 10 felhasználóval. Az üzemeltető megkapja parancsba, kész a következő világsiker, indítsuk hát el. Jön az első éles bevetés, készül mindenki a hatalmas sikerre, a sok munkaóra gyümölcsének learatására. Aztán a rendszer hirtelen összeomlik. Nincs gond, mindenkivel megesik, Microsoftnál is volt már kékhalál promo workshopon. Leporolás, újraindítás, a hatás ugyanaz. A mobileszközök miatti minimalizálás és a folyamatos valósidejű adatok kiszolgálása miatt az erőforráshasználat kritikusan eltolódott a szerver felé. Felbillent az egyensúly.

Nincs mese, le kell mondani bizonyos megoldásokról, terhelési hatásokat kell gyorsan átcsoportosítani. Gyorsítótárazni kell az adatokat, így nem lesz minden teljesen valós idejű, lehet késik 1–2 percet az adat. A mobil appok túlságosan vékony kliensek lettek, le tudnak tölteni még pár kB-ot és tudnak azok is számolni, nem kell mindent készen kapniuk. Vékony kliens készítésekor, amit megspórolunk a klienseken, azt a szerver oldalba kell beépíteni. Bizonyos dolgokat viszont nem lehet kijavítani. Ha valami, pl. egy API nem eseményvezérelten került kialakításra, hanem spagettikóddal, azon csak a teljes újraírás segít.

#### Második eset

A másik esettanulmány is a túl vékony kliens hibáját követte el. A valós idejű adatok kezelése ebben az esetben jobban átgondolt volt, viszont a vékonykliensnek ténylegesen csak megjelenítő szerepe volt. Szerencsére ennél a projektnél megmutatkozott a tesztek fontossága, hiszen az első terhelésteszteknél megmutatkozott, hogy hiába gyors a backend önmagában, és hiába gyors a frontend önmagában, a frontend irányából érkező hatalmas mennyiségű és szekvenciális API hívás nagyban le tudja lassítani a működést.

Ezen három dologgal lehetett segíteni. Egyrészt nem csak az emberek felé kell cache-elni, hanem a két rendszer közötti kommunikációt is célszerű gyorsítótárazni, így nem kell folyamatosan a háttérrendszer felé nyúlkálni adatokért. Másrészt a frontend gyorsítását el lehet érni bizonyos fokú párhuzamosítással, amivel egy-egy adott esetben blokkoló hívást ki lehet kerülni. Végül pedig az előző esetben is említett megoldás, a vékony kliens kicsit „vastagítása”, némi terhelés áthelyezése a frontend részére.

Az esetekből is látszik, hogy fontos a részlegek közötti hatékony kommunikáció, és nem csak 1–1 ember vagy részleg érdekeit kell szem előtt tartani, mert megbosszulja magát a projekten megspórolt idő.
### Webappok és offline működés
URL: https://blog.fps.hu/web-app-offline-mukodes-appcache-local-storage/
Last updated: 2026-07-17T08:35:49.000Z
Az offline elérhetőséghez szükséges appcache technológia már évek óta elérhető és használják is, ám az utóbbi időben került előtérbe és kezdett népszerűvé válni. A webappok elterjedésével egyre gyakrabban felmerül az igény is, hogy a webes szolgáltatás ne csak online legyen elérhető, hanem akár internet hiányában is használható legyen.

### Miért lehet rá szükséged?

A webalkalmazások offline elérésével függetlenítheted alkalmazásod az internetkapcsolattól. Kevésbé gyakran változó adatok esetén kifejezetten előnyös (pl. menetrend, egyéb információs appok), hiszen ha van internet, akkor ellenőrzöd van-e változás, ha pedig nincs, akkor a felhasználók gond nélkül elérhetik a már meglévőket. Az appcache használatával ugyanakkor jelentősen gyorsíthatod a működést is, növelve ezzel a felhasználói élményt, ráadásul a kevesebb hálózati lekérés által még a telefon üzemidejének is kedvezel.

### Mikor érdemes alkalmaznod?

Alapvetően webalkalmazások esetén lehet ideális a módszer, viszont érdemes egy oldalt használó statikus oldalaknál is alkalmazni sebesség optimalizálás céljából. HTML5 játékok esetén kifejezetten ideális, hiszen ha minden függőséget lecache-elsz, és a főoldalra kiteszed az elérést, bármikor elérhetővé válik az alkalmazás. Minél több a dinamikus adat, annál kevésbé ajánlott a használata, hiszen van egy szint, amikor el kell fogadnod, hogy csak online módon használható a termék.

A mobilos böngészők nagy része már a kezdetektől támogatja az egyes oldalak főoldali elérését, sajnos a Chrome for Android csak 2015\. áprilisától (42.0.2311 verzió) tette lehetővé. Ez azért lehet érdekes és fontos, mert sokakban fel sem merült, hogy valami offline módban is működhet, amíg a szokásos „megnyitom a böngészőt és beírom az url-t” módon érte el azt.

![Mobilon főoldalra app ikon](https://blog.fps.hu/content/images/2016/01/webapp.png)

### Hogyan kezdj hozzá?

A folyamatot három részre lehet bontani:

**Statikus elemek lekezelése:** A futáshoz szükséges HTML, CSS, JavaScript fájlokat egyenként megadod a böngészőnek és kényszeríted rá, hogy mentse le őket az appcache tárolóba. Ide tartozhatnak még a webfontok, sprite-ok és egyéb képek is.

**Dinamikus tartalmak kezelése:** A webappod jellemzően távoli, API-tól kapott adatokkal dolgozik, melyek XML, JSON, esetleg CSV formátumban jutnak el az apphoz. Értelemszerűen internet kapcsolat nélkül ezek nem állnak rendelkezésre, így gondoskodnod kell a tárolásukról.

**Offline működés biztosítása:** Az alkalmazásnak le kell kezelni azt a helyzetet, ha nincsen internet kapcsolat és ilyenkor mindent abból kell megoldanod, amit letárolt.

### Statikus elemek

Ugyan a böngészőnknek van saját gyorsítótára, melyet minden oldal megtekintéskor igénybe vesz, viszont ez elég labilis és sok tényezőtől függhet a hatékonysága. A HTML5 bevezetésével elérhetővé vált az [application cache](http://www.html5rocks.com/en/tutorials/appcache/beginner/?ref=blog.fps.hu) interfész, ami kifejezetten hosszútávú tárolásra ad lehetőséget, jó pár extra tulajdonsággal.

A működés lényege, hogy létrehozol egy manifest fájlt (lehetőleg .appcache kiterjesztéssel), ami a következőket tartalmazhatja:

```
CACHE MANIFEST  
#v1.0 

CACHE:
index.html
script.js
style.css

NETWORK:
login.php

FALLBACK:
/user/*.jpg img/user.jpg

```

Minden esetben az első sorban szerepelnie kell a **CACHE MANIFEST** leírásnak, ami jelzi a böngészőnek hogyan kell feldolgoznia a tartalmakat.

**Fontos, hogy ha módosítod a letárolandó fájlok tartalmát, a böngésző nem fogja automatikusan lehúzni a frissebb verziót.** Ellenben, ha bármilyen változást észlel az appcache fájlban, akkor minden abban felsorolt fájlt újrahúz. Erre a legpraktikusabb megoldás a második sorban elhelyezett megjegyzés, ami egyfajta verziózásnak felel meg.  
Érdemes még megemlíteni ezzel kapcsolatban, hogy emiatt az apró macera miatt ajánlott az appcache bevezetését a projekt legvégére hagyni, hogy ne kelljen minden egyes módosítást külön lekezelni.

Ezután minden appcache fájlban három szekciót lehet elkülöníteni és használni.

A **CACHE** szekcióban felsorolt fájlokat a böngésző automatikusan letölti, tárolja, és minden esetben elsőként a tárolt verzióhoz nyúl az online elérés helyett.

A **NETWORK** szekció tartalmazza mindazon url-eket, amiket mindenképp online kell meghívnia az appnak. Amennyiben a CACHE szekcióban konkrétan felsoroltad az összes letárolandó fájlt, a „\*” szabály lekezel minden, előzőleg nem említett hívást.

A **FALLBACK** szekció olyan (akár wildcard jellegű) url párokat tartalmaz, melyek offline módban kerülnek feldolgozásra. Az első tag megadja, hogy mit figyeljen, a második (space után) pedig, hogy mire hivatkozzon abban az esetben. A példa kódban minden felhasználó profilkép lekérésekor ugyanazt az user.jpg fájlt fogod visszakapni. Nem elhanyagolható tényező, hogy kizárólag ugyanarról az url-ről tudsz fallback szabályokat definiálni, ahol a manifest fájl is található!

Az appcache alkalmazása előtt érdemes átrágni magad a konkrét működésén, mert egy rosszul megírt manifest file lelassíthatja és megnehezítheti a későbbi munkát. [Ajánlom ezt az oldalt](http://appcache.offline.technology/?ref=blog.fps.hu) kiindulásnak.

![network](https://blog.fps.hu/content/images/2016/01/network.png)

### Dinamikus tartalom

Amennyiben dinamikus tartalmakat akarsz megjeleníteni, melyek egy API-tól jönnek (elmenteni egy játék eredményeit, vagy bármilyen beállítást), nem tudod elkerülni a [HTML5 webstorage](http://www.html5rocks.com/en/features/storage?ref=blog.fps.hu) használatát. Több alternatíva is adott, viszont a támogatottságok itt már eléggé meghatározzák, hogy mit érdemes konkrétan igénybe venni. Ezeket most nem részletezem, inkább az általam preferált megoldást emelem ki.

A Mozilla létrehozott egy zseniális libet, ami megoldást nyújt minden storage technológiákkal kapcsolatos bizonytalanságra. A [localForage](http://mozilla.github.io/localForage/?ref=blog.fps.hu) böngészőtől függően kiválasztja a megfelelő drivert és azt használja, ráadásul aszinkron módon, ami szintén fontos az adatok megfelelő kezelése szempontjából. A használata majdnem megegyezik a localStorage szintaktikájával, azzal a lényeges különbséggel, hogy konkrétan visszakapod az adatot, amivel dolgoznod kell.

```javascript
// localStorage használatával
localStorage.setItem('key', JSON.stringify('value'));
doSomethingElse();

// localForage esetén használhatunk callback függvényt:
localforage.setItem('key', 'value', doSomethingElse);

// vagy "promises" megoldást:
localforage.setItem('key', 'value').then(doSomethingElse);

```

### Működési logika

A fenti technológiák alkalmazásával elérheted, hogy minden szükséges adat le legyen tárolva kliens oldalon, viszont fontos része a működésnek a szinkronizálás és a kettéválasztott működés. Tapasztalataim szerint, a legjárhatóbb út, ha az API hívásokat lehetőleg egy helyen, elkülönítve minden más funkcionalitástól kezeled, így a lehető legkevesebb alkalommal kell vizsgálni az internetkapcsolat állapotát és elkerülheted a felesleges 404-es requesteket és timeoutokat.

Érdemes megemlíteni, hogy a navigator.onLine metódus nem minden esetben ad vissza pontos értéket ([itt kifejtve](https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine?ref=blog.fps.hu)). Ezt többen is felismerték és létrejött az [online.js library](http://pixelscommander.com/polygon/onlinejs/?ref=blog.fps.hu), ami mindig biztos értéket ad vissza. Kisebb hátulütője a dolognak, hogy 5 másodpercenként meghív egy távoli fájlt (amit megszakít), amivel a telefon akkumulátorát terheled, így szerintem csak indokolt esetben érdemes használni.

### Tapasztalatok

Fontos! Ha szeretnéd, hogy a webalkalmazásod offline is elérhető legyen, már a tervezéskor figyelembe kell venni és az egyes funkciókat úgy kell kialakítani, hogy azok internetkapcsolat nélkül is elérhetők legyenek, viszont online állapotban szinkronizáljon az APIval. Egy már meglévő, kicsit is bonyolultabb appot elég körülményes és túlbonyolított folyamat lehet átalakítani. Érdemes mérlegelni, hogy egyáltalán belekezdj. Továbbá számolnod kell azzal is, hogy a kliens oldali tároló (localStorage) [mérete mindig véges](https://arty.name/localstorage.html?ref=blog.fps.hu). A képeket csak módjával, API-tól kapott adatokat csak megfelelő szűrés után ajánlott elmenteni, ezzel is spórolva a helyen. Általában 5MB a korlát, de ha nem bánsz vele megfelelően, a storage tele lesz szeméttel, ami hamar káoszhoz vezet.

Amennyiben felkeltette érdeklődésed a technológia, mindenképp ajánlom ezt a [linkgyűjteményt](https://github.com/pazguille/offline-first?ref=blog.fps.hu) és az [offlinefirst.org](http://offlinefirst.org/?ref=blog.fps.hu) oldalt, ahol rengeteg hasznos információt szerezhetsz a témával kapcsolatban!
### Hogyan mérj helyesen GTM segítségével?
URL: https://blog.fps.hu/meres-google-tag-managerrel-helyesen/
Last updated: 2026-07-17T08:35:59.000Z
A minap egy projekt kapcsán volt szerencsénk mélyebben is elmerülni a Google Tag Manager rejtelmeiben. A feladat egy 5 oldalból álló vásárlási folyamat mérése, hogy kiderítsük, mely elemeket használják az oldalon, melyeket nem, illetve pontosabb képet kapjunk a felhasználói viselkedésről. A feladat nem tűnt bonyolultnak, így örömmel vágtunk bele a projektbe.

Az első lépés a folyamat feltérképezése volt, valamint meghatározni, mely elemeket mérjünk eseménnyel és melyeket ne. Kialakult egy lista, melyet az ügyféllel egyeztetve leszűkítettünk a legfontosabb pontokra. A vásárlási folyamatban többféle dolgot kellett mérni: oldalon belüli eseményeket (ajaxos felugró ablak, tabok közötti váltás), következő oldalra való lépést (a folyamatban), illetve kifelé mutató linkeket (pl. gyik). A mérendő linkek közül néhány az öt lépés minden oldalán megtalálható, némelyik két-három oldalon, a többi egyedi link. A projekt hátteréről tudni kell, hogy minimális fejlesztői segítséget tud az ügyfél supportja az oldalhoz biztosítani (a gtm konténerkódok elhelyezése is hónapokba tellett).

### Első probléma: paraméterezett URL

Miután meghatároztuk a mérési pontokat és bekerültek a GTM konténerek az oldalakba, következett a címkék és a szabályok létrehozása. Ekkor szembesültünk az első problémával: az URL a folyamat minden lépésénél azonos, viszont az első lépés kivételével többféle paraméterrel vannak ellátva. Az URL szétválogatásánál ez rögtön problémát okozott, ugyanis hiába próbáltuk a paraméterek alapján megadni a szűrési szabályokat, az azonos linkeket összemérte a rendszer, mivel technikailag az url paraméterek nem részei az URL-nek, így nem vette figyelembe a paramétereket. Hogy anno a fejlesztés idején miért így találták ki az URL-ek kialakítását, már sosem tudjuk meg, Mindenesetre a mérést alaposan megnehezítette.

### Második probléma: azonos html id, class elemek használata

Amikor elkezdtük létrehozni az aktiválási szabályokat, akkor szembesültünk a következő problémával: az azonos kinézetű, de különböző helyre linkelő gombok azonos id-val illetve class-al rendelkeznek. Ami normál esetben önmagában nem okozna problémát, de a fentebb említett problémával együtt mérési pontatlanságot okoz. Ezekkel a html elemekkel tudunk a gombokra hivatkozni, de így problémás külön mérni a gombokat, mert forráskód szinten nincs különbség közöttük, így bármelyik gombra érkezik a kattintás, nem tudjuk megkülönböztetni.

![image](https://blog.fps.hu/content/images/2016/01/code-seo.png)

### Harmadik probléma: hiányzó id vagy class html elem (vagy mindkettő)

Hasonló problémát okozott ez a verzió is, ugyanis míg az előző esetben nem tudtuk megkülönböztetni a gombokat, itt pedig a gombra való hivatkozás nehézkes. Az eddigi tapasztalataink alapján a GTM az id-vel rendelkező elemeket tudja megfelelően és kellő pontossággal azonosítani, a class-ok megadásánál vagy egyáltalán nem mér, vagy pontatlanul.

### Negyedik probléma: keszekusza oldalstruktúra

A GTM mérés első adatainak beérkezésekor szembesültünk azzal a problémával, hogy a konténer kód olyan oldalakba is belekerült (dolgozóknak szánt zárt belső oldalakba, adminisztrációs felületekbe) ahová nem kellett volna. Ezeken a helyeken is szerepeltek az általunk kialakított szabályoknak megfelelő gombok, illetve az URL-ek is egy könyvtár eltéréssel, de azonosak voltak, így azok is mérésre kerültek. Így ki kellett szűrni a megfelelő URL-eket, amely tovább bonyolította a szabályrendszert.

### Ötödik probléma: nincs fejlesztői kapacitás

Az egyes linkek egyedi id vagy class elemmel való felruházása megoldaná a problémák zömét, de erre nem lesz jelen helyzetben lehetőség, másképp kell(ene) megoldani a problémát. Mit lehet ilyenkor tenni? (kommentben várjuk az ötleteket :) )

![image](https://blog.fps.hu/content/images/2016/01/aktivalas.png)

### Javaslatok GTM eseménykövetés használatához

Mindezen problémák ellenére is jó dolognak tartjuk a Google Tag Managert. Nagyban meg tudja könnyíteni a marketingesek vagy méréssel foglalkozó kollégák dolgát, hogy csak egyszer kell a fejlesztőkkel egyeztetni, beépíteni a konténert, és onnantól kezdve nincs több kódturkálás, webes felületen keresztül minimális IT ismerettel be lehet állítani a méréseket, szabályokat.

Ha el akarod kerülni a fenti problémákat, a projekt legelején célszerű a tervezési folyamatban meghatározni, hogy várhatóan milyen adatokra lesz szükséged a felhasználókról és szokásaikról, mit és hogyan szeretnél mérni, és ezek alapján kell megtervezni, kódolni az oldalt.

**Néhány javaslat fejlesztőknek és marketingeseknek, hogy gördülékenyen menjen a későbbiekben a mérés:**

- új weboldal esetén célszerű egy mérési stratégiát készíteni, előre meghatározni, mit szeretnél mérni, mire lesz szükséged
- beszédes és egyedi url-ek használata javasolt, a paraméteres url-eket lehetőség szerint kerüld el
- a fontos funkciókat és CTA gombokat egyedi id-vel lásd el
- azonos funkciók azonos id-t kapjanak
- csak azt mérd, amire tényleg szükséged van, a majd csak jó lesz valamire adatok pontatlansághoz, a túl sok adat pedig káoszhoz vezethet
- a szabályok kialakításánál minimális fejlesztői segítség nem árt, főleg ha több szempontot kell együttesen figyelembe venni

A fenti mérési problémák a „hagyományos” eseménykövetéssel megoldhatóak lennének, viszont ha összeszámoljuk, hogy mennyi időbe került volna a marketingestől, hogy minden elemhez egyesével megadja a paramétereket, és a fejlesztőtől, hogy minden egyes elemre rátegye a mérőkódot, időben legalább négyszer-ötször tovább tartott volna, mint a GTM használatával. Ráadásul, mivel sokféle mérőkódot tartalmaz az oldal, fennáll a veszélye, hogy összakadhatnak egymással, amely mérési pontatlansághoz vezethet.

Ne félj a GTM használatától, [próbáld ki](https://tagmanager.google.com/?ref=blog.fps.hu) és meglátod, mennyivel egyszerűbbé válik a weboldalad mérése.
### JavaScript hibák naplózása szerver oldalon
URL: https://blog.fps.hu/javascript-hibak-naplozasa-szerver-oldalon-remote/
Last updated: 2026-07-17T08:36:11.000Z
A modern böngészők óriási segítséget nyújtanak a fejlesztőeszközeikkel a JavaScript hibák feltérképezésében és javításában. Csak megnyitod a konzolt, és nyomban látsz minden fontos információt, pár kattintással odanavigálhatsz a forrásához és jobb esetben tiszta is a kép. Persze, ha ott vagy a hiba keletkezésénél…

Maga a módszer, amit boncolgatok nem újkeletű, már évekkel ezelőtt is [felvetődött](http://www.the-art-of-web.com/javascript/ajax-onerror/?ref=blog.fps.hu), és [konkrét szolgáltatások](http://www.muscula.com/?ref=blog.fps.hu) is léteznek a probléma megoldására. Mégis úgy gondoltam manapság ez méginkább aktuális, hiszen webappok esetén több a hibalehetőség, és nem minden platform támogatja még a megfelelő hibakeresést. A Chrome for Android egy kellemes kivétel, ahol a [remote debugging](https://developer.chrome.com/devtools/docs/remote-debugging?ref=blog.fps.hu) jóideje segít a hibák feltérképezésében és javításában, de sajnos nem minden platformon adatott meg ez a lehetőség.

### Az elv

Az elv roppant egyszerű, és kb. magától értetődő: a felbukkanó JavaScript hibákat kell elkapni és továbbítani a szervernek a lehető legtöbb környezeti paraméterrel együtt. Így utólag visszakereshető, szűrhető és minden fontos információ kinyerhető a hibát generáló eszközt illetően is.

### A megvalósítás

A JavaScript hibák lekezelésének alapja a [window.onerror](https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror?ref=blog.fps.hu) esemény. Minden, a weboldalon bekövetkező hiba esetén meghívásra kerül ez az esemény, így el lehet kapni a hibát, annak helyét és egyéb paramétereit. Öröm az ürömben, hogy ahány JavaScript motor, annyiféle lehetséges visszatérési értéke van az onerror eseménynek. Pontosabban, nem minden esetben kapsz meg minden adatot:

```javascript

window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {}

```

- **errorMsg** (string) : Az interpreter által adott hibaüzenet. Szerencsére, a modern böngészők már informatívabban kezelik a régi *„undefined is not a function”* problémát, és visszakapod a meghívott függvény nevét, így könnyebben beazonosíthatod azt.
- **url** (string) : Az url, ahol a hiba keletkezett
- **lineNumber** (int) : A script sora, ahol a hiba keletkezett
- **column** (int) : a pozíció (karakterszám), ahol a hiba keletkezett
- **errorObj** (object) : hibaobjektum

Fontos megjegyezni, hogy az utolsó két paramétert nem minden böngésző adja vissza. Windows Phone (Internet Explorer) és iOS (Safari) eszközök nem támogatják, viszont a Chrome, Chrome for Android esetén megkapod, így érdemes foglalkozni velük.

Az így elkapott hibákat AJAX hívással elposztolod egy PHP fájlnak, ami feldolgozza és eltárolja azokat, a neked megfelelő formában. A legegyszerűbb megoldás, ha a PHP fájl is a saját szervereden van, így kevésbé kavar be egyes böngészők (teljesen jogosan támasztott) Same-origin policy-je. Az alábbi kód ezt valósítja meg:

```javascript

<script type="text/javascript">
window.onerror = function (errorMsg, url,
lineNumber, column, errorObj) {
    if (errorMsg.indexOf('Script error.') > -1) {
        return;
    }
    var text = 'Err: ' + errorMsg + ' | Script: '
    + url + ' | Ln: '
    + lineNumber    + (column ? ' | Clmn: '
    + column : '') + (errorObj ? ' | Stacktrc: '
    +  errorObj : '');
    var r = new XMLHttpRequest();
    var params = "d=" + encodeURIComponent(text);
    r.open("POST", "jslogger.php", true);
    r.setRequestHeader("Content-type",
    "application/x-www-form-urlencoded");
    r.setRequestHeader("Content-length",
    params.length);
    r.setRequestHeader("Connection",
    "close");
    r.send(params);
}
</script>

```

A *Script error* ellenőrzése azért van benne, mert némely böngészők CDN-ről behúzott fájlok esetén nem közlik a hiba konkrét okát és helyét csak az előbb említett hibaüzenetet, amivel valljuk be, sokat nem lehet kezdeni. Megkerülhető a dolog, ahogy azt [ebben a cikkben](https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/?ref=blog.fps.hu) ki is fejtik, viszont én az egyszerűbb megoldást választottam.

A PHP script faék egyszerűségű. A POST metódussal megkapott stringet eltárolod egy időbélyeggel a SERVER tömbböl kiszedett user agenttel együtt az adott fájl egy-egy sorába. Ez a rész még sok lehetőséget rejt magában, mind tárolási módot, mind a letárolt adatokat illetően, viszont így is kellő információhoz juthatsz a felmerülő hibákkal kapcsolatban.

```php

<?php
 if ($d = addslashes(strip_tags(trim($_POST['d']))))
 {
   file_put_contents('jserror.log',
   date('y-m-d H:i : ').$d.' | UA: '
   .$_SERVER['HTTP_USER_AGENT']."\n",FILE_APPEND);
 }
?>

```

### További lehetőségek

Az imént taglalt kódsorok sajnos nem fednek le minden esetet. Például AngularJS és egyéb frameworkok hibáit már nem mentik el, viszont erre is van [külön megoldás](http://engineering.talis.com/articles/client-side-error-logging/?ref=blog.fps.hu).

A fenti megoldásokat egy eléggé JS-érzékeny projektünk nehezen megmagyarázható anomáliája ihlette, amikor már csak arra tudtunk gondolni, hogy valamelyik eszközön valami általunk eddig nem tapasztalt JavaScript hiba léphetett fel és ez akasztotta meg az oldal működését. Szerencsére be is igazolódott a dolog, relatíve rövid idő alatt megkaptuk a hibát és javítani is tudtuk. Minden bizonnyal még igényelne további finomításokat és kiegészítéseket az eljárás, ezt viszont már rád bízom és várom a felvetéseket. :)
### Android fejlesztői újdonságok
URL: https://blog.fps.hu/android-fejlesztoi-ujdonsagok/
Last updated: 2026-07-17T08:36:23.000Z
A 2015-ös Google I/O-n – ahogy várható volt – a Google új dolgokat mutatott az Android fejlesztőknek. A legtöbb ezek közül már régóta várt fejlesztés volt. Kiemeltem ezek közül párat, amelyek szerintem fontosak.

### Új Design Support könyvtár

Új verzió érkezett a v4 és v7-es support könyvtárakhoz a visszafelé kompatibilitást jegyében. Ebben rejlik egy új könyvtár, mégpedig a material megjelenést elősegítő design support library. Ez a 7-es API-tól felfelé már most elérhető.

#### Miket is kapsz?

- TextInputLayout – amivel beviteli mezőhöz lehet tippet és hibát megjeleníteni, akár gépelés közben is
- *FloatingActionButton* – amivel az adott nézet fő funkcióját lehet kiemelni
- *Snackbar* – amivel gyors visszajelzést lehet adni egy művelet után
- *NavigationView* – a könnyebb menü készítésért
- *TabLayout* – már material designnal rendelkezik
- Más animációt és görgetést elősegítő osztályok

[Példa projektet találsz Chris Banes githubján](https://github.com/chrisbanes/cheesesquare/?ref=blog.fps.hu). Leírást a [további újdonságokról az Android Developers Blogon](http://android-developers.blogspot.co.at/2015/05/android-design-support-library.html?ref=blog.fps.hu).

![textinputlayout példa](https://blog.fps.hu/content/images/2016/01/material.png)

### Android Studio 1.3

A már most a Canary csatornában elérhető új Studioban számos újdonsággal találkozhatsz.

#### C/C++

C/C++ integráció az egyik ilyen feature, ami még több eclipse felhasználót fog átcsábítani. Akik játékfejlesztéssel foglalkoznak, azoknak sokszor kellhet natív kódot írni C nyelven, amire eddig a Studio nem volt képes. A JetBrains Clion integrációjával viszont ez az akadály megszűnt.

#### Új annotációk

Kapsz 13 új annotációt. Ezek közül egy példa a *@WorkerThread*. Az ezzel megjelölt metódusban nem lehet UI kód. Amennyiben mégis beleírsz ilyen kódot, az Android Studio hibát jelez.  
Hasonló ehhez a *@RequiresPermission*. Itt megjelölheted melyik kód lefutásához milyen engedélyek szükségesek. Ezeket a Studio automatikusan hozzá is tudja adni a kódodhoz.

#### Gradle optimalizációk

Kezelésbe vették egy kicsit az Android Gradle plugint és javítottak a fordítás sebességén. Elkezdtek haladni afelé, hogy csak a változásokat fordítsák le és ne előről kezdődjön a fordítás. Az igazi sebesség csak később jön el majd az új 1.3-as Android Studioval, de addig is kipróbálhatod a canary csatornában lévő verzióban.

#### További újdonságok

- Egyszerűbb integrációja az olyan Google szolgáltatásoknak, mint az Analytics
- Könnyebb profiling/hibakeresés
- Átdolgozott layout/téma szerkesztő egy későbbi verzióban

### Listing Experiments

Mostantól lehetséges különböző kísérleteket indítani a Play Store-ban levő applikációkon. A felhasználók bizonyos százaléka számára kicserélhetjed az alkalmazás logóját vagy leírását, hogy több telepítést érhess el. Például az összes Play Store felhasználónak 10%-a más sorrendben látja majd az app leírásában szereplő képeket. Természetesen visszajelzést is kapsz minderről.

### Cloud Test Lab

Bejelentették a [Cloud Test Lab](https://developers.google.com/cloud-test-lab/?ref=blog.fps.hu) nevű szolgáltatást. Képes automatán tesztelni mobil applikációkat fizikai és virtuális eszközökön, mielőtt az kiadásba kerülne. A teszt a bejelentés szerint a top 20 mobil készüléken fut le, és az eredményről képernyőképet illetve naplót is tud generálni.

### Google Cloud Messaging

Bővült a Google által támogatott platformok köre, ugyanis mostantól iOS készülékeken is elérhetővé válik a GCM szolgáltatás „sokak örömére”. Ezzel a lépéssel új SDK is letölthető.

Sok más egyéb újdonságot is bejelentettek. Ajánlom neked az alábbi videókat és oldalakat több infóért:

- [100 Days of Google Dev](https://www.youtube.com/playlist?list=PLOU2XLYxmsIJDPXCTt5TLDu67271PruEk&ref=blog.fps.hu)
- [Google I/O Summary](http://robovm.com/google-io-summary-whats-new-in-android-development-tools/?ref=blog.fps.hu)
- [New Android Developer Guides](http://www.reddit.com/r/androiddev/comments/37quv8/new%5Fgoogle%5Fio%5F2015%5Fandroid%5Fdeveloper%5Fguides/?ref=blog.fps.hu)
### Hírlevélküldés, de mivel?
URL: https://blog.fps.hu/hirlevelkuldes-hirlevelkuldo-szolgaltatasok/
Last updated: 2026-07-17T08:36:32.000Z
Amikor egy cég életében felmerül a hírlevélküldés gondolata, rögtön jön a kérdés is: milyen szoftvert válasszak? A választás nem egyszerű, ugyanis nagyon sokféle hírlevélküldő érhető el a piacon. Ahhoz, hogy könnyebben eligazodj a szoftverek között, válaszolj ezekre a kérdésekre:

- Mi a célja a hírlevélküldésnek?
- Mekkora az adatbázisod?
- Az email címen kívül szükséges más adatot is tárolni?
- Hányféle listára van szükséged?
- Van elegendő humán erőforrás a cégen belül az email marketingre?

A válaszok alapján már le tudod szűkíteni a kört, és könnyebb lesz a választás. Szeretnénk segíteni a döntésben, ezért kiválasztottunk és bemutatunk 6 különböző, általunk is ismert és használt hírlevélküldő szoftvert.

#### Milyen elvárások vannak egy hírlevélküldő szoftverrel szemben?

Van néhány olyan funkció, amit mi, mint vállalkozás és mint webügynökség is alapvető dolgoknak tartunk. A teljesség igénye nélkül:

- feladóként tetszőleges domaint lehet beállítani
- van drag and drop szerkesztőfelület
- a beépített sablonokon túl tetszőleges email sablonokat is lehet használni
- perszonalizálható a levél tárgya és maga a hírlevél is
- automatikusan generálódik a hírlevél böngészős változata
- automatikus leiratkozás lehetőség
- automatikus adatbázis tisztítás (bounce-osok és visszapattanók kezelése)

És akkor következzen az egyes szoftverek bemutatása.

### Oempro

![Oempro felülete](https://blog.fps.hu/content/images/2015/12/oempro.jpg)

Az Oempro hírlevélküldő rendszer kétféle konstrukcióban is elérhető: szoftverként és szolgáltatásként. A fejlesztő cég által biztosított szolgáltatás [Sendloop](https://sendloop.com/?ref=blog.fps.hu) néven érhető el. A szoftver az [octeth.com](http://octeth.com/?ref=blog.fps.hu) oldalról vásárolható meg háromféle konstrukcióval a felhasználói fiókok száma alapján. Ha szoftverként használod, jól dokumentált API-val rendelkezik, könnyen integrálható weboldalakhoz, illetve publikus plugin keretrendszerrel rendelkezik, így jól továbbfejleszthető, illetve könnyen testre szabható. A szoftvernek egy egyszeri licensz díja van csak, viszont havi üzemeltetési költségei vannak a szoftvert kiszolgáló infrastruktúrának.

#### Melyek az erősségei?

Az API hívások széleskörű lehetőséget biztosítanak az Oempro külső programozására akár olyan szinten is, hogy kampányt lehet ütemezni, készíteni a szoftveren kívül is. Többszintű felhasználó kezelésre van lehetőség, ez elsősorban ügynökségi oldalról praktikus. A feliratkozókat elkülönített listákban is tudja külön-külön is kezelni.

#### Kiknek ajánlott?

Elsősorban ügynökségeknek, ahol van webfejlesztő, grafikus és marketinges, akik el tudják készíteni a hírleveleket illetve a hírlevél template-eket, és az utánkövetést is biztosítani tudják.

#### Milyen technikai hátteret igényel?

A felhasználói felület kezelése modern böngészőt igényel, a szoftver üzemeltetéséhez PHP 5.1-nél nagyobb verzió futtatására képes webszerver és MYSQL adatbázis szükséges. Hálózati és rendszer üzemeltetői ismeretek is szükségesek a beüzemeléshez.

### Mailchimp

![Mailchimp felülete](https://blog.fps.hu/content/images/2015/12/mailchimp.jpg)

A [Mailchimp](http://mailchimp.com/?ref=blog.fps.hu) webes szolgáltatásként érhető el. Felhasználóbarát felülete biztosítja a „laikusoknak” is a könnyű használhatóságot. A hírlevélküldő havi 2000 email címig és 12 000 kiküldött emailig ingyenes. Jól dokumentált API felülete van, könnyen integrálható weboldalakhoz is. Többféle nyílt forráskódú CMS rendszerhez létezik kész plugin az integráláshoz. Sokféle előre elkészített responsive email sablon áll rendelkezésre. Az előfizetési konstrukciók minden igényt kielégítenek: lehet email cím darabszám, kiküldött hírlevél darabszám illetve kredit vásárlás alapján is.

#### Melyek az erősségei?

Nagyon felhasználóbarát a felülete, HTML ismeret nélkül is lehet hírleveleket készíteni és küldeni. Üzemeltetéssel nem kell foglalkozni. Az előre beépített email sablonok és maga a kezelőfelület is mobilra optimalizált. A feliratkozókat elkülönített listákban is tudja külön-külön is kezelni.

#### Kiknek ajánlott?

Elsősorban azoknak, akik nem kezelnek több százezres listákat, de fontos a szegmentálhatóság. Ha nincs lehetőség külön programozó vagy grafikus alkalmazására.

#### Milyen technikai hátteret igényel?

Semmi extra, egy modern böngészővel teljes körűen használható.

### Protopmail

![Protopmail felülete](https://blog.fps.hu/content/images/2016/01/protopmail.png)

A [Protopmail](http://www.protopmail.hu/?ref=blog.fps.hu) webes felületről elérhető és menedzselhető email marketing szoftver, amely közép- és nagyvállalatok számára készült. Jónéhány funkciója túlmutat egy átlagos hírlevélküldő szoftveren, marketing automatizációs modulok is elérhetőek a csomagokban. 1000 email küldéséig ingyenes a szoftver korlátlan funkciókkal és korlátlan felhasználási idővel. Havidíjas és pre-paid-es fizetési konstrukciók érhetőek el kiküldött email alapján. Az előfizetéses modellben API használatot és támogatást kapunk.

#### Melyek az erősségei?

Nagy volumenű kiküldésekre is képesek, gyorsan és megbízhatóan. Magyar nyelvű telefonos ügyfélszolgálat is rendelkezésre áll, és lehetőség van tanfolyamokon is részt venni. Nagy mennyiségű email kiküldés mellett lehetőség van automatizációra, akár nagy forgalmú webshopok automatikus értesítéseinek kiszolgálására is. A felület magyar nyelven is elérhető.

#### Kiknek ajánlott?

Közepes és nagyvállalatok számára, illetve azoknak, akik több százezres vagy milliós ügyfél adatbázissal rendelkeznek, és napi szinten küldenek nagy mennyiségű levelet, illetve azoknak, akik automatizált marketing kampányokat folytatnak.

#### Milyen technikai hátteret igényel?

Egy modern böngészővel minden funkció elérhető, nincs egyéb erőforrásra szükség.

### Maileon

![Maileon felülete](https://blog.fps.hu/content/images/2016/01/maileon.png)

A [Maileon](http://maileon.hu/?ref=blog.fps.hu) egy nagy teljesítményű online hírlevélküldő rendszer. Abban különbözik az eddig említett hírlevélküldő rendszerektől, hogy egyedi felhasználói profilt készít, mely adatok birtokában a későbbiekben személyre szabott emailek küldésére van lehetőség. 30 napos próbaverzió elérhető, de csak kapcsolatfelvétel után. Itt is van lehetőség API kapcsolatra.

#### Melyek az erősségei?

Egyedi felhasználói profilokat készít, mely viselkedés alapon (megnyitások, kattintások stb. alapján) kerül kialakításra. Folyamatosan frissül a profil, ezáltal jól szegmentálható az adatbázis. Marketing automatizálásra is nagyon jól használható. A felhasználói felület több nyelven is elérhető.

#### Kiknek ajánlott?

Nagyméretű ügyféladatbázissal rendelkező cégeknek, ahol sokféle információt kell tárolni az egyes felhasználókról. Van lehetőség adatbázis tisztításra is (a nem létező vagy inaktív email címeket törli az adatbázisból).

#### Milyen technikai hátteret igényel?

Egy modern böngészővel minden funkció elérhető, nincs egyéb erőforrásra szükség.

### Webgalamb

![Webgalamb felülete](https://blog.fps.hu/content/images/2016/01/webgalamb.png)

A [Webgalamb](http://www.webgalamb.hu/?ref=blog.fps.hu) egy magyar fejlesztésű hírlevélküldő program magyar nyelvű ügyfélszolgálattal. A szoftvernek egy egyszeri licensz díja van csak, viszont havi üzemeltetési költségei vannak a szoftvert kiszolgáló infrastruktúrának.

#### Melyek az erősségei?

Ingyenesen kipróbálható, egyszerű, könnyen használható hírlevélküldő.

#### Kinek ajánlott?

Induló vagy kis méretű vállalkozásoknak, akik viszonylag kis (pár ezres) adatbázissal rendelkeznek és egy ember menedzseli a hírlevél kampányokat.

#### Milyen technikai hátteret igényel?

Könnyen telepíthető bármilyen Linuxos, Apache-os, MySQL-es, PHP-s környezetben, nincsenek speciális PHP-s függőségei, bármely tárhelyszolgáltatónál könnyen telepíthető.

### MailMaster

![MailMaster felülete](https://blog.fps.hu/content/images/2016/01/mailmaster.png)

A [Mailmaster](http://www.marketingszoftverek.hu/?ref=blog.fps.hu) egy magyar fejlesztésű online hírlevélküldő rendszer, kifejezetten kisvállalatokra fókuszálva.

#### Melyek az erősségei?

Egy könnyen használható CRM rendszert is tartalmaz a szoftver, illetve vannak az email kampányokat támogató segédeszközök, például fel és leiratkozó űrlap készítő, landing page készítő modul. Kiküldött emailek tényleges darabszáma alapján történik a számlázás.

#### Kiknek ajánlott?

Induló vállalkozásoknak illetve kisvállalkozásoknak, akik már rendelkeznek valamilyen ügyfél adatbázissal, de nincs erőforrásuk ügyviteli szoftver üzemeltetésére.

#### Milyen technikai hátteret igényel?

Egy modern böngészővel minden funkció elérhető, nincs egyéb erőforrásra szükség.

Reméljük, sikerült egy kis segítséget nyújtanunk ahhoz, hogy megtaláld a hozzád, illetve a tevékenységedhez leginkább passzoló hírlevélküldő szolgáltatást. Ne feledd, mindig az üzleti célokat tartsd szem előtt, mielőtt döntést hozol.
### Ellenőrizd gyorsan a Google Analytics beállításaid
URL: https://blog.fps.hu/ellenorizd-az-analytics-beallitasokat/
Last updated: 2026-07-17T08:36:44.000Z
Mérni vagy nem mérni? Ez napjainkban már nem is kérdés, ugyanis mérés nélkül nem érdemes semmilyen projektbe belekezdeni. Mérés nélkül honnan tudnánk, hogy jó úton haladunk? Ez a poszt és a végén letölthető checklist segít a helyes mérés beállításában illetve ellenőrzésében.

Ha épp most kezdesz Google Analyticset használni, vagy csak szeretnéd a jelenlegi beállításaidat rendbe rakni, akkor erre az ellenőrző listára van szükséged. Ha van még tipped, ötleted, ami hiányzik a listából, oszd meg velünk a cikk alatt kommentben.

Használd az ellenőrző listát, olvass tovább és nézd meg, minden rendben van a beállításokkal.

### 1\. Helyesen illesztettem be a Google Analytics mérőkódot?

Persze ez egyértelműnek tűnik, de mégsem lehet eléggé hangsúlyozni a fontosságát. Ha a mérőkódod nincs rendesen beállítva, akkor vagy egyáltalán nem kapsz adatokat, vagy nem megfelelő adatok érkeznek a Google Analytics fiókodba. 

Néhány tipp, amit érdemes megjegyezni:

- bizonyosodj meg arról, hogy a mérőkód minden egyes oldaladban benne van. Ha nincs kód, nincs mérési adat
- csak egyszer kell a kódot elhelyezni, amennyiben duplán szerepel, mérési problémákat okoz
- a megfelelő helyre illeszd be a kódot. Az ajánlott helye a lezárása előtt van
- a legfrissebb mérőkódot használd. Frissíts Universal Analyticsre. A klasszikus mérőkód ugyan működni fog, de előbb-utóbb a Google megszünteti a támogatását
- még jobb, ha Google Tag Managerrel illeszted be az Analytics mérőkódot. [Részletes útmutatók](https://support.google.com/tagmanager/?ref=blog.fps.hu#topic=3441530) már elérhetők hozzá
- teszteld le a [Google Tag Assistant](https://support.google.com/tagassistant/?ref=blog.fps.hu#topic=6000196)\-tal, így biztos lehetsz abban, hogy minden megfelelően működik

### 2\. Be van állítva az oldal keresési riportja?

A felhasználók keresési aktivitásának pontos követéséhez szükséged lesz néhány extra lépésre. A módszer függ attól, hogy a honlapon milyen funkciókat és milyen URL-eket hoz létre a keresésnél. 

Néhány dolog, amire érdemes odafigyelni:

- ideális, ha a keresési kulcsszót paraméterként adod át az URL-ben
- a lejelentett kulcsszavak betűkészlet érzékenyek, de lehet kisbetűs szűrőt adni hozzá
- tudnak a látogatóid kategóriánként keresni? Nyomon tudod követni a kiválasztott kategóriát is

### 3\. Használsz eseménykövetést?

![Google Analytics események képernyőkép](https://blog.fps.hu/content/images/2016/01/esemenykovetes.png)

Az eseménykövetés segít feltérképezni a felhasználók tevékenységeit az oldalon belül. Sok mindent nyomon követhetsz, úgymint: letöltések, videó lejátszás, kifelé mutató kattintást, eszközöket és flash elemeket.

Hozd ki a legtöbbet az eseménykövetésből:

- légy következetes az elnevezésekben és tervezd meg előre a struktúrát az esemény kategória, művelet és címke esetében
- gondold át, mely kifelé mutató linkekre, belső kampányokra, letöltésekre és interaktív tartalmakra akarsz mérést
- ne feledd, hogy a nem interaktív események nem befolyásolják a visszafordulási arány mérését
- vezess be esemény alapú célokat esemény érték használatához
- csak a fontos eseményeket mérd, alkoss stratégiát és mérj mindent, amit szeretnél, de tartsd szem előtt a Google korlátait is

### 4\. Szükséged van e-kereskedelmi mérésre?

Az ecommerce mérés segít jobban megismerni az ügyfeleidet, mit vásárolnak, mely termékek teljesítenek jól, hol hagyják el a felhasználók a vásárlási tölcsért. 

Ne felejtsd el az alábbiakat:

- hozz jobb döntéseket azáltal, hogy biztosítod a pontos mérést a webshopoddal kapcsolatban. Határozd meg a célokat és a vásárlási tölcsért, de ne állíts be értéket, mert ezt már a korábbi beállítás méri.
- függetlenül attól, hogy használsz e-kereskedelmi mérést vagy sem, ha alaposabb információt szeretnél, frissíts a legújabb továbbfejlesztett e-kereskedelmi mérésre

### 5\. Pontosan állítottad be a célokat?

A célok beállítása a Google Analytics fiókban az első lépés az adat alapú marketinghez. Nem csak egységet alkot a weboldal és az üzleti célok között, hanem méri azt, hogy mennyire hatékony a marketing tevékenység.

- mérj mind makro mind mikro konverziókat is, így jobban megérted a felhasználóid tevékenységét a weboldaladon
- ne feledd, hogy lehetőséged van pénzbeli értéket nem e-kereskedelmi célokhoz rendelni, így még jobban motiválhatod magad céljaid elérésére

### 6\. Beállítottad az alapértelmezett oldalt?

Van alapértelmezett oldal beállítása a weboldaladnak? Ha nincs, akkor előfordulhat, hogy találsz még néhány plusz sort a jelentésben.

- ellenőrizd a jelentést és bizonyosodj meg arról, hogy az alapbeállításokat helyesen adtad meg
- légy óvatos ezzel a beállítással, mert megakadályozza az oldalon belüli jelentés használatát, ha érvénytelen az alapértelmezett oldal beállítás a weboldalon. Az is negatívan módosíthatja a jelentést, ha rosszul állítottad be.

### 7\. Kapcsolódik a Google Adwords fiókod a Google Analytics fiókodhoz?

![AdWords és Analytics fiók összekapcsolás képernykép](https://blog.fps.hu/content/images/2015/12/adwords-2.jpg)

Ez mindenképp szükséges ahhoz, hogy a lehető legtöbbet hozd ki a kampányaidból. Ha egyszer összekötötted a fiókokat, részletes adataid lesznek a fizetett kampányaidról a Google Analyticsben, ezáltal alaposabb elemzést kapsz az ügyfeleid tevékenységről.

- ellenőrizd, hogy a kattintások a megadott időszakokkal hozzávetőlegesen egyeznek. A számok sosem lesznek pontosan egyformák, de nem lehet túl nagy eltérés közöttük
- ha több mint egy Adwords fiókod van, nézd meg az Analytics súgójában, hogyan kell összekapcsolni őket
- ne adj kampány címkét az Adwords céllinkjéhez, mivel ezek akadályozzák az Adwords automatikus címkézését

### 8\. Használsz kampány címkéket a marketing tevékenységed mérésére?

Azok a marketingesek, akik ROI-ban mérnek és szeretnék folyamatosan mérni és finom hangolni a kampányaikat nem kerülhetik el a kampány címkéket. Ez egyszerű, de rendkívül hatékony módja annak, hogy pontos adatokat kapjunk készen a Google Analyticstől, és lássuk az eredményeket, szegmentáljunk és optimalizáljunk.

- alkalmazz kampány címkézést minden bejövő linken, kivéve az Adwordsön, mert azt automatikusan címkézi a rendszer
- ellenőrizd, hogy a kampány címkék következetesen vannak-e használva, így megkönnyíted az adatok megértését
- jegyezd föl, hogy mely kampánynál hogyan címkéztél, ezzel fenntartod a következetes használatot
- kampány címkéket lekérdezési paraméterként adj az URL-hez és a kereszthivatkozás elé tedd pl. a ? paraméter után és a # szimbólum elé
- teszteld a címkézett URL-t az oldal indítása előtt és bizonyosodj meg arról, hogy működik a nyomkövetés

### 9\. Vess egy pillantást a domain nevekre: megfelelőek?

Ha a weboldalad többféle domaint vagy aldomaint használ, akkor láthatod a saját domainedet a hivatkozó jelentésben. Ezt hívják önhivatkozásnak, ha ezt látod, akkor be kell állítanod a követési kódot vagy tulajdont, hogy követhesd a domainek közötti forgalmat.

- állítsd be együttes mérést egyenként a domainekre, így elkerülöd, hogy megjelenjen az önhivatkozás és a mérés helyes marad
- szűrd ki az ismeretlen vagy gyanús domain neveket az adatok közül

Remélem, sikerült mindent leellenőrizni, illetve helyesen beállítani. Az adatokat rendszeres időközönként elemezd, hogy a lehető legjobbat tudd kihozni weboldaladból.

**Töltsd le a nyomtatható checklistet PDF formátumban!**

0 [Töltsd le a checklistet](https://www.fps.hu/presentations/google-analytics-ellenorzo-lista-fps.pdf?ref=blog.fps.hu "Töltsd le a nyomtatható checklistet PDF formátumban") 

Köszönöm a [lovesdata.com](http://www.lovesdata.com/?ref=blog.fps.hu) hozzájárulását, hogy lefordíthattam és Mátyás Anikó segítségét a nyelvi lektoráláshoz.
### 30+1 Easter Egg, amit lehet, hogy nem ismersz
URL: https://blog.fps.hu/easter-egg-gyujtemeny/
Last updated: 2026-07-17T08:36:54.000Z
Mindenki hallott már a Word 97-ben előhívható flipperről, vagy az Excel 97-ben lévő mászkálós játékról. Tény, hogy a programozók munkája nem mindig izgalmas, valamivel nekik is el kell magukat szórakoztatni, így néha easter eggeket építenek be programjaikba, weblapjaikba. Ezek közül válogattuk össze nektek a legjobbakat, amelyeknek egy része online is elérhető.

### 1\. Barrel roll

![Barrel roll](https://blog.fps.hu/content/images/2016/01/barrel-roll.png)

Írjátok be a Google keresőjébebe, hogy „do a barrel roll” vagy azt, hogy „z or r twice”! Keresőtök egy teljes fordulattal üdvözöl majd titeket.

### 2\. Beam Me Up Scotty

![Beam Me Up Scotty](https://blog.fps.hu/content/images/2016/01/scotty.png)

Úgy látszik a Googlenél is szeretik a Star Treket, hiszen ha beírjátok a Youtube keresőjébe, hogy „Beam Me Up Scotty” felsugározza nektek a videótalálatokat.

### 3\. Rejtett tartalmak az Androidban

![Android rejtett funkciók](https://blog.fps.hu/content/images/2016/01/android.png)

Az Android 2.3-as Gingerbread verziója óta minden frissítésben megtalálhatóak a fejlesztők által készített rejtett tartalmak. Ezeknek a megtekintéséhez menjetek androidos eszközötök beállításaiba, azon belül a telefon névjegye menübe és ott koppintsatok gyorsan háromszor az Android verziójára. A Jelly Beanben például cukorkákat dobálhattok szét.

### 4\. Pónik a Google Hangoutsban

![Google Hangouts](https://blog.fps.hu/content/images/2016/01/ponik.png)

A Google Hangouts chat ablakában írjátok be: „/ponies” és máris átnyargal egy szivárványpóni a beszélgetésen. Ugyanígy működnek még a „/shydino”, a „/pitchforks” és a „/bikeshed” parancsok is, a „/ponystream” paranccsal pedig egy egész ménesnyi pónit szabadíthattok a chatre.

### 5\. Billentett kereső

![Google kereső](https://blog.fps.hu/content/images/2016/01/billentettkereso.png)

Írjátok be a Google keresőbe a „tilt” szót, és minden eldől.

### 6\. Repülőgép szimulátor a Google Earthben

![Google Earth](https://blog.fps.hu/content/images/2016/01/repulogepszimulator.png)

Előhívásához nyomjátok meg a Ctrl+Alt+A kombinációt, vagy Mac-en a Cmd+Opt+A kombót, és a repülőgép típusának kiválasztását követően máris csodás tájak fölött szárnyalhattok. Az irányítás egy másik történet, de ebben is [segítséget nyújt a Google](http://earth.google.com/support/bin/static.py?page=guide.cs&guide=22385&topic=23746&answer=148092&ref=blog.fps.hu).

### 7\. Google 1337 speak interface

![Google Speak](http://)

Ha valamelyikőtök kedvet érez hozzá, akár [1337 nyelven is keresgélhet](https://www.google.hu/webhp?hl=xx-hacker&gws%5Frd=cr&ei=aaAaVYG4OsGosgHKn4Bw&ref=blog.fps.hu).

### 8\. Atari Breakout

![Atari Breakout](https://blog.fps.hu/content/images/2016/01/ataribreakout.png)

Képkeresésnél írjátok be az „Atari Breakout” kifejezést, és máris nosztalgikus hangulatba kerülve játszhattok önfeledten az eredetileg 1976-ban megjelent klasszikussal.

### 9\. Harlem Shake

![Harlem Shake](https://blog.fps.hu/content/images/2016/01/harlemshake.png)

A Google nem engedi meg, hogy elefelejtsük a weben végigsöprő Harlem Shake őrületet. Írjátok be a YouTube keresőjébe, hogy „do the Harlem Shake” és máris táncra perdül. A hangszóró is legyen bekapcsolva (vagy fejhallgató fel), kár kihagyni.

### 10\. Konami-kód weboldalakon

![Konami-kód](https://blog.fps.hu/content/images/2016/01/konami.png)

A Konami cég 1969 óta örvendezteti meg a gamereket játékaival, és majd minden arcade játékában van egy univerzális kód, ez a „felfelé nyíl”+„felfelé nyíl”+„lefelé nyíl”+„lefelé nyíl”+„balra nyíl”+„jobbra nyíl”+„balra nyíl”+„jobbra nyíl”+„B”+„A”. Akad néhány weboldal, amelyet ha betöltötök és beütitek a megfelelő kombinációt érdekes dolgokat produkál. Próbáld ki ezeken például:

- [BuzzFeed](http://www.buzzfeed.com/?ref=blog.fps.hu)
- [SoundClick](http://www.soundclick.com/?ref=blog.fps.hu)
- [Digg](http://digg.com/?ref=blog.fps.hu)
- [Vogue UK](http://www.vogue.co.uk/?ref=blog.fps.hu)

### 11\. Őshüllő a forráskódban

![Őshüllő a forráskódban](https://blog.fps.hu/content/images/2016/01/oshullo.png)

A [The Oatmeal olda](http://theoatmeal.com/?ref=blog.fps.hu)l készítői is nagyon untakozhattak, nézzétek csak meg a forráskódot.

### 12\. Robotok a Firefoxban

![Robotok a Firefoxban](https://blog.fps.hu/content/images/2016/01/firefox-2.png)

A Mozilla Firefox böngészőjében az „about:robots” szavakat a keresősávba írva egy robot üdvözöl minket, és közli: látogatásuk békés és jószándékú.

### 13\. Kalóz Facebook

![Kalóz Facebook](https://blog.fps.hu/content/images/2016/01/kalozfacebook.png)

A Facebookon lehetőségetek van nyelvként a kalóz angolt beállítani „English (pirate)”, így máris mókásabb a közösségi oldalon böngészni.

### 14\. Játszatok ha nincs net

![Nincs net? Játssz a Chrome-odban!](https://blog.fps.hu/content/images/2016/01/nointernet.png)

Feltűnt már nektek, hogy a Google Chrome dínója, amely azt jelzi, hogy nincs internet tulajdonképpen egy játék? Elég ha megnyomjátok a space-t.

### 15\. Firefox logó a Google Earth-ben

![Firefox logó a Google Earth-ön](https://blog.fps.hu/content/images/2016/01/firefoxlogo.png)

A Google Earth keresőjébe írjátok a következő koordinátákat: 45° 7'25.87"N 123° 6'48.97"W. Egy kis zoomolás után meglátjátok a jól ismert logót.

### 16\. Az ottfelejtett óriás nyúl

![Óriás nyúl a Google Earth-ön](https://blog.fps.hu/content/images/2016/01/nyul.png)

Szintén a Google Earthben navigáljatok a 4°14'39.35"N 7°46'11.53"E koordinátákra, és meglátjátok a tapsifülest, ahogy magányosan fekszik a homokban.

### 17\. Luke, használd az erőt!

![YouTube és az erő](https://blog.fps.hu/content/images/2016/01/luke.png)

A YouTube keresőjébe ezeket a szavakat angolul írva „Use the force Luke” kipróbálhatjátok a jedik trükkjét.

### 18\. Zerg rush

![Google kereső pusztulása](https://blog.fps.hu/content/images/2016/01/zerg.png)

A „zerg rush” kifejezést a Google keresőbe írva az „O” betűk megkezdik az inváziót, hogy elpusztítsák keresési eredményeinket. Csak úgy lehet megállítani őket, ha rájuk kattintotok.

### 19\. A Facebook földgömb ikonja

![Facebook földgömb ikon](https://blog.fps.hu/content/images/2016/01/facebook-foldgomb.png)

Tudtátok, hogy a szinte alig észrevehető ikon megváltozik attól függően hol tartózkodunk?

### 20\. Rekurzió

![Google kereső rekurzív](https://blog.fps.hu/content/images/2016/01/recursion.png)

A Google keresőjébe a „recursion” szót írva keresési javaslatként a „recursion” jelenik meg. A Google keresőjébe a „recursion” szót írva keresési javaslatként a “recursion” jelenik meg.

### 21\. A Kickstarter titka

![Kickstarter titok](https://blog.fps.hu/content/images/2016/01/kickstarter.png)

A [Kickstarter oldalon](https://www.kickstarter.com/?ref=blog.fps.hu) görgessetek le egészen a footerig, majd kattintsatok párszor az ollóra és fény derült a Kickstarter titkára.

### 22\. Wikipedia

![Easter egg szócikk a Wikipedián](https://blog.fps.hu/content/images/2016/01/wiki.png)

Az angol nyelvű Wikipedián az [Easter egg (media)](http://en.wikipedia.org/wiki/Easter%5Fegg%5F%28media%29?ref=blog.fps.hu) szócikkre keresve a jobb felső kép jobb alsó sarkában lévő fekete gombóc (süni) link title szövege megér egy mosolyt. Ha rákattintotok tojásokat kaptok.

### 23\. Üres oldal a Wikipedián

![Üres oldal a Wikipedián](https://blog.fps.hu/content/images/2016/01/blankpage-wiki.png)

A [Wikipedia Blank Page](https://en.wikipedia.org/wiki/Special:BlankPage?ref=blog.fps.hu) oldalára navigálva közlik velünk, hogy ez az oldal direkt maradt üresen.

### 24\. A WordPress felhasználási feltételei

![WordPress felhasználási feltételek](https://blog.fps.hu/content/images/2016/01/wordpress-felhasznalasi-feltetelei.png)

Ki szereti végigolvasni az unalmas felhasználási feltételeket? A WordPress angol nyelvű oldala egy kis [kedvességel jutalmazza a kitartókat a 17\. pontban](https://en.wordpress.com/tos/?ref=blog.fps.hu).

### 25\. Facebook fejjel lefelé

![Facebook fejjel lefelé](https://blog.fps.hu/content/images/2016/01/facebook-fejjel-lefele.png)

A nyelv választásánál lehetőségünk van az „English (Upside down)” kiválasztására, ha kínozni akarjuk magunkat vagy másokat.

### 26\. A Mozilla bibliája

![Mozilla biblia](https://blog.fps.hu/content/images/2016/01/mozzila.png)

A Firefox böngészőben az „about:mozilla” kifejezésre navigálva tekinthettek meg egy idézetet a Mozilla könyvéből.

### 27\. Csak a bögrét ne!

![Bögre a Hema webshopon](https://blog.fps.hu/content/images/2016/01/hema-bogre.png)

[Menjetek a Hema webshopjába](http://producten.hema.nl/?ref=blog.fps.hu), és húzzátok el az egeret a jobb felső sarokban látható bögre fölött. Az oldal jól érzékelhető módon belekezd az önmegsemmisítésbe.

### 28\. A Microsoft Word Lorem Ipsuma

![Lorem ipsum és a Word](https://blog.fps.hu/content/images/2016/01/microsoft-lorem.png)

Bármelyik Word verzióban elérhető, ha begépelitek a =rand(X,Y) sort, majd nyomtok egy entert. Az X a bekezdések, az Y a sorok számát jelöli. Ki tudja, hátha szükségetek lesz rá.

### 29\. ASCII Art a forráskódban

![KitKat website-ban ASCII Art](https://blog.fps.hu/content/images/2016/01/asciart.jpg)

A [KitKat](https://www.kitkat.com/?ref=blog.fps.hu) fejlesztői kiélték művészi hajlamukat az oldal forráskódjában.

### 30\. Az élet értelme

![Google Calculator 42](https://blog.fps.hu/content/images/2016/01/answer-google.jpg)

A Galaxis útikalauz stopposoknak című filmben ugyan megválaszolták már, de a Google Calculator is tudja a választ. Egyszerűen írjátok be: „answer to life the universe and everything”.

### +1\. A Wolfram Alpha tudásbázis

![Wolfram Alpha tudásbázis](https://blog.fps.hu/content/images/2016/01/wolframalpha.jpg)

Biztosan hallottatok már róla, bár hazánkban kevesen használják mivel angol nyelvű. De a „how much wood would a woodchuk chuck if a woodchuck could chuck wood” vagy a „to be or not to be” kérdésekre érdekes válaszokat ad az oldal.

**Kimaradt valami? Esetleg ti is rejtettetek már el Easter Egget valahol?**  
**Várjuk kommentben!**
### Template-kezelő rendszerek
URL: https://blog.fps.hu/template-kezelo-rendszerek/
Last updated: 2026-07-17T08:37:06.000Z
Annak idején, amikor kezdtem a webes programozást, megszokott volt, hogy olyan kódokat írjak és lássak, ahol az adatok lekérdezése, kezelése és megjelenítése, illetve az oldal felépítése egy fájlba volt ömlesztve, emiatt nehezen átlátható, robusztus és nem túl rugalmas kódok voltak. Ennek oka az volt, hogy még tapasztalatlan voltam kevés tudással és nem tudtam, hogy lehet ezt másképp is.

Biztos ismerős helyzet sokak számára, amikor újra és újra előkerül ugyanaz a html kód az oldalon. Például amikor cikkeket és kategóriákat (recepteket, videókat, képeket) listázol. Legtöbb esetben a listák hasonló felépítésűek és hasonlóképpen jelennek meg, de sok más hasonló vagy ugyanolyan felépítésű elem is előfordulhat az oldalon. Ennek ellenére gyakran az történik, hogy mindegyik ilyen elem külön található meg a kódban, vagyis feleslegesen kódot duplikálsz és plusz munkát végzel. Ráadásul, ha később valamilyen módosítást kell végrehajtani az oldal egy elemén, akkor a kódban minden egyes helyen módosítanod kell, ahelyett hogy ezt csak egyszer tennéd meg.

### Hogyan kerülheted el ezeket a problémákat?

Ezért születtek a template-kezelő (sablon) rendszerek, melyekből mára már elég sokféle létezik. A lényegük, hogy segítenek külön választani az üzleti logikát az adatok megjelenítésétől és éppen ezért az [MVC](http://hu.wikipedia.org/wiki/Modell-n%C3%A9zet-vez%C3%A9rl%C5%91?ref=blog.fps.hu) alapú keretrendszerek szerves részét képezik.

Mi is az MVC (model-view-controller)? Egy olyan szerkezeti minta, ami rétegekre bontja az alkalmazást azért, hogy az adatok elérése, az üzleti logika és az adatok megjelenítése elkülönüljenek egymástól. A model (modell) gondoskodik az adatok eléréséről, a view (nézet) pedig arról, hogy az adatok a felhasználó számára megfelelő módon jelenjenek meg, végül a controller (vezérlő) feladata, hogy összegyűjtse az adatokat és átadja a megfelelő view-nak megjelenítésre. Ez a minta csökkenti a szerkezeti bonyolultságot és megnöveli a rugalmasságot, illetve a felhasználhatóságot.

Az MVC-ben a korábban említett template-kezelő rendszerek tulajdonképpen a view-k, amelyek megjelenítik az adatokat. Ezek a template-ek újra felhasználhatóak és több részre bonthatóak. Egymásba is ágyazhatod őket – akár többször is – és tartalmaznak számos hasznos funkciót, melyek segítenek az adatok megjelenítésében, az egyszerűbb szerkezet elérésében. Például rendelkeznek vezérlési szerkezetekkel, így bizonyos dolgokat feltételhez köthetsz, ami hasznos tud lenni olyankor, amikor többféle hasonló megjelenítendő elem van az oldaladon, de valamiben mégis kicsit eltérnek. Ezeken felül használhatsz ciklusokat is, amivel létrehozhatsz ismétlődő HTML elemeket és töltheted fel őket egyszerűen adatokkal.

### Milyen template-kezelő rendszert használj?

Nos ez egy olyan kérdés, amiről mindenkinek megvan a maga véleménye, a magyar közösségben nagyon elterjedt [Smarty](http://www.smarty.net/docs/en/?ref=blog.fps.hu) egy lehetséges opció, de vannak más jó template-kezelők is. Ilyen például a [Twig](http://twig.sensiolabs.org/?ref=blog.fps.hu), amely több MVC keretrendszer részét is képezi. Ajánlom a [Composert](https://getcomposer.org/?ref=blog.fps.hu), amivel könnyedén telepítheted a Twiget más keretrendszerekhez is. A Composer egy csomagkezelő, amivel letöltheted a szükséges csomagokat úgy, hogy megadod neki a függőségeket egy JSON alapú konfigurációs fájlban, majd parancssorból lefuttatod.

Sok keretrendszernek megvan a maga template-kezelő rendszere, mint például a [Laravelnek](http://laravel.com/?ref=blog.fps.hu) a [Blade](http://laravel.com/docs/5.0/templates?ref=blog.fps.hu#blade-templating), vagy a [Phalconphp](http://phalconphp.com/en/?ref=blog.fps.hu)\-nek a [Volt](http://docs.phalconphp.com/en/latest/reference/volt.html?ref=blog.fps.hu). Ezek használata meglehetősen hasonló, de azért van némi eltérés a szintaktikájukban. Érdemes lehet kipróbálni többfélét is. Számomra a Twig eddig a legjobb választás. Rövid, egyszerű a szintaktikája és mindent tud, ami kellhet. Például könnyedén el lehet vele tüntetni a whitespace-eket, így a sokak által használt megoldás végre feledésbe merülhet, amikor inline-block elemeket szeretnél egymás mellé tenni.

Hagyományos megoldás:

```markup

<div><!–
        –><div>foo</div><!–
        –><div>foo</div><!–
–></div>

```

Twiges megoldás:

```markup

{% spaceless %}
        <div>
                <div>foo</div>
                <div>foo</div>
        </div>
{% endspaceless %}

```

A Twig rengeteg remek dolgot tud még, ezek mind megtekinthetőek leírással és példákkal a [dokumentációjában](http://twig.sensiolabs.org/documentation?ref=blog.fps.hu). 

Fontos szerepe van a kód tisztaságának, egyszerűségének és átláthatóságának. A rugalmasságról már nem is beszélve. Érdemes elgondolkodnod azon, hogy kipróbálj te is egy, vagy akár több template-kezelő rendszert. Véleményedet és tapasztalatodat oszd meg velem hozzászólásként, örömmel veszem. ;)
### Miért oszd meg a tudásod másokkal?
URL: https://blog.fps.hu/tudasmegosztas-elonyei/
Last updated: 2026-07-17T08:37:16.000Z
Az ember természetes ösztöne a tudásmegosztás. Lehetővé teszi számára, hogy kapcsolódjon másokhoz és együtt, csoportosan tevékenykedjen. Őseink már a kezdetben is történeteket meséltek egymásnak és lerajzolták ismereteiket. Miért? Hogy túléljenek. Az első igazi forradalmi változást a könyvnyomtatás hozta, amely iszonyatosan felgyorsította az információ terjedését. Jelenleg, a digitális forradalom korában, exponenciálisan nő az információ mennyisége és annak terjedési sebessége. Elképesztő, hogy az emberiség által előállított információhalmaz több mint 90%-a, az elmúlt két évben keletkezett.

[![exponcenciális görbe, ami mutatja a keletkezett információ mennyiségét az idő függvényében](https://blog.fps.hu/content/images/2015/12/generated-information-by-human.gif)](http://www.slideshare.net/bradfrostweb/death-to-bullshit-now-with-80-more-bullshit?ref=blog.fps.hu)

Mélyen hiszek abban, hogy a tudásmegosztás nagyszerű lehetőség arra, hogy a világunk egy sokkal jobb hely legyen. Nem titkolt célja ennek az írásnak, hogy téged is arra ösztönözzelek: ne tartsd magadban a tudásod! Elvégre mi hasznod van abból, ha te ugyan nagyon okos vagy, de csak ülsz a szuper ötleteiden? Hidd el, neked sem jó, ha sóherkedsz. A világ körülötted vajon több lesz így tőled? Ha pedig attól félsz, hogy tőled semmit sem lehet tanulni, akkor ezt azonnal verd ki a fejedből.

> „Még soha sem találkoztam olyan emberrel, aki olyan tudatlan lett volna, hogy semmit sem tudtam volna tőle tanulni.”  
> – Galileo Galilei

Összegyűjtöttem, hogy neked miért jó az, ha megosztod, amit másoktól tanultál. Ne csak kopipésztelj, hanem mindig tedd hozzá saját gondolataid, érzéseid és történeteid a tanultakhoz. Amint látod, én is éppen így teszek, mint mindig. Jöjjön hát a lista.

### 1\. Önfejlesztés

Azáltal, hogy rendszerezned kell magadban az ismeretanyagot és újra átveszed az információ morzsákat, azok sokkal mélyebben rögzülnek agyadban. Kialakul benned egy belső motiváció, hogy a témának alaposan utána járj és utána olvass. Ergo a megosztással magad is fejlődsz!

### 2\. Segítesz másoknak

Ugye milyen jó, amikor valami után keresgélsz, és nyomban megtalálod rá a választ? Gondolj arra, hogy másoknak ugyanígy örömet szerzel, ha leírod és elérhetővé teszed azt, amit tudsz. A tudásmegosztással elősegíted mások fejlődését, növeled a tanulás hatékonyságát és hozzájárulsz az innovációhoz. (Lásd WikiPedia – támogasd!)

### 3\. Önbizalom fejlődés

Először is létrehozol valamit. Szimplán az alkotás folyamata elégedettséggel tölt el. Nem beszélve arról, hogy ha egy feladatot befejezel, az eleve örömöt okoz. Külön kiemelem, hogy a visszajelzés önmagában is egy örömforrás. Márpedig, ha adsz, akkor bizony kapsz. Hideget-meleget. A pozitív visszajelzések fejlesztik az önbizalmad és végső soron boldogabb leszel.

### 4\. Személyes márkaépítés

Ne félj attól, hogyha kiteszed a tudásod, akkor többé rád nem lesz szükség! A valóságban – és ezt tapasztalatból mondom – több megkeresés érkezik hozzám, mint valaha. Ugyanis bizalmat építesz a tudásod megosztásával. Akkor hát miért félsz? Ráadásul ez a bizalom automatikusan arra sarkall, hogy még jobb légy a területeden és még többet tudj. Minél többször osztod meg a tudásod, annál több lesz neked.

### 5\. Kapcsolatépítés

A témáddal foglalkozó emberekhez előbb vagy utóbb eljut az üzeneted és ők reagálni fognak rá. Kiegészítik, helyrepofozzák, más szemszögből megvilágítják – mindezekből végeredményben mindenki csak profitál. Emlékszem, milyen egyedül éreztem magam kb. 8 évvel ezelőtt, mikor a UX világában először elmerültem, és nem volt kivel átbeszélnem az olvasottakat. Aztán elindítottam a [kolboid blogot](https://blog.kolboid.eu/?ref=blog.fps.hu "kolboid blod – UX, pszichológia") és csakhamar megismertem jó pár okos szakembert. Így aztán részt vehettem a UX Budapest meetup szervezésében és közben sokat, nagyon sokat tanultam ezektől az emberektől. Thx ;)

### 6\. Üzlet

Bármivel is foglalkozol, szinte biztos, hogy emberekkel kell együttműködnöd. Nem beszélve arról, hogy biztos vannak ügyfeleid, akikkel közösen kell építened valamit. A tudásmegosztás nagyszerű eszköz arra is, hogy edukáld őket. Sőt! Kiküszöbölheted a félreértéseket. Hatással lehetsz a szakmádra, berögzült mítoszokat számolhatsz fel. Cégen belül elképesztő sebességgel lehet fejlődni szimplán azáltal, hogy beszélsz az ismereteidről és meghallgatod mások tapasztalatait. Hiszem, hogy egy szervezet hatékony működésének alapja a tudásmegosztás. Az ügyfelekkel és a csapattársaiddal való produktív együttműködés pedig fellendíti az üzletet.

> „Oszd meg a tudásodat másokkal: ez az egyik módja annak, hogy halhatatlan légy.”  
> – Dalai Láma

### Csináld!

Adj elő meetupokon, konferenciákon. Írj blogot, cikkeket, egyszerű és rövid social media posztokat. Mesélj a környezetednek! Segítsd minden erőddel a hasznos tartalom terjedését! Oszd meg a tudásod!
### Hogyan készítettünk egy logót?
URL: https://blog.fps.hu/logo-keszites-folyamata/
Last updated: 2026-07-17T08:37:24.000Z
### A projekt

Codecool logótervezés egy honlaphoz

#### Brief

A feladat tömören annyi volt, hogy: „programozói suli"

Szerencsés helyzetben voltam, mert az ügyfél szabad kezet adott, csupán annyi megkötés volt, hogy fiataloknak szól, friss és tükrözze az iskola tevékenységét.

![A forma kialakulása](https://blog.fps.hu/content/images/2015/12/logo_04-1.png)

#### Forma

Miből indulhattam volna ki, mint…

– Ahh értem, szóval olyan programokat nem fognak oktatni, amire a kacsacsőr jellemző. Pedig mennyi, de mennyi inspiráció?! Akkor milyen programok? – Hangzott el a beszélgetés csapaton belül.

Így maradtunk a kapcsos zárójelnél. Jó kiindulási alap volt, de elég hamar unalmassá és sablonossá vált. Viszont jól tükrözte mind a programozást, mind az összetartó erőt, amit sugallni szerettünk volna az elejétől a logóval. Ezért következett a játék a zárójelekkel. Kialakult az 1a-n és 1b-n látható forma. És valahogy így, ahogy a 2\. képen látszik, egy duplikálás során összeforgattam és megpillantottam a 3\. képet. Itt elindult a lavina. Gyorsan lett belőle 4., majd akkor azt is forgattam és 5., aztán színekkel játszadozva 6\. kép. Ekkor jött a szikra. Origami.

**Origami**

> „…fejleszti a kreativitást, memóriát és gondolkozást.”  
> – [WikiPedia](http://hu.wikipedia.org/wiki/Origami?ref=blog.fps.hu)

Mintha az általam ismert programozókat fogalmazta volna meg három szóban. És így született meg a 7\. kép.

![Finomítás folyamata](https://blog.fps.hu/content/images/2015/12/logo_05-3.png)

#### Finomítás

Amikor kialakultak a későbbi színek és a forma adott volt, még mindig nem éreztem azt a „flatsége” ellenére, hogy ennyi, kész. Valahogy szerettem volna visszahozni a mélységét, éreztetni a rétegeket és az egymásra épülést. Igen, leírva furán hangzik, de erre egy árnyék pont elégnek tűnt. (8a, 8b).

Így jött létre a 9a-n látható embléma. Egy jó darabig azt hittem a figurális részével készen vagyok, ekkor születtek olyan vadhajtások, mint a 9b.

Ám egy kis pihenő után amikor ránéztem, még mindig nem éreztem, hogy teljes lenne. Elkezdtem először a több árnyék (10.) módosításokat, amiről hamar letettem, mely annak ellenére, hogy mélységet adott, pont az ellenkező hatást váltotta ki. Ezért inkább megfordítottam és domborulat lett, árnyék helyett fény. (11.) Erre ha most is ránézek még mindig azt érzem, hogy nem kell hozzányúlni. Igazából olyat nem is szoktam mondani, hogy kész.

![Tipó kialakulása](https://blog.fps.hu/content/images/2015/12/logo_07.png)

#### Tipó

Az egész blokk azért kapott egy számot, a 12-t, mert… Inkább nem is emelnék ki annyira semmit. Sőt. Nem is lenne „szabad” megmutatnom a fenti verziókat, de ez egy blogposzt. Valami mókás dolgot el kell helyezni benne. Ugye? Maradjunk annyiban, hogy elég ha csak az legalsót nézitek. Az lett a végleges. Hogy miért ekkora a betűköz és a mérete, abban a következő bekezdésben térek inkább ki.

![A logó végleges formája](https://blog.fps.hu/content/images/2015/12/logo_08.png)

#### A logó

1:2\. Ez lett a végső arány, mint a képen is látható. (13.) Sokáig variáltam, hogy mi lenne a legjobb, és az ügyféllel is tologattuk le-fel, nagyítottuk, kicsinyítettük… Azt hiszem a kép jól leírja a végső formát és választ ad a betűközre, illetve a méretére.

És mi fog történni, ha nem lesz elég a magasság az oldalon? Adta magát. A 14\. képen az az állapot látható, amikor a parallax oldal eltünteti a headert.

A 15\. pedig már csak ráadás. Ezt a nézetet még nem használjuk sehol. Még.

Összességében nagyon szerettem ezt a projektet és logó is közel került hozzám. Ha szeretnétek „élőben” is megtekinteni, csak klikklejetek, vagy írjátok be a böngészőbe, hogy: [codecool.com](http://codecool.com/?ref=blog.fps.hu)
### Környezetbarát betűtípus
URL: https://blog.fps.hu/kornyezetbarat-betutipus-eco-font/
Last updated: 2026-07-17T08:37:34.000Z
21\. század. Globális felmelegedés, környezeti hatások, ökolábnyom… És a nyomtatással hogy álltok? Igen, tudom, nem szoktatok már olyan sokat nyomtatni. Biztos? Újrahasznosított papír. És mi újság a festékkel?

Ha a környezetvédelem kerül szóba, rendszerint a legalapvetőbb dolgokra gondolunk: szelektív hulladékgyűjtés és kistársai. Persze, ez nagyon fontos, sőt. Ugyanakkor, ha szántok rá időt és végiggondoljátok a napi rutint, ti is rádöbbentek majd, mennyi apró(-nak tűnő) ponton lehet még változtatni és „jobbá tenni a világot”. Idézőjel, mert közhely, de mint minden közhely, ez sem alaptalan.

Mi hisszük, hogy egyénileg és csapatban is tehetünk egy élhetőbb világért. A környezettudatosságnál alapvetően nem fő szempont a szépség vagy a design. Pedig ha a kettőt kombináljuk, valami olyat kapunk, ami pont az erre érzékenyebb fiatal generációt fogja meg (és persze mindenki mást is, akinek fejlett a szépérzéke).

![font minta előnézet](https://blog.fps.hu/content/images/2015/12/1-2.jpg)

**Miért fontos ez?**

Mert ők, mi, ti a jövő. A [Grey London és a Ryman (Dan Rhatigan type designer)](http://www.rymaneco.co.uk/?ref=blog.fps.hu "Ryman Eco Font for free") is felismerte ezt, és egy gyönyörű, környezettudatos és mellesleg ingyenes fontot készítettek, amivel a világ bármely pontján csökkenthető a tintafelhasználás. Átlagban a standard fontokhoz képest **33%-kal kevesebb tintát használ nyomtatáskor**. Használjátok bátran!

**Köszönjük a Ryman hozzájárulását, hogy kiterjesztette a licence-t és az fps webügynökség számára (Vigyázat! Kizárólag mi terjeszthetjük!) lehetővé tette a font módosítását és terjesztését.**

**Ezt fogyasszátok, ne a tintát!**

[Töltsd le a fontot (0 letöltés)](https://www.fps.hu/presentations/ryman-eco-with-latinext.zip?ref=blog.fps.hu "Letöltés")
### Húzzuk le tender
URL: https://blog.fps.hu/tervezes-folyamat-tender-palyazat-huzzuk-le/
Last updated: 2026-07-17T08:37:45.000Z
Ha valamit jól akarsz csinálni, akkor nincs más út mint a hosszas előkészítés és tervezés, tervezés hátán. Igazából teljesen mindegy miről van szó, a profi végtermék csakis így születhet meg, vagy egy óriási véletlen folytán, amire azért van példa (szerencse).

Képzeld el mi lenne ha a házat, amiben élsz nem tervezték volna meg előre. Ha kicsit skicceltek volna előtte, váltottak volna néhány szót a burkolókkal, a vizesekkel, az áramosokkal és mindenki a saját gondolata alapján csinálná a dolgát. Nem kétséges, hogy egy lakhatatlan kreálmány születne végül, vagy x-szer vissza kellene bontani a házat az alapokig és újrahúzni. Érdekes módon a digitális alkalmazások nagy része még mindig így készül. Nem csoda, hogy tele vannak az app store-ok, az internet használhatatlan oldalakkal, eszközökkel, programokkal, appokkal. Jobb esetben a ház külső falait szépre festik, mert hát azt látják úgyis kívülről, de ettől még az lakhatatlan, vagy jobb esetben kényelmetlen marad, nem is beszélve a biztonságról.

Még egy ház építésénél is figyelembe veszik, hogy kiknek szánják azt és nekik milyen igényeik vannak, hogyan fognak ott élni. Mégis miért teszik ezt oly kevesen digitális környezetben?

### 80% tervezés – 20% kivitelezés

Ez most nem a Pareto–elv. :) Meggyőződésem, hogy egy igazán sikeres projekt esetén összességében a tervezésre fordított effortnak valahol 80% körül kell lennie és „csak” a többit (\~20%) kell kivitelezésre hasznosítani. Tudom, baromi türelmetlenek vagyunk, már csinálni kell, akarjuk és teszed, tesszük is.

### Digitális projektek

Másik kapitális probléma, ami felett nem lehet elsiklani. A tendereket kiírók valamiért előre meghatározzák maguknak, hogy mikorra kell elkészülnie a terméknek. Ezt az időpontot szimplán az üzleti céljaik alapján tűzik ki. Minden esetben megkapjuk, hogy ez nem kőbe vésett határidő és ha a pályázó megindokolja, akkor el lehet tőle térni. Szavak szintjén ez nagyon jól hangzik, de a valóság az, hogy nem téged fognak választani. ;)  
Mi ennek a következménye? Ha eleve nem adnak elég időt rá, akkor azt bizonyosan a tervezési szakasz sínyli meg, abból vágnak le (jellemzően a lenti folyamat első három szakaszát).

Sajnos a legtöbb esetben még az üzleti célok sincsenek meghatározva, jól körülhatárolva. Egyszerűen kapsz egy *feature* listát vagy mutatnak egy mintát, hogy ezt és ezt csináld meg. De mi a cél, miért jó ez az ügyfélnek, ki fogja egyáltalán használni és miért, ügyfél oldalon ki fog ezzel foglalkozni és hogyan? Számtalan kérdés megválaszolatlanul lebeg. Nem bírom ki, hogy ne tegyek említést a tendereknél kötelezően elvárt „látványterv” kérdésről. Teljesen értelmetlen, amíg a fenti kérdések tömkelege nem tisztázódott. Ha arról akar meggyőződni az ügyfél, hogy alkalmas vagy szép grafikát gyártani, akkor inkább kérjen korábbi portfóliót és az alapján döntsön.

Ha már digitális környezet – mert mi ehhez értünk – a tervezés alatt mit is értek?

### Process

Számomra Jesse James Garrett zseniális könyvében ([The Elements of User Experience](http://www.amazon.com/The-Elements-User-Experience-User-Centered/dp/0735712026?ref=blog.fps.hu) – 2002) kidolgozott design folyamat az etalon, amit a kivitelezéssel (grafikai kidolgozás, fejlesztés stb.) egészítek ki:

- Tervezési stratégia
- Hatókör
- Struktúra
- Felülettervezés
- Grafikai tervezés
- **\+ Kivitelezés** *(a kakukktojás)*

![A UX elemei képen ábrázolva](https://blog.fps.hu/content/images/2015/12/ux-process.gif)

Teszem hozzá ezek a lépések nem egymást követő szigorú lépések, hanem jócskán egymásba nyúló fázisok, sőt az utolsó négy pont párhuzamosítható és minden szereplő folyamatos együttműködését igényli. Ebből a folyamatból is jól látszik, hogy a kivitelezés milyen arányban szerepel és ez még mindig kevés!

A kivitezelés (többnyire fejlesztés) nagyon fontos etap, amit szintén tervezni kell. Rendszeresen kimarad az architektúra, az adatbázis, a szoftver tervezés, melyek hiánya egyrészt az alkalmazás megfelelő sebességét, rugalmasságát, skálázhatóságát, másrészt pedig a határidők betartását veszélyezteti. Sok helyen látom, hogy pontosan tudják, szükség van a tervezés ezen fázisára is és az önbecsapós, névleg tervezést választják önmaguk megnyugtatására (idő!). Khmmm.

A másik paradoxon a tendereken, hogy meg kell mondanod előre milyen áron tudod a teljes projektet megvalósítani. Ez szinte mindig feszültséggel jár. Visszakanyarodva egy ház építéséhez: hogyan tudod akár csak megbecsülni a kivitelezés költségeit, ha azt sem tudod még pontosan mit kell megvalósítani? …és akkor még csak a kivitelezésről beszélek. Ilyenkor jön a korábbi tapasztalatokon alapuló becslés, ami már bocsánat, de igazából egy nagy bullshit és ez alapján fognak kiválasztani a tenderen. wtf?!

Erre egyetlen megoldást látok, mint ahogy a házak építése esetén is. Ügyfél oldalon első körben tervezést kell tendereztetni, azt elvégeztetni és végül a kivitelezést külön tenderben. Akár ugyanaz az ügynökség is végezheti mindkét jól elhatárolható szekciót. El lehet képzelni további felosztást is, de az már talán az utópia irányába mutat. (ok, kicsit sántít)

### Konklúzió

Véleményem szerint elsősorban ügyfél oldalon szükséges a változás, amire meglehet egyetlen megoldás az edukáció. Ilyen jellegű képzésekre, coachingra van szükség és az igényre, hogy ezeket a cégek ki is aknázzák. Ügynökség oldalon el kell felejteni a „kell a projekt okán bullshit gyártást” és tanítani az ügyfeleket. Miért? Egyszerű. Mindenkinek az az érdeke, az embereken (felhasználókon) át az ügyfelekig és végül az ügynökségekig, hogy jól használható, értékes, hiteles, értelmes, hasznos, élményt nyújtó és mindenki számára elérhető digitális termékek szülessenek.

### Disclaimer

*„Ember tervez – Isten perverz.”* – írta ifj. Müller Péter. Igen, bármennyire alaposan tervez az ember szinte biztos, hogy nem tud mindenre gondolni, illetve a valóság mindig közbeszól, de ettől még tervezni kell! Ez ügyben a kedvenc mondásom, mely egy képzésen hangzott el és nagyon megragadt bennem:

> „A terv egy út a sikerhez. Ha terveztél, akkor egyszer már nyertél!”
### 19 epic mondat a fejlesztők szájából
URL: https://blog.fps.hu/19-epic-mondat-a-fejlesztok-programozok-szajabol/
Last updated: 2026-07-17T08:37:56.000Z
Annál nincs felemelőbb, ha az ember képes saját magán nevetni. Belefutottunk egy [posztba](http://www.itworld.com/article/2695431/what-programmers-say-and-what-they-really-mean.html?ref=blog.fps.hu), amin rendkívül jól szórakoztunk. Nyomban lefordítottuk a relevánsakat és jócskán kibővítettük a saját életünkben előforduló beszólásokkal.

Egy valódi üzenete azért ennek is van:  
**Sose vedd igazán komolyan magad!**

![19 epic fejlesztői mondat](https://blog.fps.hu/content/images/2015/12/1_big-1.jpg)
### Sebesség, visszajelzés újra
URL: https://blog.fps.hu/oldalsebesseg-visszajelzes-ujra-es-ujra/
Last updated: 2026-07-17T08:38:05.000Z
Minden felhasználói tesztelés két legfontosabb konklúziója, hogy az alkalmazás gyorsasága és az egyértelmű visszajelzés mennyire fontos az emberek számára. Ismét leírom és még százszor fogom leírni, hogy erre a két dologra kell a leginkább figyelmet fordítani legfőképpen a fejlesztés során, no meg tervezéskor is.

### Sebesség

Írtam már erről egy posztot „[Sebesség optimalizáció mindenek felett](https://blog.fps.hu/sebesseg-optimalizalas-gyors-honlap/)” címmel, ami inkább fejlesztőknek szól. Kiemelve a két legfontosabbat:

- Az oldal betöltési sebessége javarészt a kliens oldaltól függ.
- A sebességnek közvetlen hatása van a konverzióra és nem utolsó sorban a felhasználók (emberek) élményindexére.

> „A sebesség a tiszteletről szól.  
> Tiszteld a felhasználóid és vissza fognak térni!”  
> – Brad Frost

### Visszajelzés

Erről is írtam már „[Visszajelzés függők vagyunk](https://blog.fps.hu/visszajelzes-feedback-ui/)” címmel. Minden tesztelésen látszik, hogy az emberek megnyomnak egy gombot, keresnek stb. és értelten arccal bámulják mi történik, majd kattintanak, tappolnak megint és megint és még hangot is adnak elégedetlenségüknek. Roppant módon szükséges az azonnali visszajelzés, hogy a rendszernek időre van szüksége. Használj [progress button stylest](http://tympanus.net/Development/ProgressButtonStyles/?ref=blog.fps.hu), loading, process megoldásokat, bármit, mert ezzel nagyban segítheted, könnyítheted a felhasználók életét, ami végsősoron mindannyiunk érdeke és célja.

*[A fejléc kép forrása](https://www.pinterest.com/pin/223983781442904406/?ref=blog.fps.hu)*
### Email building, avagy vissza a kőkorszakba
URL: https://blog.fps.hu/responsive-email-building/
Last updated: 2026-07-17T08:38:16.000Z
Munkám során gyakran készítek email sablonokat hírlevél kampányokhoz, weboldalak kimenő leveleihez. Első ránézésre a feladat könnyűnek tűnik, hiszen rövid terjedelmű, kevés elemet tartalmaz, struktúrája lényegesen egyszerűbb mint egy weblapé. Mégis rengeteg kihívást rejt, ennek oka a modern webes megoldások kényszerű nélkülözése.

Sajnos a levelező kliensek primitívek a mai technológiákhoz viszonyítva. Ha csak az Outlook asztali kliensét nézzük, mely 2007/2010/2013-as verziói alatt a World HTML motorját használják megjelenítéshez máris a 90-es évek megoldásaira kell szorítkoznunk és még szót sem ejtettünk a megannyi webes kliensről és más asztali alkalmazásról.

### Van, hogy nem lehet

A fentiekben leírtam, hogy lehetőségeink korlátozottak így vannak olyan esetek, amikor egy-egy designt nem lehet sablonként megvalósítani. Például egy reszponzív hírlevél kampányt nem lehet elkészíteni egy három oszlopos design alapján úgy, hogy az megfelelően jelenjen meg desktop és mobil levelező klienseken egyaránt. Röviden: harcsapaprikást ne akarj főzni, ha a spájzban csak paprikás krumplihoz való van. Ezért érdemes a fejlesztőt már a grafikai tervezés során bevonni a megvalósíthatóságot illetően.

> „A szép rögtön kell.  
> Az igazra alszunk egyet.  
> Lelkünknek elég a kép.  
> A testnek keret is kell.”  
> – Márai Sándor

### Email sablon felépítése

A „táblázatos design”-ról már biztos hallottál, letűnt korok megoldása, sokan csak úgy emlegetik, hogy az internet őskorában weboldalak elrendezésére használt módszer. Ez helytálló, viszont email sablon készítéshez a legjobb megoldás, ugyanis a levelező kliensek csak ezt a felépítést jelenítik meg helyesen. Ahhoz, hogy a táblázatod valóban csak a struktúra kialakítását szolgálja, érdemes néhány alapértelmezett értéket felülírni. *Cellspacinget*, *cellpaddingot* és *bordert* állítsd nullára, a *border-collapse*\-nek pedig adj *collapse* értéket.

Olvasottak alapján a felépítés kialakítása során érdemes figyelned arra, hogy a táblázatokat négy szintnél mélyebben ne ágyazd egymásba. Tapasztalataim szerint ennél többre nincs is szükség. Tesztek alapján öt szintnél sem jelentkeznek problémák, ennek ellenére úgy gondolom, akkor is érdemes kerülni és törekedni az egyszerűbb felépítésre.

Egy szokványos sablon felépítésénél a keretedet egy meghatározott szélességgel fixálod, ami általában 620 és 500px közé esik. Reszponzív sablon esetén keretednek fluidnak kell lennie, ami a fent említettek tükrében sem egyszerű, és még hozzá jön a megannyi mobil eszköz és levelező alkalmazás.

Egyik módszer a kereted reszponzívvá tételéhez, ha a fixen meghatározott kereted szélességét egy töréspontnál felülírod 100%-ra. Akár csak a website-oknál, ebben az esetben is mediaquery segítségével. Sajnos a *mediaquery*\-t a Campaignmonitor adatai alapján a Gmail mobil alkalmazás egyik platformon sem támogatja, ahogy a Windows Phone 7 és 8 natív alkalmazásai sem.

Egy másik módszer, ha keretednek szélességét már az elején 100%-kal határozod meg és *max-width* tulajdonsággal szabályozod a maximális szélességet. Ebben az esetben számolnod kell azokkal a platformokkal és kliensekkel, melyek nem támogatják a *max-width*\-et. Ilyen az Apple mail illetve az Outlook is.

Ahhoz, hogy az Apple mail eme hiányosságát kiküszöböld, ismét a mediaquery-t kell használdod, és meghatározott eszköz szélességtől ráerőltetni a fix szélességet.

```css

<style type="text/css"> 
@media only screen and (min-device-width: 601px) {
    .content { width: 600px !important; } 
} 
</style>

```

Az Outlook ennél kicsivel körülményesebb. Ebben az esetben ki kell egészítened a keretedet egy újabb kerettel, amelynek megjelenését HTML feltételhez kötöd és fix szélességet adsz neki. Így meg is oldottad azt a problémát, hogy sablonod Outlookban teljes szélességben jelenjen meg.

```markup

<!--[if (gte mso 9)]>
<table width="600" cellpadding="0" cellspacing="0" border="0">
    <tr>
        <td>
            <![endif]-->
            <table class="content" cellpadding="0" cellspacing="0" border="0">
                <tr>
                    <td>
                        [tartalom]
                    </td>
                </tr>
            </table>
            <!--[if (gte mso 9)]>
        </td>
    </tr>
</table>
<![endif]-->

```

Windows Phone-ról még nem tettem említést. Eddigi tapasztalataim szerint az egyetlen, amit tehetsz,  elem nyitása után elhelyezett *<!–\[if (IE 7)|(IEMobile)\]>* feltételben *<style>* elemek között fixen meghatározod a táblázatok és elemeinek a szélességét. Ennek hátulütője, hogy álló/fekvő helyzettől, mobil eszköz méretétől függetlenül 320px szélességben jelenik meg.

Több lehetőség is van reszponzív levél sablonod keretének kialakításához, de talán utóbbi az, ami a legtöbb esetben megfelelő megjelenést fog biztosítani a legtöbb kliensben. Természetesen mit sem ér egy jó keret, ha a *meta viewportról* megfeledkezel, és a dokumentum szélességét nem az eszköz szélessége adja.

```markup

<meta name="viewport" content="width=device-width,
initial-scale=1">

```

### Stíluslapok használata

Alapesetben egy weboldal CSS kódját különálló fájlokba írjuk, melyben szelektorokkal hivatkozunk a dokumentum egyes elemeire. Így választjuk külön a struktúrát a megjelenéstől. Email template esetében ez az irányelv nem követhető. Némelyik levelező kliens ugyanis kiszűri a *<link>* elemet, amellyel hivatkozni tudnánk CSS fájljainkra. Lehetőségünk van a *<head>*\-ben *<style>* elem használatával stílus definiciókat meghatározni, de a szelektorok kezelése szintén eltérő kliensenként.

Egy RoundCube a *<style>* elemben megadott szelektorokat írja át, és az általa megadott azonosítón keresztül érvényesíti a kódunkat.

```css

#messagebody div.rcmBody #csak-egy-id { } 

```

Outlook.com esetében az elem *class* és *id* tulajdonságai is átírásra kerülnek, és eléjük kerül egy ecx prefix.

```css

.ExternalClass #ecxcsak-egy-id { }

```

A cél mind két esetben az, hogy az email template és a webes kliens ne nyúljon bele a másik megjelenésébe, ami az első esetben nem egészen teljesül – mivel, ha a RoundCube által meghatározott azonosítót használnánk, az érvényes lenne a mi elemünkre is.  
A Gmail még egy érdekes eset. Nem szűri ki a *<style>* taget, a szelektorokat is átírja, hogy egy generált osztályon keresztül történjen a hivatkozás, de minden elemről leszedi a *class* és *id* tulajdonságot.

Mindezek tükrében csak az úgynevezett inline CSS (azaz elemenként a *style* tulajdonsággal megadni a rávonatkozó formázási szabályokat) tűnik jó megoldásnak. Mint ahogy említettem, a szelektorok kezelése eltérő, úgy a CSS tulajdonságok támogatottsága is. Sablon készítése közben kiváló útmutatást ad a már fentebb említett [Campaign Monitor](https://www.campaignmonitor.com/css/?ref=blog.fps.hu "The Ultimate Guide to CSS"), ahol összeszedték elemek, szelektor típusok, CSS tulajdonságok támogatottságát kliensekre levetítve egy táblázatban.

### Képek

Grafikai elemek megjelenítéséhez egy website-nál *backgroundot* használunk. A *background* tulajdonságot kivétel nélkül támogatják a kliensek, sajnos az Outlook asztali és webes kliensei csak részlegesen, mivel a *background-images*\-t nem ismerik. Így minden képi elem megjelenítéséhez az *<img>* elemet kell használnod.

A képek közötti eltartások megoldására több lehetőséged is van, például: *padding*, *margin*, *border*, sortörés (a vertikális eltartáshoz). Az igazi megjelenítési probléma szintén az Outlooknál jelentkezik, mivel ezek közül egyiket sem veszi akadály nélkül, kivéve a *paddingot* tábla elemre és a sortörést. Két kép közötti eltartás megtartására a legjobb, amit tehetsz, ha a képeket már eltartással vágod méretre.

Amit fontosnak tartok górcső alá venni, az a méret. Mert igenis számít a méret. Kereted már fluid, de ha tartalmad közé egy 1020 pixel széles képet ágyazol be, nem lesz az. Ezért az *<img>* elemeid szélességét határozd meg százalékosan, és érdemes *max-width*\-et használni.

![Windows Phone mail screenshot](https://blog.fps.hu/content/images/2016/01/windows-phone-mail-screenshot.jpg)

Mindezek ellenére a *max-width*\-et az Outlook nem ismeri és szélesség 100 százalékra állításánál nem a keret szélességéhez viszonyít, hanem a kép méretéhez, így végeredményül a kép kitolja keretét és szétesik minden, amivel órákig foglalkoztunk. Az egyetlen, amit tehetsz, hogy a képeket méretre vágod, pontosan akkora szélességűre, mint a tartalom.  
Remélem azt nem kell megemlítenem, hogy a leírtak egy ikon megjelenítéséhez használt *<img>*\-re nem vonatkoznak – ebben az esetben fix méreteket kell meghatároznod.

Ha már méretekről van szó, a fájlméretekre is érdemes figyelmet fordítani, hisz nem szeretnéd egy hírlevéllel lerágni az olvasó fél havi adatkeretét. A [tinypng.com](https://tinypng.com/?ref=blog.fps.hu "Shrink PNG files and so on…") lehetőséget biztosít arra, hogy png és jpg képeid fájlméretét drasztikusan lecsökkentsd.

### Végezetül, néhány gondolat

Mielőtt belekezdenél, a grafikai tervvel szemed előtt gondold végig a struktúrát, lásd az elemeket a design mögött – így elkerülheted, hogy később a részletekbe merülve próbálj újra fókuszálni az egészre.

**Tesztelj, tesztelj, tesztelj.**

Tapasztalataim alapján a folyamat legnagyobb része a tesztelés és a finomhangolás. Email building közben el kell vetned minden új technológiát és leporolnod az elavult megoldásokat, mindazontúl egy újszerű kihívás és kreativitást próbáló feladat.

Végezetül ne felejtsd el, hogy miért csinálod. Olvashatóbb és szerethetőbb formába öntöd a tartalmat, ami akár több ezer emberhez is eljuthat.  
Remélem sikerült ebben most segítenem.

*UPDATE*  
A Google végre 2016\. szeptember végére megígérte, hogy [Gmailben támogatni fogja a media query-k használatát](https://www.campaignmonitor.com/blog/email-marketing/2016/09/responsive-email-support-in-gmail-is-coming/?ref=blog.fps.hu)! \\o/
### Kétirányú eseményvezérelt kommunikáció valós időben
URL: https://blog.fps.hu/ketiranyu-esemenyvezerelt-kommunikacio-valos-idoben-node/
Last updated: 2026-07-17T08:38:26.000Z
Bizonyára sokatok számára ismerős az a helyzet, amikor olyan funkciót kell készíteni, ami másodpercenként vagy percenként frissít tartalmat. Például egy üzenőfal vagy egy értesítő.

A legegyszerűbb megoldás, egy *setInterval()*\-féle függvény, amit x időközönként meghívsz. Ennek viszont az a nagy hátránya, hogy valószínűleg nem minden x-edik időben következett be változás a frissítendő tartalomban, így feleslegesen terhelődik a kliens és akár a szerver is. Akadhatnak olyan esetek is, amikor gyakorlatilag valós időben kell tartalmat frissíteni, ha valamilyen változás történt az adatokban, mint például a csevegő alkalmazások esetében. Az előbbi példával élve ez egy-egy néhány másodpercenként lefutó függvényt jelentene, ami rengeteg felesleges művelettel járna és nem is lehetne valós idejűnek nevezni. Ehhez hozzájárul még az is, hogy a böngészők csak néhány kapcsolatot engednek egyidejűleg nyitva tartani, ami szintén lassabbá teheti az oldalad.

### Csöbörből vödörbe

Az egyik leggyakrabban használt módszer a valós idejű reagálásra az úgynevezett „[Long-polling](http://en.wikipedia.org/wiki/Push%5Ftechnology?ref=blog.fps.hu#Long%5Fpolling "Long polling push technology")” technika, ami az *AJAX* alapjaira épül, így aszinkron kommunikációval valósul meg. Ennek lényege, hogy a szerver egy ciklusban ellenőrzi, hogy történt-e változás, de a ciklus nem a végtelenségig fut – meg kell adni neki egy bizonyos lépésszámot, ami után el kell döntenie, hogy volt változás vagy sem. Ha történt változás, akkor elküldi válaszban *AJAX*\-on keresztül, majd újra meghívódik, viszont ha nem, akkor üres választ ad és ismét meghívódik (a korlátozott számú egyidejű nyitott kapcsolat miatt). Ez a folyamat a háttérben zajlik, így a felhasználót nem befolyásolja semmiben sem, de sajnos ennek továbbra is az a hátulütője, hogy feleslegesen hajtunk végre műveleteket a szerveren. Például a ciklusban mindig lekérdezünk egy adatbázistáblát, hogy megvizsgáljuk, történt-e benne változás.

### Hogyan kényszeríthetnénk a szerveroldalt esemény alapú I/O műveletekre?

2009-ben született meg a nyílt forráskódú *Node.js*, melyet úgy alkottak meg, hogy kéréseket fogadjon és válaszokat küldjön aszinkron módon. Ahogyan azt már sejtheted, ez egy JavaScript alapú rendszer, melyhez a Google kifejlesztette a szintén nyílt forráskódú [V8 JavaScript futtató motort](https://code.google.com/p/v8/?ref=blog.fps.hu "V8 JavaScript Engine"). A [Node.js](http://nodejs.org/?ref=blog.fps.hu "Node.js® is a platform built on Chrome's JavaScript runtime") kiválóan alkalmas a túlterhelés minimalizálására és a skálázhatóság növelésére, hiszen eseményvezérelt a működése, így elég csak akkor műveletet végeztetni vele, ha történt valami, amire reagálni kell. Például egy csevegő alkalmazásban a csevegő felek egyike új üzenetet küldött, amit a szerver eltárol, maga az üzenet küldése pedig kivált egy eseményt a szerveren és erre az eseményre reagálva a többiek számára is elküldi az új üzenetet.

### Hogyan tovább?

Annak érdekében, hogy a kommunikáció kétoldalú, duplex és kéréstől független legyen, létrehozták a [WebSocketet](http://hu.wikipedia.org/wiki/WebSocket?ref=blog.fps.hu "WebSocket"), mely ma már a W3C szabványok közé tartozik. A kapcsolatok kiépítésekor a kliens egy kézfogási kérelmet (*handshake request*) küld, amire a szerver kézfogási válasszal reagál. A kézfogás a HTTP-re hasonlít, de valójában nem az – lehetővé teszi azonban, hogy a szerver a kézfogási kérelmet a HTTP protokoll szerint értelmezze, majd átválthasson a *WebSocket* használatára. Sajnos nem teljes a támogatottsága, mivel az Internet Explorer 10 előtti verzióiban nem használható – ki gondolta volna? – és nagy sajnálatra az Android böngészők 4.4 előtti verzióiban sem működik. Nem kell pánikba esni, nincs minden veszve, ugyanis nem feledkeztek meg azokról sem, akik még a régebbi Internet Explorereket vagy Android böngészőket nyúzzák!

[![IE must die](https://blog.fps.hu/content/images/2015/12/141230104204-ie-must-die-1024x576.jpg)](http://money.cnn.com/2014/12/30/technology/internet-explorer/?ref=blog.fps.hu "IE must DIE")

Az optimális megoldás a [Socket.io](http://socket.io/?ref=blog.fps.hu "SOCKET.IO – FEATURING THE FASTEST AND MOST RELIABLE REAL-TIME ENGINE"), amely remekül használható a *Node.js*\-sel együtt. Kétirányú eseményvezérelt kommunikációt hivatott létrehozni valós időben, melyhez a korábban említett *WebSocketet* használja elsődlegesen, illetve rendelkezik egy polling visszakapcsolással (fallback) a korábban említett támogatottsági problémák miatt. A *Socket.io* hivatalos oldalán egy egyszerű, valós idejű chat segítségével nézheted meg, hogy mire is képes a cucc. A chat forráskódja megtalálható a letöltött *Socket.io*\-ban példaként, illetve a hivatalos oldalon találhatóak további egyszerűbb példák a működésére és használatára vonatkozóan. Léteznek még alternatívák, amelyek hasonlóképpen működnek, úgymint az [Actionhero.js](http://www.actionherojs.com/?ref=blog.fps.hu "actionhero  The Reusable, Scalable, and Quick node.js API Server."), [Elephant.io](http://elephant.io/?ref=blog.fps.hu "Elephant.io provides a socket.io client fully written in PHP"), és még ezeken kívül is van jó néhány.

Manapság nagy szerepe van az optimalizálásnak, egyrészt az oldalak betöltési sebessége, másrészt a gördülékeny, felhasználóbarát működés miatt, és persze az erőforrás megtakarítás sem utolsó szempont. Érdemes jól átgondolni a megvalósítást és a használt technológiákat mielőtt nekikezdesz a funkciók megvalósításának.
### Fejlesztés és keresőoptimalizálás
URL: https://blog.fps.hu/fejlesztes-keresooptimalizalas-seo/
Last updated: 2026-07-17T08:38:35.000Z
Ha SEO-ról van szó, mindenki rögtön az online marketingesre gondol, hogy majd ő foglalkozik vele, tudja, mit kell tenni. Viszont a keresőoptimalizálás egy része teljesen technikai dolog, melyeket a fejlesztők állítanak be. Ezért is fontos, hogy a fejlesztők is tisztában legyenek a különféle beállításokkal.

Technikai oldalról alapvető fontosságú, hogy a keresőrobotok jól tudják olvasni és megérteni a forráskódot. A keresőrobotok egyre fejlettebbek, egyre több szintaktikai elemet ismernek fel és értelmeznek, ezért is szükséges a megfelelő minőségű kódbázis.

A következőkben végigveszem azokat a témákat, amelyek érintik a fejlesztőket, hogy tisztában legyenek a keresőoptimalizálás folyamatával és ennek megfelelően alakítsák ki a kódokat.

### Oldalbetöltődési sebesség

Az, hogy az oldalbetöltődés a lehető leggyorsabb legyen, igazi szakmai kihívás. Figyelni kell arra, hogy:

- nagyobb szerveroldali terhelés esetén se lassuljon az oldalbetöltődés
- az egy képernyőn megjelenő tartalom töltsön be a leggyorsabban
- ne legyen túl terjengős a forráskód, amit lehet, egyszerűsíts vagy hívj meg külső forrásból
- ne legyenek nagyméretű fájlok, amik automatikusan betöltődnek
- responsive site esetén a sok CSS miatt különösen figyelj az optimalizálásra

#### Miért jó SEO szempontból a gyors oldalbetöltődés?

A weboldal betöltődési sebesség már régóta rangsorolási faktor. Minél gyorsabban tölt be az oldal, annál magasabb pontszámot kap ez a faktor. A különböző faktorok súlyozása időről időre változik, de nemcsak a SEO miatt fontos a gyors betöltődés, hanem a felhasználói élmény miatt is (nem mellesleg ez is egy rangsorolási faktor).

![hajók fennakadva](https://blog.fps.hu/content/images/2015/12/csonak.jpg)

### URL átirányítások

Egy weboldal életciklusa alatt folyamatosan változik, új tartalmak kerülnek fel, régiek szűnnek meg, kisebb-nagyobb átalakítások történnek, amelyek hatással lehetnek az URL struktúrára. A keresők folyamatosan indexelik a weboldalt, így problémát jelenthet, ha az eddig működő link egyszer csak eltűnik az oldalról, ugyanis a keresőben a megszűnést követően még hónapokig is elérhető lehet a tartalom, mire onnan is eltűnik. Ha a felhasználó egy ilyen linkre kattintva jut az oldalra, fontos, hogy relevánst tartalomra érkezzen. Ezért is fontosak a különféle átirányítások.

Az állandó átirányításra a 301-es átirányítást használd, ez a leggyorsabb és legegyszerűbb módja a megszűnt tartalmak átirányítására. Arra figyelj, hogy párban legyenek az URL-ek, véletlenül se mutasson önmagára az átirányítás. Ha olyan linket kell átirányítani, aminek az új struktúrában nincs párja, lehetőleg a tartalmilag legközelebb álló oldalra, vagy végszükség esetén a nyitóoldalra kell irányítani. Semmiképp se maradjon hibás oldalra mutató URL, se SEO szempontból, se felhasználói szempontból sem jó. Legyen 404-es oldal, ami továbbirányítja az egyéb tartalmakra a felhasználót. Ideiglenes átirányításokhoz a 302-es átirányítást használd, ezek általában néhány napos, vagy maximum néhány hetes átirányításokra való.

Figyelj arra is, hogy az URL-ek csak egyféleképpen szerepeljenek. Ne éljen külön életet a www-s és a www nélküli verzió, vagy a / és / nélküli végződésű URL-ek. Teljesen mindegy, melyik lesz az alapértelmezett, a lényeg, hogy a másik verzió automatikusan irányítson át a választott verzióra.

Ha a webhelyed szolgáltató szerverén Apache fut, és 301-es átirányítást akarsz használni, hozzá kell férned a szerver .htaccess fájljához is. A [beállításokhoz szükséges tutorialokat innen](http://httpd.apache.org/docs/2.0/howto/htaccess.html?ref=blog.fps.hu "Apache Tutorial: .htaccess files") érheted el.

#### Miért fontosak az átirányítások SEO szempontból?

A keresők szigorúan büntetik a tartalom duplikációt, ezért kell különösen odafigyelni az átirányításokra. Ha ugyanaz a tartalom két különböző URL-ről is elérhető, az már duplikációnak számít. Ha mégis előfordul azonos tartalom (például egy cikk több rovatban/kategóriában is megjelenik), akkor canonical tag-et használva meg kell valamelyik tartalmat eredetinek jelölni, a többi oldalon pedig erre hivatkozni, így a kereső nem fogja büntetni.

Ha a keresőkben lévő régi linkekre kattintva nem jut releváns információhoz a felhasználó, azonnal továbblép az oldalról, ami szintén rontja egyrészt a SEO eredményeket, másrészt a felhasználói élmény is rossz lesz, legközelebb már nem fog a linkünkre kattintani a keresőben.

### Sitemap, robots.txt

Keresőoptimalizálás szempontjából mindkét fájl nagyon fontos, ugyanis az oldal feltérképezése ezeknek a fájlok átvizsgálásával kezdődik. A robots.txt a weboldal feltérképezéséhez szükséges információkat (is) tartalmazza, a sitemap.xml pedig a weboldal azon URL-jeit, amit a keresőknek láthatóvá akarunk tenni. Mindkét fájl a webszerveren az adott oldal gyökérkönyvtárában kell, hogy legyen. Ha valamiért nem sitemap.xml-ként nevezzük el a sitemap fájlt (pl. azért, mert több is van belőle) akkor a robots.txt-be írjuk bele a pontos elérési nevet, hogy a keresőrobotok megtalálják.

![kisgyerek átnéz egy fakerítés résén](https://blog.fps.hu/content/images/2015/12/eva_shutt-1.jpg)

### Mikroformátumok

A mikroformátum (rich snippets vagy microformats) olyan adatforma, melyekkel különböző adattípusok egységesítésére használnak. A mikroformátum a keresőrobotok és az emberek számára is értelmezhető és olvasható adat. Funkciója, hogy az egységes forma révén kereshetővé válnak az adatok, ezáltal más alkalmazásokba is egyszerűen beilleszthetőekké válnak, továbbá a szemantikus web egyik fontos alappillére.

Ezekhez a tartalmi típusokhoz javasolt mikroformátumot használni:

- személyekhez kapcsolható adatok (pl. név, születési idő, lakcím, stb.)
- termékekhez kapcsolható adatok (pl. könyvek esetében szerző neve, könyv címe, kiadás éve, stb.)
- cégekhez, üzletekhez kapcsolható adatok (pl. cég székhelye, fióktelep címe, nyitva tartás, stb.)
- receptek (pl. összetevők, értékelés, kalóriatartalom, stb.)
- események (pl. egy esemény neve, időpontja, stb.)
- zene (pl. egy zenei album címe, zeneszámai, lejátszási idő, előadók, stb.)
- breadcrumbs (azonosítja az útvonalat és megjeleníti a találati lista szövegében)

#### Miért fontos SEO szempontból?

Keresőoptimalizálás szempontjából a mikroformátumok picit kakukktojáshoz hasonlítanak, ugyanis nem rangsorolási faktor a használata, tehát „elvileg” nem befolyásolja a keresőkben való megjelenést. A gyakorlat azonban azt mutatja, hogy mivel hasznos információkat lehet a találati oldalon megjeleníteni segítségükkel, többen kattintanak a linkre, nagyobb forgalmat generálnak az oldalnak.

### URL struktúra kialakítása

Az oldal URL struktúrájának kialakításakor törekedni kell arra, hogy amennyire lehet, kerüld el a különféle számokból, kódokból álló linkeket. Mennyivel beszédesebb egy ilyen link [http://www.mysite.com/services/product](http://www.mysite.com/services/product?ref=blog.fps.hu) mint egy ilyen [http://www.mysite.com/123123/?id=0123](http://www.mysite.com/123123/?id=0123&ref=blog.fps.hu) Az URL struktúrában elhelyezett kulcsszavak is számítanak SEO szempontból, és ez is nagyban segíti a tájékozódást az oldalon. Ha nincs breadcrumbs, akkor is látjuk az URL-ben, milyen mélységben járunk az oldalon.

Van, hogy elkerülhetetlen, hogy valamilyen ID-t használj a linkben, pl. egy webshop esetében, ahol egy termék több méretben vagy színben is kapható, ilyenkor egyszerűbb ID alapján beazonosítani a terméket. De ettől még használhatod a kulcsszavas struktúrát pl. mywebshop.com/products/spoons/teaspoon?id=12

#### Miért fontos ez SEO szempontból?

A megfelelő URL struktúra megléte rangsorolási faktor. Már az URL-ben megjelenő kulcsszót is figyeli indexeléskor a keresőrobot, hogy mennyire releváns az oldal további tartalmára nézve.

![hegymászó mászik egy meredek sziklafalon](https://blog.fps.hu/content/images/2015/12/hegymaszo.jpg)

### Tartalmi elemek

Vannak tartalmi oldalról meghatározott elemek, ilyen például a title, description, a többszintű headings elemek, vagy képek esetében a kép title és kép alt szöveg, link title stb. Technikai oldalról célszerű biztosítani, hogy a tartalom feltöltéskor a felhasználók egyedileg tudják állítani ezeket, ha nem megoldható, akkor számíts rá, hogy ezekkel még dolgod lesz. Sok open source keretrendszer biztosítja ezeket a beállítási lehetőségeket. (pl. WordPress)

### Mérőkódok elhelyezése

Minden üzleti célú weboldalnál számtalan dolgot kell mérni különféle mérőkódok segítségével. Ehhez többféle mérőkódot kell elhelyezni a weboldal forráskódjának megfelelő pontjaira. Ilyen pl. a különféle analitikai kódok, úgymint Google Analytics, hirdetésekhez remarketing kódok, eseménykövetések, paraméteres linkek és még sorolhatnám. A Google kifejlesztett a mérőkódok kezelésére egy olyan platformot, a Google Tag Managert, amely arra hivatott, hogy nem kell egyesével befűzni a mérőkódokat az oldalakba, hanem mindössze egyetlen kód kerül csak be az oldalba, és egy felületen keresztül lehet definiálni és paraméterezni a meghatározott célokat. Ha nem használsz Tag Managert, figyelni kell arra, hogy a mérőkódok a megfelelő helyekre kerüljenek és ne üssék egymást, különben nem lesz pontos a mérés. A kódok általában a head rész aljába, a body tetejére vagy aljára szoktak kerülni.

### Összegezve

A fentiekből kiderül, hogy könnyebb ezen szempontok szerint kialakítani egy új weboldalt, mint utólag ezeket beállítani/átalakítani. Keresőoptimalizálás szempontjából a technikai beállítások fontosak, de önmagában a jó SEO eredményhez már nem elég, a tartalmi dolgok is elengedhetetlenek a sikerhez.
### Kérlek, maradj még!
URL: https://blog.fps.hu/kerlek-maradj-meg/
Last updated: 2026-07-17T08:38:45.000Z
Van az úgy, hogy a funkcionalitás és a használhatóság nem elég. Bizonyára sokatok számára ismerős a helyzet, hogy van egy alkalmazás, legyen az akár egy weboldal, akár egy mobil app, de igazából bármilyen termék, mely funkcióival segíti bizonyos emberek munkáját, életét, sőt még használata is egyszerű, azonban a felhasználók mégsem tartanak ki mellette huzamosabb ideig. Ilyenkor van az, hogy értetlenül állsz a terméked előtt és csak fogod a fejed, hogy már megint mi a franc bajuk van a felhasználóknak, mit nézhettél el?

### Mi lehet a baj?

A probléma megoldásának kulcsa az emberi igényekben, az emberi viselkedésben keresendő. Mit miért csinálunk mi emberek és mi motivál minket?

Létezik az úgynevezett [emberi szükségletek piramisa](http://hu.wikipedia.org/wiki/Maslow-piramis?ref=blog.fps.hu "Maslow-piramis"), melyet Abraham Maslow alkotott meg, és ez a piramis az emberi szükségleteket állítja egymáshoz viszonyítva fontossági sorrend szerint.  
A Maslow-piramisnak létezik egy, a felhasználói élményre kiélezett változata, mely az ember egy adott termékre vonatkozó 6 különböző igényét sorakoztatja fel.

[![user experience hierarchy of needs learning](https://blog.fps.hu/content/images/2015/12/user-experience-hierarchy-of-needs-learning.jpg)](http://www.growthengineering.co.uk/user-experience-hierarchy-of-needs-learning/?ref=blog.fps.hu "the User Experience Hierarchy of Needs")

A terméked akkor lesz igazán sikeres és népszerű, ha a piramis mind a 6 pontját képes lefedni.

- Legyen funkcionális
- Legyen megbízható
- Legyen használható
- Legyen kényelmes
- Legyen kellemes
- Legyen jelentőségteljes

Számos olyan termékkel találkoztam, mely az első 3-4 pontot tökéletesen lefedi, ám ahhoz, hogy a felhasználókban kialakuljon az a bizonyos függés, mely miatt beleszeretnek egy termékbe, az utolsó két ponton múlik igazán (persze az alap igények kielégítése után/mellett).

Lássuk, mely módszerek alkalmazásával egészítheted ki hiányos piramisod, és csábíthatod el a felhasználókat.

### Esztétikum, szépség és a viselkedés

A csábítás első fegyvere az esztétika. Mi, emberek hajlamosak vagyunk azt hinni a szép dolgokról, hogy azok jobban működnek. Tovább megyek, jó megjelenésű emberekben hajlamosabbak vagyunk megbízni, mint kevésbé attraktívabb megjelenésű társainkban.

Azonban az esztétika alatt nem szabad csak a művészi, felületes dolgokra gondolnod. Az agyunk mintázatok és korábbi tapasztalataink segítségével ismeri meg a körülöttünk lévő világot. Erre építve, a különböző természetes mintázatok alkalmazásával, mint például a színek, árnyékok, alakzatok stb. segítségével, hozzásegítheted a felhasználókat, hogy minél könnyebben, a lehető legkevesebb gondolkodással felismerhessék az alkalmazásod egyes részeinek funkcióját, jelentését anélkül, hogy akár terjengősebb szöveges magyarázatot igényelnének.

[![image](https://blog.fps.hu/content/images/2015/12/regisztracio.jpg)](http://blog.kolboid.eu/gomb-call-to-action-button/?ref=blog.fps.hu "A gomb az gomb")

Alkalmazásod felülete minél inkább megfelel a valós világ szabályainak, a felhasználóknak annál egyszerűbb lesz használni azt. Ha az elkészült felhasználói felület fizikai modelljét könnyedén fel tudod építeni, akkor az agy számára egyszerű lesz megérteni azt, egyébként kognitív disszonanciát okozhat.

![ablakok fedése](https://blog.fps.hu/content/images/2015/12/window.jpg)

*Mely ablakok vannak hozzád közelebb?*

### Játékos csábítás

Az alkalmazások nagy része telis-tele van olyan, általános és jól ismert elemekkel, melyek lássuk be, hogy nem túl izgalmasak, sőt egy idő után nagyban hozzájárulnak a monotonitás kialakulásához. Például ott vannak a szöveges visszajelzések. Ezeken a helyeken, amikor csak lehet, használj könnyed, esetleg vicces nyelvezetet, természetesen csak akkor, ha ezt a kontextus és az adott célközönség „megengedi”.

[![image](https://blog.fps.hu/content/images/2016/01/mailchimp.jpg)](http://www.dtelepathy.com/blog/design/blasting-off-into-the-4th-dimension?ref=blog.fps.hu "Showing Personality")

Ha tudod, hogy a felhasználóidnak rendszeresen igénybe kell venniük az alkalmazásod által nyújtott szolgáltatásokat és funkciókat, akkor sejtheted, hogy hamar monotonná válhat a számukra. Ezt könnyedén kiküszöbölheted, ha azokat a folyamatokat, melyeket gyakran végeznek, megtöröd és ezzel kimozdítod őket az unalmas rutinjukból. Például, ha az imént említett szöveges visszajelzéseket rendszeresen változtatod. Remek példa erre a Google kereső, melyben a logó rendszeresen változik.

Azonban arra ügyelj, hogy drasztikus változtatásokat ne eszközölj, főleg olyanokat, melyek befolyásolják a megszokott folyamatokat, hiszen azzal csak megnehezíted a munkájukat.

![Google Doodles](https://blog.fps.hu/content/images/2015/12/google.jpg)

Egy másik jól bevált módszer lehet, ha hagyod, hogy a felhasználóid kibontakozhassanak, kifejezhessék önmaguk. Az élet egyik mozgató rugója az önkifejezés, miért hagynád ezt ki az alkalmazásodból? Ha emlékszel még a Messenger alkalmazásra, akkor biztosan tudod, hogy ott lehetőséged volt egyedi emotikonokat használni. Aztán, mikor a Skype átvette a helyét, hiszed vagy sem, többen is sérelmezték, hogy ezt itt nem tehetik meg. Már az is elég, ha biztosítod a felhasználóidnak, hogy személyre szabhassák azokat a felületeket, melyeket rendszeresen használnak, ezzel is kényelmesebbé, otthonosabbá téve saját maguk számára a környezetet.

### Az ördög a részletekben van

Az alkalmazásodban lévő összetett folyamatokat érdemes több, kisebb részre bontanod a felhasználóid számára, hogy jobban átlássák az utat, melyet meg kell tenniük. Továbbá érdemes valamiféle folyamatjelzőt is használnod a számukra, hogy egyrészt lássák hol tartanak, másrészt, hogy ösztönözve legyenek: „Ahh, már csak ennyi?”.

![profil kitöltése progress barral mutatva százalékosan](https://blog.fps.hu/content/images/2015/12/profile.jpg)

Ezt a darabolós módszert űrlapok esetében is alkalmazhatod oly módon, hogy bizonyos mezőket csak abban az esetben társz a felhasználó elé, ha elért egy bizonyos pontra a kitöltésben, illetve akkor, ha egyáltalán szükségessé vált azok kitöltése is.

[![inline contextual actions](https://blog.fps.hu/content/images/2015/12/action.jpg)](http://www.lukew.com/ff/entry.asp?246&ref=blog.fps.hu "Inline Contextual Actions")

Gyakran előforduló helyzet, hogy bizonyos dolgokat el akarunk végeztetni, fogadtatni a felhasználókkal. Ilyen esetekben jobb, ha nem kérdésként tesszük eléjük a lehetőséget, például: „Szeretnéd meghívni a barátaidat is?”, ehelyett sokkal célravezetőbb kijelentést tenni: „Hívd meg barátaid!”.

### Gemifikáció

Manapság igen felkapott dolog, nem hiába. Talán az egyik legerőteljesebb megtartó erő. Olyan technikák és módszerek tárháza, mely játékosságot, versengést biztosít a felhasználóknak.

> „A gamification technikák az emberekben a versengés, az eredmények, a státuszok, az önkifejezés és az altruizmus iránt rejlő vágyakat aknázzák ki és használják fel. A gamification kulcsstratégiája a vágyott feladatok megvalósítása utáni jutalmak biztosításában rejlik.”  
> – [WikiPedia](http://hu.wikipedia.org/wiki/Gamification?ref=blog.fps.hu "Gamification")

A gemifikáció megfelelő alkalmazásával valódi függőséget alakíthatsz ki a felhasználóidban az alkalmazásod felé. Erejére remek példa a különféle szerencsejátékok, kaszinók és online játékok elsöprő sikere. A Doulingo nevű web illetve mobil alkalmazás is ezen alapszik, ahol is úgy tanulhatsz angolul, hogy egyrészt versengsz önmagaddal és a barátaiddal is, miközben különféle kitüntetéseket szerezhetsz és nyomon követheted fejlődésed, rendszeres visszajelzést kapsz.

[![gemikáció példák](https://blog.fps.hu/content/images/2015/12/game.jpg)](http://theacademiclunchbox.wordpress.com/2013/04/18/duolingo-and-gamification/?ref=blog.fps.hu "Duolingo and gamification")

A kirótt feladatok sikeres elvégzéséért a felhasználó jutalmat söpörhet be. Jutalom lehet például szintlépés, pontszerzés, különféle jelvények, vagy akár virtuális fizetőeszköz is.

### Végszó

*Stephen Anderson [*Seductive Interaction Design*](http://www.amazon.com/Seductive-Interaction-Design-Effective-Experiences/dp/0321725522?ref=blog.fps.hu "Seductive Interaction Design: Creating Playful, Fun, and Effective User Experiences")* című könyve egy remek olvasmány lesz mindazok számára, akik nem egyszerű feladatorientált alkalmazásokat akarnak gyártani droidoknak, hanem igazi, embereknek szóló terméket, élményt szeretnének készíteni!
### 10+1 hasznos bookmarklet nem csak fejlesztőknek
URL: https://blog.fps.hu/11-bookmarklet/
Last updated: 2026-07-17T08:38:56.000Z
A bookmarkletek egy vagy több funkció megvalósítását teszik lehetővé az éppen böngészett oldalon a címsorba másolt (vagy könyvjelzőből meghívott) JavaScript kód által. Gyakorlatilag módosíthatjuk vele az oldal kinézetét, működését, vagy plusz hasznos funkciókat húzhatunk be. a lehetőségek majdnem korlátlanok, ezáltal használhatóságuk is igen sokrétű.

### 1\. Live.js

Az általam egyik leggyakrabban használt eszköz, ami sitebuld során nagy mértékben megkönnyítheti a munkádat. Az oldal újratöltése nélkül jelennek meg a CSS és JavaScript fájlokban eszközölt módosítások, elősegítve a „pixeltologatás” folyamatának gördülékenységét.

[Használd te is!](http://www.livejs.com/?ref=blog.fps.hu "Live.js")

### 2\. Viewport Resizer

Reszponzív oldalak teszteléséhez nyújt nagy segítséget a Viewport Resizer. Előre beállított képernyőméretekkel lehet tesztelni a megjelenést és külön hasznos funkció, hogy van benne újratöltés gomb is, így nem kell frissítened az oldalt, majd újra betöltened a bookmarkletet.

[Használd te is!](http://lab.maltewassermann.com/viewport-resizer/?ref=blog.fps.hu "Viewport resizer")

### 3\. Design

Amikor „pixeltologatásra” kerül a sor, vagy csak ellenőrizni akarjuk, hogy egy vonalba kerültek-e az egyes elemek, nagy segítséget nyújthat a design által biztosított vonalzó vagy grid.

[Használd te is!](http://www.sprymedia.co.uk/article/design?ref=blog.fps.hu "Design")

### 4\. Performance bookmarklet

A weboldal betöltődés gyorsasága egyre fontosabb tényezővé vált manapság, így érdemes kiemelt figyelmet fordítani az optimalizálásra. A performance bookmarklet használatával elemezheted az egyes requestek eloszlását és felkutathatod a kritikus pontokat.

[Használd te is!](https://github.com/nurun/performance-bookmarklet?ref=blog.fps.hu "Performance bookmarklet")

### 5\. Edit

Nem, nem egy hölgyről van szó. :) A HTML5 szabvány már támogatja az egyes elemek helyben történő szerkeszthetőségét. Ezzel a rövid kóddal az oldalad minden szöveges elemét szerkeszthetővé teheted. Hasznos lehet, ha át akarsz írni valamilyen szöveget tesztelés gyanánt.

[Használd te is!](http://downloadsquad.switched.com/2008/07/08/edit-this-page-useless-but-fun-bookmarklet-lets-you-edit-any-we/?ref=blog.fps.hu "Edit")

### 6\. Scratch+

Biztosan Te is jártál már úgy, hogy valamit gyorsan le kellett jegyzetelni szövegfájlba, de túl macerás lett volna megnyitni a notepadet. A Scratch+ a böngésződ aktuális tabját minimalista jegyzettömbbé alakítja, és már használhatod is.

[Használd te is!](http://mrcoles.com/one-line-browser-notepad-bookmark/?ref=blog.fps.hu "Scratch+")

### 7\. Keepvid

Közösségi oldalak hírfolyamában rendszeresen szembesül az ember a „hogyan töltsek le youtube videót?” kérdéssel. A Keepvid egyszerű megoldást nyújt a probléma orvoslására. Csak egy kattintás és már mentheted is le az éppen nézett videót.

[Használd te is!](http://keepvid.com/extensions?ref=blog.fps.hu "Keepvid")

### 8\. Readability

Rengeteg olyan oldallal találkozhatsz, ahol nagyon jó írások vannak, viszont a fejlesztők nem igazán fordítottak figyelmet az olvashatóságra. A Readability bookmarklet kiemeli a tartalmat és a szemnek kellemes módon formázza be azt.

*Update (2019\. november 7.)*  
A Readability időközben megszűnt,  
[nézz alternativákat!](https://toptenalternatives.co/readability/?ref=blog.fps.hu)

### 9\. Count

A Count egy oylan bookmarklet, amivel a karakterek (továbbá szavak és sorok) számát mérheted az éppen megnyitott oldalon. Nincs más dolgod, mint kijelölni az adott szögegrészt. Content editoroknak hasznos lehet.

[Használd te is!](http://charcount.appspot.com/?ref=blog.fps.hu "Count")

### 10\. SEO Bookmarklet

SEO szakembereknek kifejezetten hasznos eszköz, ami összetett és mindenre kiható elemzést készít az oldalról a linkek vizsgálatát, a robots.txt és sitemap ellenőrzését magába foglalva.

[Használd te is!](http://twkm.ca/seo-bookmarklet/?ref=blog.fps.hu "SEO Bookmarklet")

### +1\. Kickass

Abszolút haszontalan, viszont szórakoztató bookmarklet, amivel bármilyen oldalt csatatérré változtathatsz és szétlőhetsz minden elemet :)

[Használd te is!](http://kickassapp.com/?ref=blog.fps.hu "Kickass")

Ha esetleg még több bookmarklet között szeretnél böngészni, ajánlom [ezt a kategorizált listát](http://www.hongkiat.com/blog/100-useful-bookmarklets-for-better-productivity-ultimate-list/?ref=blog.fps.hu "100+ Useful Bookmarklets For Better Productivity | Ultimate List"), de ha Neked is van kedvenced, várom kommentben a linkeket!
### 274 Vector Solid Icons for free
URL: https://blog.fps.hu/274-vector-solid-icons-for-free/
Last updated: 2026-07-17T08:39:05.000Z
Completely free vector based line icons for you by our gorgeous design team at fps web agency. In the pack you can find icons in PDF, SVG, EPS, PNG formats and finally as an icon font.

Download and use it wherever and whenever you want. Free for personal and commercial use as well.

**Citations are appreciated and appropriate.**

Here is a preview of all icons. You can download the whole set as a zip file below the image.

![274 Vector Solid Icons by fps web agency](https://blog.fps.hu/content/images/2015/12/fpssolidicons_zoldhatter.jpg)

[Download for free (0 downloads)](https://www.fps.hu/presentations/274-solid-icons-pack-by-fps.zip?ref=blog.fps.hu "Download 274 Vector Solid Icons pack for free") 

[We made a line version of this icon set, download it as well!](https://blog.fps.hu/274-vector-line-icons-for-free/)
### Flat szervezet
URL: https://blog.fps.hu/flat-szervezet/
Last updated: 2026-07-17T08:39:15.000Z
Lassan 15 éve tesszük a dolgunk, elképesztően sok projekten vagyunk túl. Volt köztük számtalan sikeres, büszkén vállalt termék és sok félrecsúszott, sikertelen megoldás. 15 év sok idő és mondhatom még mindig keressük azt a struktúrát, amivel a lehető legjobb egyedi megoldásokat lehet kihozni magunkból. Nem könnyű.

Nem tudom más hasonló méretű, tevékenységű cégek hogy vannak ezzel, de mi itt szakadatlan variálunk, kombinálunk, permutálunk. Próbáltunk már mindent, jártak itt a legkülönbözőbb tanácsadók, coach-ok és átadták legjobb tudásokat. A projekt szervezettől a klasszikus hierachikus modellig bejártuk az utakat.

Kialakult bennem a meggyőződés és a hit, hogy az fps számára az egyetlen jó felépítés a lapos szervezet. Nálunk kizárólag kreatív, értékes, erős egyéniséggel megáldott emberek tevékenykednek. Igen, a programozótól a tervezőig mindenki kreatív. Kimondottan utálom, mikor a programozókat „gyári munkásoknak” tekintik, sajnos nem egyszer találkoztam már ezzel a szemlélettel. A kódolás egy igazán izgalmas világ, töméntelen megoldási lehetőséggel, melyekből megtalálni a helyes uta(ka)t magasfokú kreativitást igényel. PONT.

Összefogni ennyi alkotó szellemű egyént, csapattá formálni valóban nagy kihívás. Egyikőjük sem bírja a kötöttséget, az „alárendelt” szerepet. Ha ilyen környezetbe kerülnek frusztráltak lesznek, ami végsősoron a terméken tükröződik vissza. Arról nem is beszélve, hogy hamarosan továbbállnak, máshol keresik találékonyságuk kifejeződését. Ezeket az embereket nem motiválja más, mint a sikeres projektek, melyekre büszkék lehetnek, a magas szakmaisággal rendelkező csapat, a jó hangulatú környezet és a mindig új, másféle kihívás, amiből tanulni lehet, amihez szükség van a leleményességükre.

Tervező lévén design hasonlattal tudom megvilágítani a legjobban mire gondolok. Adott egy layout, maga a szervezet. Ennek a layoutnak fluidnak, responsive-nak, agilisnak kell lennie. Az egyes UI elemek a szervezetben tevékenykedők, melyek csoportosítva vannak, azaz csapatokra osztottak. A grafikai megvalósítás pedig flat. Mindenki egy szinten van, ugyanazon a célért és vízióért küzd a maga eszközeivel, szoros együttműködésben a csapatával. KOMMUNIKÁCIÓ. A flat designnak megvannak a maga problémái, ezért sokkal inkább a Google-féle material design a jobb hasonlat, azaz a lapos világból pl. drop shadow-val kiemelkednek egyes elemek. Ők azok, akik összefogják a projekteket, szállítják az információt a csapattól az ügyfélig és vica versa.

Az alapértékek: [tisztelet a köbön, alkotás és élmény](https://blog.fps.hu/fps-alkotas-es-elmeny-tisztelet/ "fps") maradnak.
### 274 Vector Line Icons for free
URL: https://blog.fps.hu/274-vector-line-icons-for-free/
Last updated: 2026-07-17T08:39:25.000Z
Completely free vector based line icons for you by our gorgeous design team at fps web agency. In the pack you can find icons in PDF, SVG, EPS, PNG formats and finally as an icon font.

Download and use it wherever and whenever you want. Free for personal and commercial use as well.

**Citations are appreciated and appropriate.**

Here is a preview of all icons. You can download the whole set as a zip file below the image.

![274 Vector Line Icons by fps web agency](https://blog.fps.hu/content/images/2015/12/fpslineicons_kekhatter.jpg)

[Download for free (0 donwloads)](https://www.fps.hu/presentations/274-line-icons-pack-by-fps.zip?ref=blog.fps.hu "Dowload 274 Vector Line Icons pack for free") 

[We made a solid version of this icon set, download it as well!](https://blog.fps.hu/274-vector-solid-icons-for-free/ "274 Vector Solid Icons for free")
### Horrorli szabadon
URL: https://blog.fps.hu/horrorli-github/
Last updated: 2026-07-17T08:39:36.000Z
Itt a Halloween, remélhetőleg már találkoztatok a [horrorli online toolunkkal](http://horrorli.fps.hu/?ref=blog.fps.hu "horrorli – your horror background noise generator"), ahol horror filmek hangeffektjeit használhatod saját ijesztgetésed háttérzajaként, vagy csak hogy játssz kollégáid, ismerőseid idegeivel. Most mindenki számára elérhetővé tettük a forrást githubon, mert sok tematikára ráhúzható a megoldás.

**Néhány ötlet:** Cartoonli, Constructli, Trafficli, Bruceli, és persze Pornli :D

#### Legyetek kreatívak és csináljatok újat ti is!

Töltsd le [a horrorli forrást githubról](https://github.com/fpshu/horrorli?ref=blog.fps.hu "horrorli github")!

Írtunk már [a horrorliról és tettünk hozzá képregényt](https://blog.fps.hu/horrorli-hatterzaj-generator/ "Horrorli a horror háttérzaj generátor – jó móka!") is, olvasd.
### A tartalomkirály trónfosztása?
URL: https://blog.fps.hu/a-tartalomkiraly-tronfosztasa/
Last updated: 2026-07-17T08:39:46.000Z
A tartalom a király. Ez folyik a csapból is már jó pár éve. Az internetre felkerülő tartalom mára brutális méreteket ölt. És ennek a nagy része értéktelen, spam tartalom. Akkor hogy is van ez? Mégsem a tartalom a király?

Az idei [Internet Hungary](https://www.internethungary.com/?ref=blog.fps.hu "Internet Hungary web site")\-n erről a témáról tartottam előadást, íme a rövid összefoglaló.

> „Content is where I except much of the real money will be made on the internet.”  
> – Bill Gates January 1996

1996-ban, amikor Bill Gates ezt a kijelentést tette, nagyjából 200 millió oldal volt elérhető a világhálón. Ma, 2014-ben 2,2 millió terabájtnyi tartalom kerül publikálásra naponta! És ez a szám folyamatosan növekszik.

Óriási mennyiségű információmennyiséggel kell megküzdenünk nap mint nap. Percenként a világban:

- 2,4 millió Google keresést hajtanak végre
- Több mint 130 órányi Youtube videó kerül feltöltésre
- 3,3 millió Facebook megosztás történik
- 1530 terabájtnyi tartalom kerül fel a világhálóra

### Óriási mennyiségű tartalom, rengeteg spam tartalommal. Hogyan igazodjunk el ebben a zajban? Hogyan ismerjük fel a minőségi tartalmakat?

Napjainkban a keresők már annyira szofisztikáltak, hogy elég nagy biztonsággal meg tudják állapítani egy tartalomról hogy minőségi vagy sem. (A Google tett is már lépéseket ezügyben, lásd Google Panda) A minőségi tartalomnak vannak kézzelfogható ismérvei, amelyek alapján könnyen beazonosíthatóak, illetve ezen ismérvek mentén előállíthatóak.

Nézzük, milyen szempontok szerint vizsgálja a tartalmakat a kereső.

3 kiemelten fontos ismérv:

- expertise – szakértelem
- authoritativeness – tekintély
- trustworthiness – megbízhatóság

![szakértelem, tekintély, megbízhatóság](https://blog.fps.hu/content/images/2015/12/141029_3_ismerv.jpg)

Ha bármelyik szempont nem megfelelő vagy valami miatt sérül, a kereső gyengébb besorolással „díjazza” az oldalt.

A weboldal célja, mondanivalójának fókuszában a FELHASZNÁLÓ álljon. A felhasználók igényeire, szokásaira kell szabni a tartalmakat, hogy számukra releváns, hasznos információkat kapjanak. Ha a felhasználó boldog, a kereső is szeretni fogja a tartalmat/oldalt. Például van egy cipőket árusító webshopunk. Biztos nagyon érdekesek a régi nagy cipészekről szóló történetek és anekdoták, de a cipő webshop látogatói nem emiatt fogják keresni az oldalt.

Készüljön rendszeresen ilyen típusú tartalom. Hogy milyen gyakorisággal, az téma/egyén függő, ki kell tapasztalni. (napi több –> havi egy) A kevesebb néha több, csak azért ne tegyünk ki valamit, mert eljött a tartalom előállítás ideje. Van elég spam tartalom már bőven az interneten, nem kell még több.

Amikor tartalomról beszélünk, ne csak a szövegre gondoljunk.

#### A tartalom három részből tevődik össze

**Main content (MC)**: az oldal fő mondanivalója (szöveg, kép, videó, űrlap, stb.) ez a rész tartalmazza a felhasználó számára legfontosabb üzenetet

**Supplemental content (SC)**: az oldal kiegészítő tartalmai. A mondanivalóhoz kapcsolódó kiegészítő dolgok, melyek a felhasználói élményt teszik teljessé. Ilyen pl. az átlátható navigáció, footer, cikkajánló, kommentek, rating, social megosztás, stb.

**Advertisement/monetisation**: hirdetések/szponzorációk óvatosan kell bánni vele, ne menjen a minőség rovásásra.

Például egy ecommerce site esetén a minőségi tartalomhoz elengedhetetlen:

- a termék neve
- termékleírás
- termékfotó
- kosár funkció
- ár

További információk bizalmat építenek, növelik a tartalom minőségét:

- termék szavatossága
- szállítási információk
- vásárlási feltételek
- méretválaszték
- színválaszték
- garancia
- fizetés menete
- vélemények
- kívánságlista
- termékkód
- hasonló termékek, stb.

Vannak másodlagosan fontos szempontok is, amelyek fontosak a minőségi tartalom ismérvéhez.

- website információk (kapcsolat, impresszum, a weboldal üzemeltetőjére/készítőjére vonatkozó infók, stb.)
- hasznos kiegészítő tartalmak (kacsolódó cikkek/termékek, ezt vették még, stb.)
- funkcionális design
- megfelelő technikai feltételek (optimalizált forráskód, 404-es hibák kiküszöbölése, törött linkek ne legyenek, stb.

### A tartalomkirály trónfosztott?

A válasz egyértelműen nem, sőt, egyre fontosabb, viszont a tartalmi kontextus is ugyanolyan fontos, sőt, egyre fontosabb lesz a jövőben.
### Hatékonyságnövelés a Gulp.js használatával
URL: https://blog.fps.hu/gulp-js-hatekonysagnoveles/
Last updated: 2026-07-17T08:39:55.000Z
Fejlesztés vagy akár sitebuild során számtalan esetben kerülhetsz szembe újra és újra lefuttatandó feladatokkal, úgy mint a CSS vagy JavaScript fájlok összefűzése, lekicsinyítése (minify), a képek tömörítése vagy a CSS preprocesszorok (SASS, LESS) használata. A [Gulp](http://gulpjs.com/?ref=blog.fps.hu "Gulp.js – The streaming build system") automatizált feladatvégrehajtó-eszközként ezen folyamatok kezelésében lehet nagy segítségedre.

A Gulp nem az első a task runner eszközök terén, a legismertebb talán a [Grunt](http://gruntjs.com/?ref=blog.fps.hu "GRUNT – A JavaScript Task Runner"), ami hamarabb jött létre, így több plugint kínál, viszont a Gulp más irányból közelített meg sok dolgot és gyors iramban elkezdett felzárkózni. Számos [összehasonlító cikk](http://jaysoo.ca/2014/01/27/gruntjs-vs-gulpjs/?ref=blog.fps.hu "Grunt vs. Gulp") és [sebességteszt](http://tech.tmw.co.uk/2014/01/speedtesting-gulp-and-grunt/?ref=blog.fps.hu "Speedtesting gulp.js and Grunt") jelent meg a két eszközről, ahol kiemelik a Gulp gyorsaságát és könnyebb használhatóságát.

A Gulp tulajdonképpen egy [Node.js](http://nodejs.org/?ref=blog.fps.hu "node.js oldala") csomag, így futtatásához elengedhetetlen, hogy telepítve legyen. Legyen az egy egyszerű feladat, élesítés előtti optimalizálás vagy folyamatosan futó, a változásokat figyelő folyamat, tökéletes megoldást nyújt a Gulp, a feladatokat összefűzve, feltételhez kötve vagy akár bonyolult módon felépítve.

Az eszköz használatát leginkább pár példán keresztül lehet megérteni, jöjjenek most ezek.

### Gulp telepítése és alapok beállítása

#### 1\. Gulp package globális telepítése

```bash

npm install -g gulp 

```

#### 2\. Gulp telepítése a projektünkbe, és függőség beállítása

```bash

npm install gulp --save-dev 

```

#### 3\. A gulpfile.js létrehozása a projekt könyvtárunk gyökerébe

```javascript

var gulp = require('gulp');

gulp.task('default', function() {
 console.log('Hello from Gulp!');
});

```

Ha nem vagy tisztában, mit is jelent a pontosan a [Node.js függőségek beállítása](https://devcenter.heroku.com/articles/node-best-practices?ref=blog.fps.hu "Best Practices for Node.js Development"), a linken hasznos tudnivalókat találsz ezzel kapcsolatban. Ezzel a pár lépéssel már rendelkezésedre is áll az eszköz és nincs más hátra, minthogy létrehozz futtatható feladatokat. Számos [leírás](http://julienrenaux.fr/2014/05/25/introduction-to-gulp-js-with-practical-examples/?ref=blog.fps.hu "Introduction to Gulp.js with practical examples") található kész megoldásokkal, de érdemes böngészni [az elérhető pluginok](http://gulpjs.com/plugins/?ref=blog.fps.hu "Gulp.js pluginok") között is.

![Gulp csslint plugin](https://blog.fps.hu/content/images/2015/12/141009_totya_alkalmankent-2.jpg)

### Alkalmanként futtatható taskok

Vannak olyan folyamatok, amiket nem szükséges minden módosítás után lefuttatnod, tipikusan ilyenek a kódminőség ellenőrző eszközök (csshint, jslint), nyelvi fájl generátorok (gettext függvénytár, po/pot generálás) vagy különböző reportot készítő scriptek (plato).

```javascript

var jshint = require('gulp-jshint');
var csslint = require('gulp-csslint');
var gulp   = require('gulp');

// $ gulp jshint
gulp.task('jshint', function() {
 return gulp.src('./lib/*.js')
   .pipe(jshint())
   .pipe(jshint.reporter());
});

// $ gulp csslint
gulp.task('csslint', function() {
 gulp.src('./css/*.css')
   .pipe(csslint())
   .pipe(csslint.reporter());
});

// $ gulp 
gulp.task('default', ['csslint','jshint']);

```

### Folyamatos figyelés

Egyes fájlokat folyamatosan figyelő és azok módosulásakor megadott taszkokat lefuttató folyamatok kezeléséhez a watch funkciót kell igénybe venned. Ez tulajdonképpen egy véget nem érő streamet hoz létre, aminek a futását manuálisan kell megszakítanod. A legjobb példa ezekre a folyamatokra a CSS és JavaScript preprocesszorok igénybe vétele.

```javascript

var gulp = require('gulp');
var sass = require('gulp-sass');

gulp.task('sass', function() {
    return gulp.src('./sass/*.scss')
        .pipe(sass())
        .pipe(gulp.dest('./css'));
});

gulp.task('watch', function () {
    gulp.watch('./sass/*.scss', ['sass']);
});

gulp.task('default', ['sass', 'watch']);

```

### Deploy, avagy élesítés

Minden oldal esetében fontos annak betöltődési sebessége, amihez már régóta léteznek bevett módszerek. Tömörítjük a képeket, megtisztítjuk a kódot a felesleges kommentektől és debug funkcióktól, összefűzzük a CSS és JS fájlokat, majd ráengedjük a minify tool-t. A Gulp megfelelő konfigurlálásával ezt egy parancs kiadásával véghez viheted, könnyen és egyszerűen.

```javascript

var gulp = require('gulp');
var concat = require('gulp-concat')
var minifycss = require('gulp-minify-css');
var uglify = require('gulp-uglify');
var svgmin = require('gulp-svgmin');
var imagemin = require('gulp-imagemin');

gulp.task('process-js', function(){
    gulp.src('./app/js/*.js')
.pipe(concat('app.js'))
    .pipe(uglify())
    .pipe(gulp.dest('./build/'));
});

gulp.task('process-css', function(){
    gulp.src('./app/css/*.css')
    .pipe(concat('app.css'))
    .pipe(minifycss())
    .pipe(gulp.dest('./build/'));
});

gulp.task('process-svg', function() {
    gulp.src('./app/img/*.svg')
    .pipe(svgmin())
    .pipe(gulp.dest('./build/img/svg'));
});

gulp.task('process-img', function () {
    gulp.src(['./app/img/*', '!./app/img/*.svg'])
    .pipe(imagemin())
    .pipe(gulp.dest('./build/img'));
});

gulp.task('deploy', ['process-css', 'process-js',
'process-svg', 'process-img']);

```

![gulp.js plugin kereső képe](https://blog.fps.hu/content/images/2015/12/141009_totya_egyeb_hasznos.jpg)

### Egyéb hasznos pluginek

Végigböngésztem az összes elérhető plugint és jópár hasznos darabot találtam köztük, amik használatát kíváncsian várom, vagy már napi szinten alkalmazom is. Egyik ígéretes lehetőség az [ftp](https://github.com/sindresorhus/gulp-ftp?ref=blog.fps.hu "Gulp FTP Deploy") / [sftp](https://github.com/gtg092x/gulp-sftp/?ref=blog.fps.hu "Gulp SFTP Deploy") kapcsolaton keresztül feltöltést megvalósító plugin, ami folyamatos fejlesztés és élesítés esetén roppant módon megkönnyítheti a munkád. Ha szeretnéd elkerülni, hogy ne maradjanak „todo”-k a kódodban, akkor könnyen rájuk tudsz keresni a forráskódban (vagy akár más stringre is) a [check plugin](https://github.com/LogRhythm/gulp-check?ref=blog.fps.hu "Gulp plugin to check for illegal expressions") alkalmazásával, továbbá érdekes és hasznos információkat kaphatsz a forráskódunkról a [Plato](https://github.com/sindresorhus/gulp-plato?ref=blog.fps.hu "Gulp Plato – Generate complexity analysis reports") által generált reportot tanulmányozva.

A fenti példák csak nagyon kis részét fedik le a Gulp nyújtotta lehetőségeknek. Ha érdekesnek találod, csak bíztatni tudlak, hogy nézz utána, hiszen jól összerakott feladatokkal nagy mértékben növelheted hatékonyságodat és megkönnyítheted a fejlesztésed menetét, továbbá növelheted kódbázisod minőségét!
### Tartalomgyártás és látogatók toborzása lead generáláshoz
URL: https://blog.fps.hu/tartalomgyartas-latogatok-toborzasa-lead-generalasahoz/
Last updated: 2026-07-17T08:40:05.000Z
A [III. Email marketing konferencián](http://www.emailmarketingkonferencia.hu/?ref=blog.fps.hu "3. Email marketing konferencia oldala") elhangzott előadásom összefoglalóját készítettem el, ahol az inbound marketing első szakaszáról, a tartalom előállításról és a látogatóterelésről beszéltem.

Percről percre hatalmas mennyiségű információ kerül fel az internetre. Például minden egyes percben 100 órányi videót töltenek fel a Youtube-ra, 3,3 millió tartalommegosztás történik a Facebookon, 2,4 millió keresést indítanak a Google keresőjében. Ebben a hatalmas „zajban” kell a tartalmaknak helyt állniuk úgy, hogy a keresők és a látogatók is megtalálják, használják. Ami nem egyszerű feladat. Nézzük, mi kell hozzá.

### Mit is nevezünk tartalomnak?

Minden tartalom. A weboldal szövege, a struktúrája, a designja, a metaadatai, mind-mind tartalom. Ezek alkotják együttesen A tartalmat. És akkor lesz ez a tartalom a felhasználók számára is értékes, ha megfelelően van strukturálva.

![Mi a tartalom? felirat](https://blog.fps.hu/content/images/2015/12/141007_tartalom_strategia.jpg)

### Mi az a tartalom stratégia?

A tartalom stratégia fő célja, hogy úgy alakítsuk ki a tartalmat, hogy az egyértelmű, jelentőségteljes legyen, és interaktív élményt nyújtson a felhasználóknak. A kommunikációnak minden szempontból hatékonynak kell lennie. És természetesen támogassa a sales tevékenységet.

![image](https://blog.fps.hu/content/images/2015/12/141007_hogyan_alakitsunk.jpg)

### Hogyan alakítsd ki a tartalmakat?

A legfontosabb, hogy egyedi, minőségi tartalmat állíts elő, amely a látogatóid számára értékes, releváns információkat tartalmaz. És ez a legnehezebb, de nem lehetetlen, sőt! Ha egyedi és értékes a tartalom, akkor a keresőoptimalizálással külön nem is kell foglalkoznod. Fontos, hogy rendszeresen készíts ilyen tartalmakat. A kevesebb néha több, ebben az esetben ez így van. Inkább legyen ritkábban frissülő tartalom, mint olyan, amely nem felel meg a fenti kritériumok valamelyikének. Van épp elég felesleges, spam tartalom a világhálón, nem kell tovább bővíteni. Megvannak a tartalmak, jöhet a következő lépés.

### Forgalmat kell generálni, de hogyan?

**Keresőoptimalizálás**: a minőségi tartalom sem garancia arra, hogy rögtön a találati lista élére ugorj, ezért szükség van némi támogatásra is ahhoz, hogy minél gyorsabban elérd a megfelelő pozíciót. A technikai beállítások mellett fontos a tartalomra mutató releváns linkek száma is.

**PPC kampányok**: bár az inbound marketing elsősorban „ingyenes” eszközöket használ, nem árt főleg az elején megtámogatni a tartalmakat egy-egy kampánnyal. Így gyorsan és hatékonyan lehet eljuttatni az üzenetet a célközönségnek.

**Social media**: a különböző social csatornákon gyorsan el lehet juttatni a tartalmakat és üzeneteket a célközönséghez. A közösségeket azonban nemcsak építeni, de gondozni is kell ahhoz, hogy a tartalom hatékonyan eljusson a címzettekhez. A különféle csatornákon különböző célcsoportokat lehet megszólítani. A Facebook jelenleg a legnépszerűbb, ezért itt sok embert lehet elérni, Twitteren ha bejut a kemény maghoz a tartalom, gyorsan szét tudják teríteni. Google+-on elsősorban a keresőoptimalizálás miatt fontos, de ott is egyre aktívabb a közönség. Linkedinen a szakmai közönséghez lehet a tartalmakat eljuttatni.

**Email kampányok**: ha van már néhány tucat email címed, máris el lehet kezdeni a hírlevélküldést. Érdemes előre átgondolni a koncepciót, hogy mikor, kinek, milyen tartalmakat szeretnél kínálni. Ha tudod szegmentálni az adatbázisod, akkor dinamikus tartalmakkal minden szegmensnek egyedi, személyre szabott tartalmakat tudsz kínálni. (egyébként, ha vannak már email címeid, azok már leadek, akiket gondoznod kell)

**Online PR:** az online PR kiváló lehetőséget biztosít a brand, illetve az általunk fontosnak tartott tartalmak természetes közegben való megjelenésére. Másrészt az úgynevezett implied linkek jótékonyan hozzájárulnak a keresőoptimalizáláshoz.

**Guest blogging**: A guest blogging vagy vendégblogolás azt jelenti, hogy egy-egy blogger egy másik bloghoz ír vendégposztot. Miért jó ez neki? Mert visszahivatkozik az eredeti blogra, így egy linkkapcsolat jön létre, amely ha megfelelő minőségű, azaz tartalmilag releváns egymáshoz, akkor segíti a keresőoptimalizálást. Másrészt ha egy kevésbé nagy látogatottságú blog írója posztol egy népszerű blogba, népszerűséget és forgalmat is tud generálni a saját tartalmaira.

![Hogyan gyűjtsünk leadeket? felirat](https://blog.fps.hu/content/images/2015/12/141007_hogyan_gyujtsunk.jpg)

### Ha már van sok látogatód, hogyan gyűjts leadeket?

Felhasználókat a fenti eszközökkel viszonylag könnyen tudsz a tartalmaidhoz terelni. Ahhoz viszont, hogy leadeket gyűjthess, szükséges valami plusz, valami csali, amivel adatokat tudsz szerezni róluk.

Lead lehet email cím, telefonszám, postai cím, amelyeken keresztül fel tudod venni a közvetlen kapcsolatot az egyes emberekkel. Ezeken az alapadatokon kívül számtalan információra lehet szükséged ahhoz, hogy pontosan tudj célozni az egyes csoportokra és szegmentálni tudj.

A lead gyűjtés mindig valamilyen formon keresztül történik. Ez lehet egy hírlevél feliratkozás form, egy regisztrációs form, vagy bármilyen űrlap, amelyen keresztül elkéred a fenti információkat. Az emberek maguktól nem fogják ezeket az adataikat kiadni. Egy hírlevélre való feliratkozást vonzóvá tehetsz azzal, hogy valami pluszt nyújtasz: exkluzív tartalmat, kedvezményt, stb. Regisztrációért cserébe kínálhatsz még speciális eszközöket, pl. valamilyen kalkulátort, egyéb alkalmazásokat, ingyenesen letölthető tartalmakat.

Arra figyelj oda, hogy mikor mennyi információt kérsz el a látogatóktól. Ha egyszerre túl sok adatok akarsz elkérni, hamarabb otthagyhatják az űrlapot. Át kell gondolni, melyek a legszükségesebb információk, ezeket kell első körben elkérni. Ha sikerül bizalmat kiépíteni az egyes látogatókkal, könnyebben lehet tőlük a későbbiekben még plusz információkat begyűjtened.

Ezekkel az úgynevezett csalikkal hatékonyan lehet leadeket gyűjteni. És ha már vannak leadjeid, ne felejtsd el gondozni is őket. De ez már egy másik szakasza az inbound marketingnek.
### Simple and Usable
URL: https://blog.fps.hu/simple-and-usable-konyvajanlo/
Last updated: 2026-07-17T08:40:15.000Z
„Öreg vagyok én már ehhez…” – hangzik el az ismerős mondat. Én számos alkalommal hallottam már ezt a szösszenetet szüleimtől, nagyszüleimtől, amikor egy új technikai dologgal kellett „megküzdeniük”. Mondjuk mikor először vették kezükbe a televízió vagy DVD lejátszó távirányítóját. De még nekem is sokszor gondot okoznak az efféle eszközök, pedig nem mondhatnám, hogy huszonévesen le lennék maradva. Ugyanígy van ez a mobil és webes alkalmazásokkal kapcsolatban is. Ott van például az online adózás, vagy az online vásárlás és még sorolhatnám, ahol sokszor indokolatlanul bonyolultak az egyes folyamatok, hiszen egy kis tervezéssel áthidalhatóak lennének ezek az intermezzók és nem okoznának megannyi fejtörést.

[Kolboid](https://kolboid.eu/?ref=blog.fps.hu "kolboid web page") kollégámnak köszönhetően akadt kezembe [Giles Colborne Simple and Usable](http://www.simpleandusable.com/?ref=blog.fps.hu "Giles Colborne – Simple and Usable book") című könyve, mely lépésről lépésre mutatja be, miként lehet az amúgy túlkomplikált dolgokat leegyszerűsíteni és illeszthetővé tenni a hétköznapi emberek életébe.

### Kezdd el!

Az első teendőd legyen az, hogy saját magad számára pontosan meghatározod, mi a célja annak a valaminek, amit el akarsz készíteni. Erre azért van szükséged, hogy sose térj le az utadról, és mindig a lényegre koncentrálva sallangmentesen csak a legfontosabb elemeket építsd bele a termékedbe. Ha egy kisebb dolog elkészítése a célod, mondjuk egyetlen egy oldal egy nagyobb website-on belül, akkor ennyi elegendő is lehet a folytatáshoz. Ha viszont egy monumentálisabb cél lebeg a szemed előtt, akkor már szükséges, hogy bevond a megfelelő célközönséget, azokat, akik majd ténylegesen használni fogják a terméked.

### Már megint a felhasználók

Azon túl, hogy megvan a célközönséged, érdemes őket 3 csoportra osztanod és az igényeiket is 3 féle fontossági sorrendben kezelned.

#### Általános felhasználók *(mainstreamers)*

Ez legyen az első számú csoport, akikre alapozol. Ők azok a tipikus *„Csak azért használom a telefonom, hogy végezhessem a munkám”* emberkék. Nekik nincsenek feltétlenül olyan előismereteik az adott szegmenssel kapcsolatban, mint mondjuk egy szakértő felhasználónak, így ha ezek az emberek gond nélkül el tudnak lavírozni az alkalmazásodban, akkor bárki.

#### Alkalmazkodó felhasználók *(willing adopters)*

A második, közepesen fontos csoport az „alkalmazkodóké”. Ide tartoznak azok az emberek, akik valószínű, hogy már használtak a tiédhez hasonló terméket vagy szolgáltatást, így hajlamosak alkalmazkodni egy hasonszőrű dologhoz.

#### Szakértő felhasználók *(experts)*

A harmadik és most a legkevésbé fontos csoport pedig a „szakértők” csoportja. Ők tipikusan azon emberek közé tartoznak, akiknek nem okoz különösebb fejtörést, ha új dolgokat kell használatba venniük, sőt még szeretik is felfedezni azt.

Miután már pontosan tisztában vagy azzal, hogy kik is lesznek a felhasználóid, ki kell menned terepre és megfigyelni őket a természetes közegükben, majd fel kell tenned magadnak a következő kérdést: **Mit csinál a felhasználó?** Ezzel a kérdéssel olyan dolgokra derülhet fény, melyek kihagyásával nagyban csökkenhet a terméked által nyújtott felhasználói élmény. Mondjuk vegyük példának a videókamerákat. Ugye arra gondol mindenki, hogy az emberek videókat akarnak rögzíteni vele, így erre hegyezik ki őket. Aha, csak az már ki szokott maradni, hogy azon túl hogy ez megtörténik, meg is akarják osztani az eredményt.

[![TV távirányító változatai](https://blog.fps.hu/content/images/2015/12/140930_krisz_belso.jpg)](http://assets.uxbooth.com/uploads/2010/12/4strategies.jpg?ref=blog.fps.hu "Eredeti kép")

### Rendszerezz!

Valószínű, hogy mire eljutsz erre a pontra, már van egy szép kis feature listád számos ponttal. Ahhoz, hogy a terméked ne valami labirintus legyen, először is priorizálnod kell az egyes elemeket, azaz előre venni a legfontosabbakat, még hátrébb a kevésbé fontosakat. Ezután ki kell alakítanod, hogy mely funkciókat fogod kiemelni és melyeket fogod hátrébb helyezni, illetve elrejteni, netán törölni a listádról. Ebben a feladatban 4 módszer segíthet neked a megvalósításban. A módszerek bevetésekor, a korábban kitűzött céljaid és a felhasználóid dolgai mindig legyenek szem előtt.

#### Eltávolítás *(ezekre nincs szükség)*

Azokat a funkciókat, melyek fölöslegesek egyszerűen csak távolítsd el, hogy ne foglaljanak okvetlenül helyet és ezzel együtt ne tegyék átláthatatlanná, bonyolulttá a felületet. A döntés sosem egyszerű, így óvatosnak kell lenned. Ha bizonytalan vagy, tedd fel magadnak az alábbi kérdést: **Miért kellene megtartani?**

#### Átrendezés *(ezekre szükség van)*

A módszer lényege, hogy a logikailag összetartozó funkciókat csoportokba rendezd, az így kialakult halmazokat pedig a felületen is jól elkülöníthető modulokká csoportosíthatod. Ezzel sokkal átláthatóbbá teheted a felületet, hiszen ha az összetartozó dolgok egymás mellett vannak, akkor a felhasználóknak nem kell össze-vissza keresgélniük azokat. Az, hogy milyen csoportokat hozz létre, és hogy azokba milyen elemek kerüljenek, nagyrészt a felhasználók viselkedésén múlik, azaz **Mit szeretne csinálni?**, és **Milyen sorrendben?** Érdemes továbbá odafigyelned, hogy egy csoportban összesen 4±1 elem kapjon helyet, ugyanis az ember rövidtávú memóriája ennyi elemet képes elraktározni egyszerre.

#### Elrejtés *(ezekre szükség lehet)*

A lényeg abban rejlik, hogy elrejted azokat a funkciókat, melyek elvonják az általános (mainstream) felhasználók figyelmét. Arra azonban figyelned kell, hogy az elrejtésnek ne az legyen az eredménye, hogy soha senki nem fogja megtalálni ezeket a funkciókat!

#### Áthelyezés *(hogy mi?)*

Ez a módszer a kakukktojás. Arról van itt szó, hogy például egy DVD lejátszó távirányítóján nem tudod közvetlen beállítani, hogy mely időpontban szeretnéd, hogy elinduljon a rögzítése egy adott TV csatornának, viszont egy gombnyomásra behozhatod a televízión megjelenő menüjét, ahol már gond nélkül megteheted azt. Ennek a módszernek a használata előtt érdemes megnézned, hogy milyen eszközöket, mikor és miért használ a felhasználó. Összeírni az adott eszközök tulajdonságait, funkcióit, majd ezek után lehet biztonságban tervezni vele.

### Végszó

Természetesen a „De biztos, hogy jó?” szabály itt is érvényes, így amikor csak lehet, tesztelj a valós felhasználókkal és szerezz be tőlük minél több visszajelzést, hiszen sose feledd, értük dolgozol!
### Csináld magad SEO
URL: https://blog.fps.hu/csinald-magad-seo-diy/
Last updated: 2026-07-17T08:40:26.000Z
Induló vállalkozásod van, vagy más okból kifolyólag elég szűkösek az anyagi lehetőségeid ahhoz, hogy a weboldaladdal kapcsolatos feladatokat, például a keresőoptimalizálást szakemberre bízd? Ha konyhanyelven „beszélsz” HTML-ül, van egy kis technikai érzéked, akár magad is megpróbálkozhatsz vele.

Számtalan ingyenesen is elérhető nyílt forráskódú CMS keretrendszer van, amelyet használhatsz weboldalad elkészítéséhez. Az egyik legnépszerűbb ilyen rendszer a WordPress, amelyhez kapcsolódóan összegyűjtöttem egy csokorra való hasznos plugint és információt, melyekkel könnyedén el lehet végezni a szükséges keresőoptimalizálási feladatokat.

### Tippek és tanácsok

- válassz olyan Wordpress sablont az oldalad megjelenéséhez, amilyen leginkább passzol az üzleti tevékenységednek
- telepíts olyan [SEO plugint](https://wordpress.org/plugins/search.php?q=seo+&ref=blog.fps.hu "Wordpress SEO pluginok"), melynek segítségével minden oldalhoz egyedi title és description mezőket tudsz megadni (pl. all-in-one seo plugin)
- telepíts [sebességoptimalizáló](https://wordpress.org/plugins/search.php?q=traffic+optimization&sort=&ref=blog.fps.hu "Sebességoptimalizáló pluginok") és [cache](https://wordpress.org/plugins/search.php?q=cache&sort=&ref=blog.fps.hu "Cache pluginok") pluginokat: ezek az oldal betöltődési sebessége miatt fontosak, mert ugye az is egy rangsorolási SEO faktor
- telepíts [security](https://wordpress.org/plugins/search.php?q=security&sort=&ref=blog.fps.hu "Biztonsági pluginek") plugint: mivel a Wordpress nyílt forráskódú és ismert rendszer, sokan támadják a biztonsági réseket, ezért mindenképp védekezni kell. A security plugin segítségével bezárhatod ezeket a „kiskapukat”
- telepíts [social media](https://wordpress.org/plugins/search.php?q=social+media+share&sort=&ref=blog.fps.hu "Social media megosztó plugin") megosztó plugint: hasznos, ha az egyes tartalmakat könnyen és gyorsan, akár egy-két kattintással is meg tudják a látogatók osztani
- készíts minőségi, a felhasználóidnak értékes tartalmat: erről korábban írtam már [egy posztot](https://blog.fps.hu/minosegi-tartalom-google-szeressen/ "Minőségi tartalom"), abban találsz hasznos információkat
- a szükséges oldalakat/kategóriákat tiltsd ki a robots.txt-ből: itt általában az admin oldalakat szokás kitiltani, de előfordulhat, hogy van az oldaladnak olyan része, amelyet nem szeretnél, hogy lássa a Google, pl. máshonnan átvett tartalmak vannak, keresők számára lényegtelen információk vannak, stb.
- kategória listaoldalak esetében állítsd be a tartalmakat úgy, hogy a listaoldalon ne látszódjon a teljes szöveg, csak egy rövid kivonat, majd a tovább/bővebben/stb. linkre kattintva érik el a teljes szöveget
- állítsd be, hogy a posztok nevei URL-ként is megjelenjenek: ez posztok, cikkek esetében automatikusan generálódik, az egyéb oldaltípusoknál van ennek jelentősége
- telepíts [URL átirányításhoz](https://wordpress.org/plugins/search.php?q=url+redirect&sort=&ref=blog.fps.hu "URL átirányításhoz pluginek") plugint: egyszerűbb az admin felületen kezelni az URL átirányításokat, mint kézzel egyesével írogatni a htacces fájlba az áritányítandó linkeket
- minden posztnál használj megfelelő képe(ke)t a megfelelő alt szöveggel: egy jól megválasztott kép vagy illusztráció vonzóbbá teheti a tartalmat
- telepíts [analitikai plugint](https://wordpress.org/plugins/search.php?q=analytics+&sort=&ref=blog.fps.hu "Analitikai pluginek") és töltsd fel az analitikai kódot: ma már alapvető, hogy mérd az oldalad látogatottságát. Én a Google Analytics-et ajánlom, de vannak más mérési lehetőségek is (pl. gemius, etracker, stb.)
- a Google Analytics kóddal ellenőrizd le a Google Webmaster fiókot: ha Universal kódot használsz, egy kattintással validáltatni lehet a Webmaster fiókot. Ha nem működne ez a mód, jónéhány lehetőség közül lehet választani
- telepíts sitemap XML plugint, majd add hozzá a sitemapet a Google Webmestereszközökhöz: ezzel fel lehet gyorsítani a Google indexelési folyamatát, ráadásul SEO szempontból is fontos egy jó sitemap
- regisztrálj a legnépszerűbb közösségi média oldalakra és hozz létre külön céges oldalt: ezekkel az oldalakkal közösséget építhetsz magad köré, akikből potenciális ügyfeleket is csinálhatsz
- minden social csatornádat használd rendszeresen, különben olyan, mintha nem is lenne. SEO szempontból is fontos, hogy rendszeres időközönként posztolj
- regisztráld be a weboldalad különböző tematikus linkgyűjtő oldalakra: az oldalra mutató linkek nagyon fontosak, arra figyelj, hogy csak tartalmilag releváns oldalakra regisztrálj, és ne egyszerre mindenhova, nehogy a hirtelen megnövekvő linkek miatt megbüntessen a kereső
- készíts minőségi tartalmakat, hasznos infografikákat és oszd meg a különböző social csatornákon

Remélem, sikerül a fentiekből minél több lehetőséget felhasználnod. Egyet ne felejts: bármilyen tevékenységet is végzel, folyamatosan kövesd nyomon analitikával hogy lásd, mi működik és mi nem, így időben be tudsz avatkozni, ha szükséges.
### A pálya füve magasabb volt a szokásosnál
URL: https://blog.fps.hu/brainstorming-meeting/
Last updated: 2026-07-17T08:40:38.000Z
Megvan a brief! Gyerünk, rántsunk össze gyorsan egy pettinget (aka meeting), üljön be a csapat és mehet az ötletelés ezerrel. Időpont ok, már bent is vagyunk öten–hatan a tárgyalóban. Még moderátor is van, aki nyomban belevág a sztoriba, ismerteti az alapinfókat, mindenki figyel, van aki még jegyzetel is. Minden frankó, végre indulhat a problémamegoldás. Nyomban aktivizálódik egy, vagy két arc és mondja az ötletét. Szépen haladunk, két ember tolja, fejleszti az elképzelést, a többiek figyelnek, időnként elhangzik a kérdés: – Egyetértetek? Mindenki bólogat.

Elérkezik az első mélypont, megáll a nagy lendület, csend honol, majd újra fellángol a páros egyik tagja, továbbfonja a szálat és így tovább. Közben elhangzik párszor a „Mit gondoltok?” kérdés is, „Szerintem jó lesz” reakciókkal. Végül nagy nehezen, de megszületik a koncepció, ami egyébként tök jó, mindenkinek tetszik. Vége. Mehetünk a dolgunkra.

**Csapatban dolgozni jó**, csapatot vezetni szintén. A fenti történet jellemző a munkánkra, de valahogy mindig az volt az érzésem, hogy beragadnak ötletek, lehetne sokkal jobb a végeredmény. Valami módon rá kell venni a többieket is, hogy aktivzálódjanak, dobják be a közösbe, ami bennük van. Aztán megértettem.

### Brainstorming

Az a helyzet, hogy egy kis csoport (mint esetünkben) együtt dolgozva körülbelül fele annyi megoldást tud adni egy nehéz problémára, mintha egyénenként dolgoznának.

#### Miért?

Vannak más okok is, amiért nem osztjuk meg a gondolatainkat:

- sokan szégyenlősek, félénkek, bátortalanok vagyunk
- esetleg félünk attól, hogy a többiek azt gondolják rólunk, nem értünk hozzá
- vagy csak egyszerűen kerülni akarjuk a konfliktust
- engedünk a csoport nyomásának

#### Mi mind egyéniségek vagyunk

Én nem. :)  
Az ember egy csoporton belül folyamatosan alkalmazkodik a többiekhez. Miért? Mert igazából nem akar különbözni, mert fél a közösség kitaszításától, mert biztonságban akarja érezni magát. A csoport tagjai tudattalanul minimalizálni akarják a konfliktust, gyors konszenzusra törökednek úgy, hogy közben inkább figyelmen kívül hagynak alternatív nézőpontokat. Csekkold ezt a vicces videót a konformitásról. Igen, birkák vagyunk.

#### Mi akkor a megoldás?

Egyszerű. Ismertesd a briefet. Utána mindenki dolgozzon egyénileg a saját megoldásán. Majd dominancia szerinti sorrendben mutassák be egyenként az ötletet, arra senki, semmilyen formában (se szóban, se metakommunikációval) ne reagáljon (csak jegyzeteljen magának), a végén pedig vitassák meg az eredményt.

#### Dominancia szerinti sorrendben

Igen. A domináns egyéniség, vagy az egyén szervezeten belüli helyzete mind nyomást gyakorol a többiekre. Érdemes ezért olyan sorrendben haladni, ahol a legcsendesebb, legkisebb dominanciával megáldott (jellemzően introvertált) egyén kezdi a sort.

Tapasztalatból mondom, több ízben kipróbáltuk és mondhatom nagyszerű ötletek kerülnek elő, amelyek eddig sosem, mindenki sokkal élvezetesebbnek találja a pettingeket (még mindig meeting) és többet tanulunk egymástól, mint valaha.

Köszönöm a zseniális [Szociálpszichológia coursera kurzusnak](http://blog.kolboid.eu/szocialpszichologia-coursera-kurzus/?ref=blog.fps.hu "Szociálpszichológia kurzusról poszt"), ahol ezeket az ismereteket találtam.
### Szeretnéd, hogy szeressen a Google?
URL: https://blog.fps.hu/minosegi-tartalom-google-szeressen/
Last updated: 2026-07-17T08:40:49.000Z
Minőségi tartalom. Gondolom, sokszor hallottad már ezt a kifejezést, én is gyakran használom. Tudod-e, hogy mitől lesz egy tartalom minőségi tartalom? Hogyan kell olyan tartalmakat előállítani, amelyet a felhasználóid olvasni és használni is fognak, nem mellesleg a Google is szeretni fogja?

Minőségi tartalmat készíteni a keresőoptimalizálás egyik sarokköve. Ha a weboldalad ezen része rendben van, akkor szilárd alapokra építkezhetsz tovább. A jó tartalom csak egy dolog a több száz rangsorolási faktor közül, önmagában még nem fogja a keresési találat élére repíteni a weboldalad.

### Mit jelent a Google számára a minőségi tartalom?

A legutóbbi Google algoritmus frissítés kapcsán jelezték, hogy a gyenge relevanciájú tartalmak egyértelműen hátrányba kerülnek a jó minőségű tartalmakkal szemben. Nincs ebben semmi meglepő, évek óta arra törekednek a keresőmotorok, hogy a lehető legjobb és legrelevánsabb tartalmakat kínálják a felhasználóiknak.

### Hogyan készíts minőségi tartalmat?

Több posztomban is érintettem már a minőségi tartalom ismérveit, most összegyűjtöttem egybe, milyen szempontokat érdemes figyelembe venni ahhoz, hogy megfelelő tartalmakat tudj készíteni.

![szakállas ember](https://blog.fps.hu/content/images/2015/12/1-5.jpg)

**Embereknek írj, ne a keresőrobotoknak!** – nem győzöm elégszer hangsúlyozni, hogy egy weboldalnak a felhasználókból lesz bevétele, nem a keresőrobotokból. Persze fontos, hogy a keresőben megtalálható legyen a weboldalad, de a tartalmaidat a felhasználóid fogják használni, így elsődlegesen őket kell kiszolgálnod.

**Kösd le a felhasználóid** – figyelj arra, hogy a megjelenés kellemes legyen, a szöveg olvasmányos, így növelheted a felhasználói élményt. Adj lehetőséget a felhasználóknak az interakciókra: vagy kommentelési lehetőséggel, vagy social media megosztással, vagy bármilyen más módon, a lényeg: érezze, hogy mindez neki szól.

**Légy egyedi** – ne másold a konkurenciát. Készíts olyan dolgokat, amelyek a célközönségedet érdeklik, ettől lesz számukra egyedi és értékes az oldalad.

![izzó](https://blog.fps.hu/content/images/2015/12/2-1.jpg)

**A minőség az első** – ha kiszervezed a tartalomkészítést, mert olcsóbb, általában a minőség rovására megy, mivel egy külső személy más perspektívából látja a dolgokat, mint te, aki benne él. Vagy olyan tartalomkészítőt válassz, aki szintén benne él az adott szakterületben – akár egy szakértőt is felkérhetsz – vagy szakíts rá időt, és magad készítsd ezeket a tartalmakat, vagy lektorálsz minden tartalmat, mielőtt felkerül a világhálóra. A minőségi tartalomba való befektetés hosszú távon kifizetődik.

**A tartalmak legyenek hozzáférhetőek** – törekedj arra, hogy a felhasználók minden tartalomhoz könnyen hozzáférjenek, ne nehezítsd a dolgukat azzal, hogy négy-öt menüpontba is be kell menniük ahhoz, hogy megtalálják azt, amit keresnek. Ha exkluzív tartalmat nyújtasz pl. egy regisztrációért cserébe, ez is a lehető legegyszerűbben legyen elérhető a látogatók számára.

**Használj megfelelő kulcsszavakat** – olyan kulcsszavakat használj, amit a felhasználóid használnak. Ha olyan kulcsszavakat erőltetsz, amelyet sose írnak be a keresőkbe, nem is fognak megtalálni rá. Lehet, hogy ezekre a szavakra nagy lesz a verseny, de ha jó a tartalmad és figyelsz a keresőoptimalizálásra, a felhasználóid meg fognak találni a keresőkön keresztül is.

![Figyelj a részletekre! felirat](https://blog.fps.hu/content/images/2015/12/3-1.jpg)

**Figyelj a részletekre** – amikor tartalomról beszélünk, sokan csak a szöveges tartalmakra gondolnak. Ez nagy hiba. Ugyanis a szöveg, az képek, videók, és maga az oldal megjelenése együttesen alkotják a tartalmat. Hiába van jó szöveged, ha citromsárga háttéren fehér betűkkel van írva, vagy bonyolult, áttekinthetetlen az oldalstruktúra, stb. Ezekre mind figyelj oda, mert az oldal bármelyik részével probléma van, kihat az összes többire.

### Tehát

Ha egyetlen mondatban kellene összefoglalnom, hogyan készíts minőségi tartalmat, kb. így hangozna: Olyan tartalmat készíts, ami a célközönségednek szól, számára érdekes és értékes, egyedi, jól strukturált és áttekinthető, jól kereshető.

Tudom, első olvasásra ez majdhogynem lehetetlen küldetésnek tűnik, de hidd el, nem az. A legfontosabb, hogy jól ismerd a célközönséged, így a minőségi tartalom előállítása már nem fog problémát okozni.
### A web halott, vagy nem
URL: https://blog.fps.hu/web-halott-vagy-nem/
Last updated: 2026-07-17T08:41:01.000Z
Figyelem! Attention! Achtung! Az írás szigorúan magánvélemény és gondolathalmaz a webről és annak jövőjéről. Az író nem jövendőmondó, nem látnok, viszont egy gondolkodó emberi lény a milliárdnyi közül.

Több, mint 5 éve mondják szakmabeliek, hogy az általunk ismert web, mint olyan halott, eltűnik a süllyesztőben. A [WIRED Magazine 2010-ben publikált cikke](http://www.wired.com/2010/08/ff%5Fwebrip/?ref=blog.fps.hu "The Web Is Dead. Long Live the Internet") az elsők között volt, ami erről szólt. Ha még nem olvastad a cikket, akkor ajánlom figyelmedbe, mert tele van nagyszerű, előremutató gondolatokkal. A poszt alatt található nem is olyan régi komment megmosolyogtató:

![Komment a cikk alatt: If it is dead, why your stupid article and web site still here years later.](https://blog.fps.hu/content/images/2015/12/tumblr_inline_na3w12GchA1r105v8.jpg)

### Mégis mi várható?

Szükséges még egyáltalán web site-ot, portált építeni, újraépíteni? Mi lesz azokkal az ügynökségekkel, cégekkel, akik webre fejlesztenek? Jó kérdések. Jó lenne tudni a válaszokat.

### Technológia

#### Desktop, notebook vs. mobil, tablet

Ott tartunk, hogy az okostelefonok, tabletek felforgatták, felforgatják a világot. Nyomban mindenki az asztali számítógépek, laptopok haláláról kezdett el beszélni. Igen, a mobilok, tabletek hihetetlen ütemben terjednek és meg is előzik a az előbbi csoport eladásait. Viszont szerintem ez nem jelenti a halálukat, legalábbis a mostani technológia nem képes kiváltani az asztali gépeket, sokkal inkább kiegészíti azokat. A mobilokat, tableteket rengeteg mindenre lehet használni, ami indokolja a növekedést, viszont sokkal inkább szórakozásra, információ keresésre, kapcsolattartásra alkalmas, semmint munkára (kevés kivételtől eltekintve). Abban a pillanatban, amikor tartalmat kell előállítani – képek, fotók manipulálása, audió anyagok kezelése, videók vágása, animációk létrehozása, szöveges anyagok megírása, komplex rendszerek kezelése, programozás, és még sorolhatnám, a relatív kicsi képernyő, a billentyűzet és egyéb vezérlő eszközök hiánya komoly hátrányt és nehézséget jelent. Gyakorlatilag lehetetlenné teszi a hatékony munkát. Minden alkalommal, amikor utazom és „csak” mobil eszközöm van (nem laptop), akkor fellélegzem mikor végre beülhetek a gépem elé. Azt gondolom, hogy a mai formájukban minden eszköz másra és másra való.

[![Worldwide Smart Connected Device Shipments, 2010-2016 diagram](https://blog.fps.hu/content/images/2015/12/idc-smartphone-tablet-predictions.jpg)](http://aydigital.tumblr.com/post/85623317421/the-seamless-digital-experience-coming-soon-to-a-site?ref=blog.fps.hu "The Seamless Digital Experience Coming Soon to a Site Near You!")

Világszinten tendencia, hogy a PC eladások csökkennek, a mobil és tablet eladások órási ütemben nőnek. Ez is érhető, egyáltalán nem meglepő. Az emberek nagy része az otthoni számítógépét korábban is szórakozásra, kapcsolattartásra használta. Érdekes azonban a [Gartner 2014\. júniusi elemzése](http://www.gartner.com/newsroom/id/2791017?ref=blog.fps.hu "Gartner Says Worldwide Traditional PC, Tablet, Ultramobile and Mobile Phone Shipments to Grow 4.2 Percent in 2014"), ami 2015-re a PC eladások kicsi növekedését jósolják, nem további csökkenést.

#### Mobil web vs. mobil app

Másik klasszikus vita most már évek óta, hogy mobilra (is) optimalizált web site-ot, vagy natív alkalmazásokat javasolt fejleszteni. Mindenhonnan jönnek az adatok, melyek főleg a mobil appok térnyeréséről szólnak szemben a mobil web használattal. Azért itt mindig figyelembe kell venni az in-app browsing kérdéskörét is, melyet rendszeresen elfelejtenek. A Facebook, twitter, LinkedIn appokban töltött idő folyamatosan növekszik, viszont a közösségi csatornákon rengeteg cikket, web oldalt osztanak meg, melyeket appon belül, de mobil webről néznek meg a felhasználók (web view). 2 évvel ezelőtt kifejtettem [miért is kell a mobil web, olvasd el](https://blog.fps.hu/mobil-web-strategia-responsive-ress/ "Mobil web stratégia").

[![comScore ábra böngésző vs. app, már 50%-ban appokban töltik az időt az USA-ban](https://blog.fps.hu/content/images/2015/12/tumblr_inline_na3x3fkmme1r105v8.jpg)](https://twitter.com/IanMaude/statuses/476701935450730496?ref=blog.fps.hu "Apps now 50% of internet usage in US according to comScore– includes in-app browsing, so actual time spent lower")

A „kérdésben” az a véleményem, hogy mindkét megoldásnak megvan a jól megérdemelt helye. Luke Wroblewski posztolt twitteren erről egy príma ábrát: A mobil web nagyobb elérést hoz, míg a natív app nagyobb elkötelezettséget.

[![Két diagram. Egyik az egyedi akciókat, másik pedig az egyedi felhasználókat mutatja.](https://blog.fps.hu/content/images/2015/12/BroREDhCcAEDuvC--1-.jpg)](https://twitter.com/lukew/statuses/484718671927857152?ref=blog.fps.hu "Web wins for reach. Native wins for engagement. Each is great for something different.")

Szeretem a natív appokat és használom is azokat. Méretes hype-nak érzem azonban, hogy mindenre appfejlesztés legyen a válasz. Azt gondolom, hogy ez le fog csengeni. Van egy kicsit sánta hasonlatom a natív vs. web kérdésre. Analógiát mutat nekem a régi világgal, amikor a web már elterjedt: desktop program vagy webes fejlesztés? A Photoshop nyilván desktop software-ként a leghatékonyabb és nehezen valósítható meg, alkalmazható webes alkalmazásként. Nem gondolom, hogy minden webshophoz kellene külön natív appot fejleszteni. Persze lehet és valamikor még kifizetődő is, viszont részemről akkor is a multi-device híve vagyok. Az egyes eszközökre fejlesztett megoldások mindamellett, hogy konzekvensek, kiegészítik egymást és az adott eszközhöz és a felhasználók kontextusához alkalmazkodnak. Vagyis egy „ökoszisztémára” gondolok, ami teljes felhasználói élményt nyújt eszközöktől függetlenül. Ergo nem választás kérdése a mobil web, hanem szükséges.

#### Mobil, tablet

Mobil, mobil és mobil. Ha a munkahelyed a második otthonod, akkor a mobilod lett a harmadik. A tendencia folytatódik. Viszont óvatosan kell bánni a tablet kérdéssel. Sok cikk született már arról, hogy [a megfelelő képernyőméret kialakulóban van](https://medium.com/@somospostpc/a-comprehensive-look-at-smartphone-screen-size-statistics-and-trends-e61d77001ebe?ref=blog.fps.hu "A comprehensive look at smartphone screen size statistics and trends"). A mobilok méretei nőnek, a tabletek méretei pedig csökkennek. Úgy tűnik, hogy valahol egy köztes méret lesz a győztes. Érdekes [az USA-ban végzett kutatás](http://dcurt.is/the-death-of-the-tablet?ref=blog.fps.hu "Replacing the PC"), ami jól mutatja, hogy minél fialatabb korosztályról beszélünk, annál kisebb a tablet használat. Ugyanígy minél fiatalabbakról van szó, annál magasabb az okostelefon használat. 14-22 évesek 55%-a már most csak mobilt használnak internetelérésre. Persze ők még nem dolgoznak, tehát a desktop, notebook hamarosan képbe jön náluk, de a tablet számukra nem érdekes eszköz.

### Jövő

#### A nyelv és a hang

![A Her (http://rendelkező operációs rendszert](https://blog.fps.hu/content/images/2015/12/aher2.jpg)

Láttad [a Her (A nő) című filmet](http://www.imdb.com/title/tt1798709/?ref=blog.fps.hu "Her az IMDb-n")? Felettébb hitelesen mutatja be mire is lehet számítani. Abszolút elképzelhető, hogy egy mesterséges intelligenciával megáldott operációs rendszerrel beszélgetünk, aki (vagy ami?) mintegy személyi titkárunk, segíti az életünk. Ha belegondolsz nem is állunk messze ettől. Gondolj csak Apple Sirire, Microsoft Cortanara, vagy a Google Voice-ra és persze a Skype realtime fordító megoldására. Meglátjuk. Mindenesetre szerintem a kulcs maga az emberi nyelv.

#### Szemantikus web (web 3.0?)

Sokan hisznek benne, sokan utópiának tartják. Ha nem vagy képben, akkor nézd meg Tim Berners-Lee TED-es előadását, megéri. Ő hisz benne.

#### Cikkek, infografikák a web jövőjéről még

- [The sad future of the Web](http://thesadfutureoftheweb.com/?ref=blog.fps.hu "The sad future of the Web")
- [Web 2024 - waiting for Singularity](http://berjon.com/web-2024/?ref=blog.fps.hu "Web 2024 Waiting for the singularity")
- [The Future of the Web and Technology (infographic)](http://www.pinterest.com/pin/119838040059448840/?ref=blog.fps.hu "The Future of the Web and Technology (infographic)")
- [Is Web 3.0 the Next Web Revolution?](http://www.1stwebdesigner.com/design/next-web-revolution/?ref=blog.fps.hu "Is Web 3.0 the Next Web Revolution?")
- [Why Does Everyone Keep Saying The Web is Dead?](http://techland.time.com/2011/04/26/why-does-everyone-keep-saying-the-web-is-dead/?ref=blog.fps.hu "Why Does Everyone Keep Saying The Web is Dead?")
- [Internet trends (presentation)](https://vivipins.com/internet-trends/?ref=blog.fps.hu "2014 Internet trends")
- [The Future Of The Web Is Audible](http://www.forbes.com/sites/reuvencohen/2014/03/06/the-future-of-the-web-is-audible/?ref=blog.fps.hu "The Future Of The Web Is Audible")

### Végsősoron

A web a most ismert formájában még évekig velünk marad és kell is vele foglalkozni különösen mobil fókusszal. Egy biztos azonban: A mozdulatlanság végzetes, a fejlődés megállíthatatlan. Jobb, ha nem azon lamentálunk, hogy mikor hal meg a számunkra most ismert web, inkább találjunk ki új megoldásokat, ami az emberek számára hasznot, élményt hoz. A többi lényegtelen. A technológia, a politika, a gazdaság változása úgysem jósolható meg.
### A WordPress és a letöltött plugin esete
URL: https://blog.fps.hu/a-wordpress-es-a-letoltott-plugin-esete/
Last updated: 2026-07-17T08:41:10.000Z
Egy tavalyi statisztika szerint az interneten fellelhető oldalak 19%-a WordPress motort használ. Több százan részt vesznek a fejlesztésében, és 2-3 havonta jönnek ki új verziókkal. Talán méltán nevezhető opensource megoldásnak, és sok esetben az ügyfél ragaszkodik is hozzá. A hivatalos oldalán több, mint [32 ezer plugin](https://wordpress.org/plugins/?ref=blog.fps.hu "WordPress plugins") elérhető hozzá, s ez a szám sokakat arra ösztönöz, hogy könnyelműen elvállaljanak egy munkát minél kevesebb fejlesztést remélve a kész bővítmények használatától. Na, ezen a ponton hibáznak! :)

Természetesen ez a kijelentés így nem teljesen igaz, hiszen vannak olyan esetek, amikor igenis jobban jársz egy plugin alkalmazásával, mintha saját magadnak fejlesztenéd le a funkciót sok-sok munkaóra alatt. Arról nem is beszélve, hogy a kevésbé, vagy programozni egyáltalán nem tudó felhasználóknak ezek nagy segítséget jelentenek. Ők inkább kattintgatnak addig, míg olyan nem lesz a megjelenés és működés, amilyet szeretnének (vagy amilyenre sikerül).

### A buktatók

A problémát az okozza az ilyen esetekben, hogy **úgysem találsz olyan bővítményt, ami pontosan azt csinálja, amit te elképzeltél**. Számos alkalommal rávágtuk projekt tervezésekor, ha kellett egy egyszerű dokumentumtár, hogy nem gond, letöltünk egy már elkészített bővítményt és csak kicsit testre kell szabni a megjelenését. A testreszabás mindig több időt vett igénybe, mint azt gondoltuk. Ha van rá lehetőség, hogy az adminisztrációs felületen beállítsd a megjelenést és a szükséges dolgokat, még nincs nagy gond. Viszont amikor már ahhoz kell folyamodnod, hogy beleírj a plugin kódjába, akkor számolnod kell az esetleges későbbi kellemetlenségekkel.

Az egyik legkomolyabb gond a plugin frissítésekor jelentkezhet, amennyiben belenyúltál a kódjába. A frissítés során ugyanis felülíródnak a fájlok és búcsút inthetsz az általad eszközölt módosításoknak. Persze ha csak a megjelenés a kérdéses, a sablonba írt css felülbírálásokkal kivitelezhető a dolog, de valljuk be, nem túl elegáns megoldás.

A nyilvánosan elérhető bővítményeknek van még egy hátrányuk, mégpedig, hogy növelik az oldalunk támadhatóságát. Rövid forrás-böngészéssel könnyen beazonosíthatóak az oldal által használt bővítmények és percek alatt elérhetjük a forráskódjukat. És egy rosszul megírt plugin bizony komoly kiskapukat adhat a rosszindulatú felhasználóknak. Elég csak a [nemrég történt eseményekre gondolni](http://www.zdnet.com/wordpress-plugin-vulns-affect-over-20-million-downloads-7000031703/?ref=blog.fps.hu "WordPress plugin vulnerabilities affect 20 million downloads"), milyen károkat okozott egy bővítményben hagyott biztonsági rés. Ha nem vagy rest utánajárni, számos bővítmény a sablonba elhelyezett pár sornyi PHP kóddal kiváltható. Legegyszerűbb példa rá a WordPress admin bar problémája. Létezik hozzá egy [letölthető plugin](https://wordpress.org/plugins/toolbar-removal-completely-disable/?ref=blog.fps.hu "Disable Admin Bar and ToolBar WordPress plugin"), ugyanakkor [egy sorral elintézhető](http://davidwalsh.name/hide-admin-bar-wordpress?ref=blog.fps.hu "Hide the Admin Bar in WordPress"), amit a sablon functions.php fájlba kell beillesztened.

![Bővítmények WordPress adminisztrációs felületen screenshot](https://blog.fps.hu/content/images/2016/01/wordpress.jpg)

### Azért ne írjuk le őket…

A fent leírtak természetesen nem azt akarják sugallni, hogy ne használj bővítményeket, és írj meg magadnak mindig mindent. Vannak robusztus pluginek (bbpress, woocommerce, stb.), amiket felesleges lenne újra megírni, vagy annyira kézenfekvő a működésük, hogy ha saját magadnak kódolnád le, ugyanaz jönne ki. Minek megírni a [nyelvesítést megvalósító bővítményt](https://wordpress.org/plugins/qtranslate/?ref=blog.fps.hu "qTranslate WordPress plugin"), ha már megtették előttünk, és jól működik? Abban az esetben sincs sok értelme magadnak kódolni, ha csak például az adminisztrációs felületet akarod [használhatóbbá tenni](https://wordpress.org/plugins/admin-management-xtended/?ref=blog.fps.hu "Admin Management Xtended").

### Konklúzió

A bővítmények jók, nem véletlenül vannak és érdemes őket használni. Viszont, ha fejlesztő vagy és WordPress-re épülő, egyedi és minőségi oldalakat akarsz kiadni a kezeid közül, akkor érdemes jó néhány esetben saját megoldások felé nyitni, és nem kell más kódját bogarásznod, módosítanod, felülírnod. Hiszen mennyivel szebben is néz ki egy admin felület, ahol nem csak a telepített bővítmények kevert nyelvű felületei láthatóak, hanem mindennek szépen meg van a helye.
### A minőség a tartalom esetében is fontos
URL: https://blog.fps.hu/a-minoseg-a-tartalom-eseteben-is-fontos/
Last updated: 2026-07-17T08:41:19.000Z
Napjainkban a keresők már annyira szofisztikáltak, hogy elég nagy biztonsággal meg tudják állapítani egy tartalomról, hogy minőségi vagy spam. (Gondolj csak a Google Panda frissítésekre.) A minőségi tartalomnak vannak kézen fogható ismérvei, amely alapján könnyen beazonosíthatóak, illetve ezen ismérvek alapján előállíthatóak is. Melyek ezek? A továbbiakban erről lesz szó.

Bár a Google keresési algoritmus pontos működését homály fedi, mégis, mint egy iránytű, utat mutat a hatalmas mennyiségű tartalom között. Néhány hete felröppent a hír, miszerint kiszivárgott a Google féltve őrzött titka, a rangsorolási szempontokat tartalmazó dokumentum ([Quality Rating Guideline](http://www.scribd.com/doc/217994742/General-Guidelines-1?ref=blog.fps.hu "Quality Rating Guideline")), amely alapvetően azoknak a munkatársaknak szól, akik manuálisan tesztelik a Google algoritmusok pontosságát. A dokumentum azonban semmilyen titkot nem tartalmaz, viszont nagyon jó áttekintést ad arra, hogyan vizsgálja minőség szempontjából a tartalmakat a kereső.

A Google indulása óta folyamatosan finomítja a keresési algoritmusokat, és mindent elkövet, hogy a lehető legjobb tartalmakat nyújtsa a felhasználóknak. Íme egy pár perces kis összefoglaló a Google keresőjének evolúciójáról:

A Quality Rating Guideline a korábbiakhoz képest egy teljesen új átdolgozás, kikerültek belőle az azóta már nem használatos keresőoptimalizálásra vonatkozó részek is. Ez az 5-ös verzió is még csak néhány hónapja készült, a dokumentumból kiderül, hogy a Google a minőségi tartalom preferálását tűzte ki célul: a weboldalaknál kiemelten fontos a megbízhatóság, a magas szintű szakértelem és tekintély. Nem kell azonban megijedni ezektől a nagy szavaktól, ha a látogatók számára hasznos és tartalmilag releváns tartalmat adsz, a Google is szeretni fogja.

### E-A-T

Az E-A-T az előbb említett szakértelem, tekintély és megbízhatóság (expertise, authoritativeness and trustworthiness) mozaikszava. Ha bármelyik szempont nem megfelelő vagy valamilyen oknál fogva sérül, a Google gyengébb besorolással „díjazza” az adott weboldalt. Tehát a weboldal tulajdonosoknak/szerkesztőknek biztosítani kell a megfelelő minőséget ahhoz, hogy jó pozícióba kerülhessen a site-juk a keresési találati listában. A Google felhívja a figyelmet arra, hogy a felhasználók által generált és szabadon publikálható tartalmak ronthatnak a rangsoroláson, ezért ezekre különösen nagy figyelmet kell fordítani.

![krétával táblára rajzolt izzó](https://blog.fps.hu/content/images/2015/12/140724_mitol_lesz_valaki.png)

### Mitől lesz valaki szakértő?

Bárki lehet szakértő bármilyen területen. Például van egy hobbi kertész, aki rendszeresen publikál tartalmakat egy saját blogon, vagy hobbi kertész oldalakon, fórumokon, stb.. A többi hobbi kertész és egyéb látogatók rendszeresen olvassák a cikkeit, kommentelik, lájkolják, +1-ezik, retweetelik, megosztják a tartalmait. A Google szemszögéből ez mindenképp minőségi tartalomra utal, különben nem aktivizálná a látogatókat. A szerző (főleg ha mindig azonos nevet vagy nicknevet használ, pláne ha használja a Google Authorshipet is) megbízhatóvá és szakértővé válik a kereső számára.

### Sok reklám = gyenge minőség

A régebbi útmutatók nem helyeztek nagy hangsúlyt a reklámokra, csak arra figyeltek, hogy az oldalon lévő reklámok ne legyenek megtévesztők vagy spamek. Ma már a reklámok elhelyezésére és megjelenítésére külön irányelveket készített, hol, milyen formában jelenhet meg, mit lehet és mit nem lehet használni, stb.. Ha sok reklám van az oldalon, amely zavarja a tartalomfogyasztást (villog, mozog, kitakarja a tartalmat, stb.) vagy megtévesztő (pl. úgy néz ki a banner, mintha egy menü lenne vagy valamilyen navigációs pont) a Google gyenge minőségűnek rangsorolhatja az oldalt.

### Frissülő tartalom

Nemcsak a keresők, de a látogató számára is fontos a rendszeresen frissülő, hasznos, informatív tartalom. Milyen gyakran frissüljön? A Google erre nem ad konkrét irányelvet, de utal rá, hogy egy rendszeresen frissülő oldal sokkal vonzóbb a látogatók számára, mint egy statikus oldal. Illetve arra is tesz utalást, hogy jobb hetente egy minőségi tartalom, mint naponta egy gyenge minőségű. Azt hiszem, ezt nem kell tovább ragoznom.

Szintén ehhez a témakörhöz tartozik, hogy a tartalmak mellett jelenjen meg a létrehozás dátuma, ha az adott tartalom többször is módosul, akkor a módosítás dátumát is. Ha vannak elavult, már nem aktuális tartalmak az oldalon, akkor azokat vagy jelöljük meg, hogy elavultak lehetnek, vagy távolítsuk el (figyelve persze a keresőoptimalizálásra).

![Content felirat](https://blog.fps.hu/content/images/2015/12/140724_frissulo_tartalom.png)

### Mennyire releváns a tartalom?

Ez egy elég komplex és elég kényes terület is. Például van egy cipőket forgalmazó webshopom. A cipő kialakulásának története, vagy a világtörténelem híres cipészei nagyon érdekes és izgalmas témák, viszont nem relevánsak a webshophoz, hiába azonos a téma.

Figyelni kell a linkekre is, csak akkor használjunk kifelé mutató linkeket, ha az adott tartalomra nézve releváns tartalomra visz. (lásd előző bekezdés)

Az analitika árulkodó lehet, ha relevancia probléma gyanúja merül fel. Ha ugyanis magas keresési találat mellett alacsony az átkattintási arány, magas a visszafordulás és alacsony az oldalon eltöltött átlagos idő, mind-mind a gyenge minőség jelei lehetnek.

Bár ugyan nem közvetlen rangsorolási faktor, de nagyon fontos, hogy ne legyenek helyesírási vagy nyelvtani hibák az oldalon, ezek leginkább a felhasználói élményt rontják, amelyek viszont már kihatnak a tartalom minőségi besorolására is.

Szintén tartalmi kérdés a duplikáció mellőzése, illetve ha átveszünk részeket más tartalmakból, jelöljük meg a forrást (canonical).

### Összefoglalva röviden

A minőségi tartalom nélkülözhetetlen ahhoz, hogy a Google keresési találati oldalán minél jobb pozícióba kerüljön egy weboldal. Ehhez az alábbiak szükségesek:

- a legfontosabb az E-A-T, azaz szakértelem, tekintély és megbízhatóság
- az oldal céljával, mondanivalójával legyen releváns a tartalom
- készüljön rendszeresen hasznos, informatív, releváns tartalom
- a tartalmak mellett jelenjen meg a létrehozás és/vagy utolsó módosítás dátuma
- a megjelenés, olvashatóság legyen megfelelő
- a reklámok legyenek az előírásoknak megfelelően elhelyezve, és tartsuk be az erre vonatkozó irányelveket is
- a weboldal technikailag is legyen rendben (megfelelő oldalbetöltődési sebesség, legyenek 404-es oldalak, megfelelő átirányítások, stb.)

Hogyan készíts minőségi tartalmat? A következő posztban összegyűjtöm neked az ezzel kapcsolatos tudnivalókat.
### JavaScript debuggolás 2. rész
URL: https://blog.fps.hu/javascript-debuggolas-2-resz/
Last updated: 2026-07-17T08:41:29.000Z
Az [előző részben](https://blog.fps.hu/chrome-devtools-funkciok/ "JavaScript debuggolás 1. rész") egy rövid összegzést kaphattál, milyen típusú hibák fordulhatnak elő JavaScript kód futása esetén. A következőkben pár nagyon hasznos online és böngészőkbe épített eszközt ajánlok, melyek használata jelentősen segíti a tisztább kódolást és a hibakeresést.

### Online eszközök

**[JSLint](http://www.jslint.com/?ref=blog.fps.hu "JSLint oldala")**

A JSLint egy JavaScript online kódelemző, ami elősegíti a minőségi és minél problémamentesebb kód írását. A szintaktikai hibák mellett egyes kódolási konvenciókra és strukturális problémákra is felhívja a figyelmet. Használatával elkerülheted az egyes böngészők interpretere közötti különbségekből adódó kellemetlenségeket. Egyáltalán nem elnéző a kódoddal, viszont csak előnyödre válik, ha hallgatsz rá. [Számos plugin](https://www.google.hu/search?q=jslint+plugin+IDE&ref=blog.fps.hu "JsLint pluginek Google-ben") segítségével remekül integrálható a legtöbb kódszerkesztőbe.

**[JSHint](http://www.jshint.com/?ref=blog.fps.hu "JSHint oldala")**

A JSHint szintén egy nyílt forráskódú kód-minőség ellenőrző software, amit külön konfigurációs fájlokkal irányíthatunk, és sok szerkesztő észreveszi, ha telepítve van, így annak megfelelően ellenőrzi a kódot a fejlesztés során. Ajánlom [ezt a cikket](http://code.androgeek.hu/2013/12/10/jshint-noveljuk-a-kodbazis-minoseget/?ref=blog.fps.hu "JSHint: Növeljük a Kódbázis Minőségét"), ha bővebben szeretnél olvasni a használatáról.

![JSHint példa képernyő](https://blog.fps.hu/content/images/2015/12/tumblr_inline_n7o638Y2jR1r105v8.png)

**[JS Console](http://jsconsole.com/?ref=blog.fps.hu "JS Console oldala")**

A JS Console egy egyszerű JavaScript parancssori konzol. Előnye, hogy könnyedén lehet vele távoli eszközökön futó oldalakat is vizsgálni, ezért roppant hasznos webalkalmazások ellenőrzésére. Érdemes megnézned a működését [bemutató videókat](http://jsconsole.com/?ref=blog.fps.hu "JS Console bemutató videók"), sok esetben hasznos eszköz lehet.

**[JSONLint](http://jsonlint.com/?ref=blog.fps.hu "JSONLint oldala")**

Online JSON validátor. Talán többet nem is nagyon szükséges róla írni. Noha a legtöbb IDE már rendelkezik ezzel a funkcióval, sok esetben jól jöhet, ha átláthatóbbá akarsz tenni egy nagyobb JSON adathalmazt.

**[JS Bin](http://jsbin.com/?ref=blog.fps.hu "JS Bin oldala")**

A JS Bin remek oldal, ha meg szeretnéd osztani a HTML/JS/CSS kódodat másokkal problémamegoldás vagy bármilyen egyéb okból. Nem kell a saját tárhellyel bajlódnod, ha szeretnéd prezentálni a kódot másoknak vagy csak éppen kipróbálni valamit.

**[CodePen](http://codepen.io/?ref=blog.fps.hu "CodePen közösségi szerkesztő")**

A CodePen frontend fejlesztők játszótere. Ugyanazt a funkciót látja el, mint a JS Bin, csak itt a feltöltött kódok böngészhetőek és akár saját listákba rendezhetők. Az egyik személyes kedvencem, naponta böngészem és ha valamilyen egyszerű megoldásra van szükségem, ott keresek először. Rengeteg érdekes és ötletes megoldással találkozhatsz és inspirálódhatsz a kódmegosztás jegyében.

![Chrome DevTools képernyőkép](https://blog.fps.hu/content/images/2015/12/search.jpg)

### Böngészőkbe épített fejlesztő eszközök

Szerencsére ma már minden modern böngésző (igen, még az IE is) rendelkezik beépített fejlesztő eszközzel, így nem kell bajlódnod külső programok telepítésével, ha például Internet Explorer alatt akarsz bővebb információt kapni arról, vajon miért is halt le a kódod, hiszen Firefox alatt semmi probléma nem volt vele. Tipikus példa erre, amikor egy objektum utolsó eleme után is vessző szerepel.

A fejlesztő eszközt a legtöbb esetben az F12 megnyomásával tudod előcsalogatni, és rendszerint alapvető hibakereséshez elegendő információkat kaphatsz. Beépített JavaScript konzol, DOM felépítés, Sütik kezelése, Hálózati forgalom és további hasznos „fülek” segítenek a betöltött oldalról minél több információt adni.

Személy szerint Chrome és az azzal együtt járó DevTools-párti vagyok, így leginkább annak használata során szereztem tapasztalatokat, amikből egy [előző írásomban](https://blog.fps.hu/chrome-devtools-funkciok/) párat meg is osztottam. Itt ismét kiemelek pár hasznos DevTools Extension-t a [számos elérhető kiegészítő](https://chrome.google.com/webstore/category/ext/11-web-development?ref=blog.fps.hu "DevTools kiegészítők") közül.

**[JavaScript Errors Notifier](https://chrome.google.com/webstore/detail/javascript-errors-notifie/jafmfknfnkoekkdocjiaipcnmkklaajd?ref=blog.fps.hu "JavaScript Errors Notifier kiegészítő Chrome-hoz")**

Meglehetősen egyszerű, de mégis hasznos kiegészítő, ami nem feltétlenül a DevTools-hoz kapcsolódik. Lényege, hogy ne kelljen mindig megnyitnod a konzolt, hogy lásd az esetleges JavaScript hibákat, hanem desktop notificationként vagy a címsorban megjelenik egy ikon, amire kattintva azonnal elérheted őket.

**[Visual Event](https://chrome.google.com/webstore/detail/visual-event/pbmmieigblcbldgdokdjpioljjninaim?ref=blog.fps.hu "Visual Event kiegészítő Chrome-hoz")**

Egy kattintással vizuálisan megjeleníti az oldalon található összes DOM elemhez kötött eseményt. Ha saját kódot javítasz, rendszerint tudod, hol is keresd az egyes eseményeket, ám idegen kóddal már más a helyzet. Nekem nem egyszer megkönnyítette az életem.

**[DomListener](https://chrome.google.com/webstore/detail/domlistener/jlfdgnlpibogjanomigieemaembjeolj?ref=blog.fps.hu "DOMListener kiegészítő Chrome-hoz")**

A DevTools konzol ablakában naplóz mindennemű DOM manipulációt (hozzáadás, törlés, attribútum módosítás, stb.)

![image](https://blog.fps.hu/content/images/2015/12/speed.jpg)

**[PageSpeed](https://chrome.google.com/webstore/detail/pagespeed-insights-by-goo/gplegfbjlmmehdoakndmohflojccocli?ref=blog.fps.hu "PageSpeed Insights kiegészítő Chrome-hoz")**

A Google által fejlesztett PageSpeed zseniális eszköz az oldalad betöltődési sebességének optimalizálására. Elemzi a kódod és javaslatokat tesz, hogy miket módosíts. Ami külön kiemelendő, hogy távoli eszközön futó Chrome példánnyal is együtt tud működni, így teljes képet kapsz az oldalad mobilon nyújtott teljesítményéről. Ami még ezen felül is kiemelendő, hogy [UX tippeket ad](http://www.morpheusmedia.com/blog/pagespeed-insights-adds-user-experience-recommendations/?ref=blog.fps.hu "PageSpeed Insights Adds User Experience Recommendations"), hogy az oldalad még inkább mobilbarát legyen. Elengedhetetlen eszköz minden fejlesztés során!

Remélem, sikerült hasznos, esetleg új eszközöket bemutatnom. Nagy részük már jóideje elérhető mindenki számára, de sokszor hajlamosak vagyunk elfeledkezni a használatukról. Pedig a hibakeresés leghatékonyabb módja, ha az ember igyekszik megelőzni a hiba létrejöttét minőségi kód írásával. Ahogy [Bob bácsi](http://codeguide.hu/2013/03/25/konyvajanlo-tiszta-kod/?ref=blog.fps.hu "Könyvajánló: Tiszta kód") mondaná:

> „Csak akkor tekinthetjük magunkat profinak, ha tiszta kódot írunk. Semmi sem indokolja, hogy a legjobbnál kevesebbet nyújtsunk”
### A web mindenkié, avagy web accessibility
URL: https://blog.fps.hu/a-web-mindenkie-avagy-web-accessibility/
Last updated: 2026-07-17T08:41:39.000Z
Számos alkalommal tapasztalom a webet böngészve, hogy az egyes weboldalak szeparált akadálymentes verzióval, vakbarát változattal rendelkeznek, ami igazából nem más, mint hátrányos megkülönböztetés, ráadásul az ilyen megoldások teljesen értelmetlenek.

### Univerzális design és nem vakbarát

Nagyon sokan azt hiszik, hogy az akadálymentesített weboldal sérült embereknek készül. Nem. Szimplán csak embereknek. Neked, nekem, a barátaidnak, az ő barátaiknak, mindenkinek. Egy website attól lesz akadálymentes (univerzális), hogy bárki, a legkülönfélébb élethelyzetekben is gond nélkül tudja használni azt és nem pedig attól, hogy megcsinálod a fekete háttéren nagy sárga betűs változatát is.

### Remek lehetőség

Az fps teljes támogatásával társadalmi munkában fejlesztjük a [Baráthegyi Vakvezető Kutya Iskola](http://barathegyisegitokutya.hu/hu/?ref=blog.fps.hu "Baráthegyi Vakvezető Kutya Iskola honlapja") honlapjának megújítását, mely hamarosan elérhető lesz a nagyközönség számára is. És miért írok minderről? Mert a projekt kapcsán végre lehetőségünk volt látássérült felhasználóval is felhasználói tesztelést végezni. Ez a lehetőség számos tapasztalattal szolgált a későbbiekre nézve is.

A weboldal célja, hogy rajta keresztül minél több látássérült ember juthasson speciális vakvezető kutyához, valamint számtalan hasznos információval, hírekkel szolgál a látogatók számára.

> „Küldetésünk, hogy minél több rászoruló élhessen függetlenebb, önállóbb és biztonságosabb életet vakvezető kutyával az oldalán.”

Sajnos nekem csak elvétve volt szerepem a weboldal tervezésében és fejlesztésében, viszont ott lehettem a felhasználói tesztelésen, amikor is Vida Zoltán először próbálhatta ki az oldalt.

![Vida Zoltán teszteli számítógépén a Baráthegyi web site-ját](https://blog.fps.hu/content/images/2016/01/teszt.png)

Zoli a weboldal tesztelése során a saját számítógépét használta, egy a látássérülteknek fejlesztett felolvasó szoftverrel ([Jaws](http://www.infoalap.hu/jaws/?ref=blog.fps.hu "Jaws oldala")) úgy, mintha csak otthon a kanapén ült volna.

### Tapasztalataink

Zoli elmondása szerint sikerült úgy elkészítenünk a site-ot, hogy ő, mint gyakorlott felhasználó csak egy-két ponton ütközött problémába.

A kevés probléma annak köszönhető, hogy a sitebuilder logikusan építette föl az oldal HTML szerkezetét ugyanis, a felolvasó szoftver magán a nyers HTML szerkezeten (DOM) megy végig sorról sorra és emeli ki az egyes részeket úgy, hogy a látható felületet nyilvánvalóan nem veszi figyelembe.

Ez azért jó hír, mert egy responsive site esetén - mint ez is -, semmiben sem módosul az oldal szerkezete (DOM), mindössze a különböző méretű kijelzőkhöz vizuálisan alkalmazkodik a megjelenítés.

A szabványok betartása, a W3C szerint is valid kód nem csak a SEO és a megjelenítés miatt fontos. A megfelelő sitebuild elkészítéséhez tartozik az is, hogy minden lényeges elemet, legyen az egy link, egy gomb, vagy akár egy kép, el kell látni a megfelelő tulajdonsággal. Ilyen például a title és az alt, melyek közül előbbi a linkek, utóbbi pedig a képek fölcímkézésére szolgál. Ha például egy linknek nem adsz title-t, akkor a felolvasó szoftver gond nélkül felolvassa az adott link URL paraméterének értékét, alt nélküli képek esetében pedig annyit mond, hogy itt egy ábra található. Létezik egy úgynevezett [WAI-ARIA szabvány](http://www.w3.org/TR/wai-aria/?ref=blog.fps.hu "a WAI-ARIA sabvány oldala a W3C-től"), mely lehetőséget biztosít, hogy fölcímkézz és besorolj olyan jelölő elemeket, mint például a div vagy span, melyek önmagukban nem hordoznak különösebb jelentéstartalmat, mint mondjuk a H2 (második szintű címsor). Többek között ezekről és további hasznos dolgokról [Szántai Károly WIAD-on tartott előadásában](http://www.ustream.tv/recorded/43838496?ref=blog.fps.hu "Szántai Károly előadása a WIAD-on ustreamen") hallhatsz bővebben.

Egy másik fontos dologra is odafigyelünk az oldalak készítésekor, mégpedig arra, hogy egér nélkül, kizárólag billentyűzet használatával is végigjárhatóak legyenek az egyes oldalak és azok alrészei.

Problémaként merült föl, hogy mikor Zoli kiválasztott egy cikket és a böngésző átirányította a kiválasztott cikk oldalára, akkor a felolvasó szoftver az oldal legtetején kezdte a felolvasást és nem pedig a cikk elején. (Ugyanis a szoftver lineáris blokkonként halad sorba az oldal felolvasásakor.) Úgy kell ezt a problémát feloldani, hogy a szöveges tartalmakra mutató linkekhez hozzá kell fűzni egy horgonyt, mely az átirányítás után egyből az adott szöveghez irányítja a felolvasó programot, így nem kell minden egyes oldalváltáskor végigugrálni a megfelelő tartalomig.

Volt még néhány olyan pontja az oldalnak, melyeket a szokástól eltérő módon kellett kialakítanunk. Ilyen volt az űrlapok megjelenítése és kezelése. Az esetleges hibaüzeneteket nem a mezők alatt kell strukturálni kódszinten (DOM), hanem már azok előtt, valamint küldéskor az űrlapok tetején fel kell tüntetnünk azt is, hogy sikeres volt az elküldés, vagy hibák léptek fel, és ha igen, melyek ezek. Ezeken felül, másik fontos dolog volt, hogy a kötelező mezőket nem elég egy csillaggal jelölni, hanem oda kell írni, hogy kötelező megadni.

![Zoli kutyája Borcsa alaszik a gazdi lábainál tesztelés közben](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n7o4yzhqRo1r105v8.jpg)

### Hasznos linkek

A fejlesztés során mindig figyelembe vesszük a [W3C WCAG 2.0 ISO 40500 szabványt](http://w3c.hu/forditasok/WCAG20/?ref=blog.fps.hu "W3C WCAG 2.0 ISO 40500 szabvány oldala"), mely nagy segítséget nyújt, hogy a weboldalak akadálymentesek legyenek. Szántai Károly web akadálymentesítési szakértő munkássága is sokat segít a fejlesztéseink során. [Károly blogját](http://www.akadalymentesweb.hu/?ref=blog.fps.hu "Szántai Károly blogja akadálymentesítésről") érdemes nyomon követni, számos hasznos és érdekes információval szolgálhat mindazoknak, akik számára szintén fontos, hogy minden web site akadálymentes lehessen.

A projekt során szerzett tapasztalatainkat a későbbiekben is kamatoztatni fogjuk, ráadásul abban a szerencsés helyzetben vagyunk, hogy Zolival együttműködhetünk a továbbiakban is, ha tesztelésről van szó és mint mindig, úgy most is egy lépéssel közelebb kerültünk egy boldogabb világhoz.

Végül álljon itt Zoli néhány mondata a teszteléssel kapcsolatban:

> „Hogy őszinte legyek az elején egy kicsit izgultam, hisz még sosem csináltam ilyet. Viszont nagyon tetszett, mert szeretem az elgondolkodtató és kihívást jelentő feladatokat. Emellett örülök, hogy segíthettem a Baráthegyi Vakvezető Kutya Iskolának. Vakként nagyon fontosnak tartom, hogy a weboldalak akadálymentesek legyenek, mert nincs annál dühítőbb, mint mikor valamit nem tudok önállóan megoldani az interneten. Az fps-nél jól éreztem magam, mert amellett, hogy érdekes és hasznos feladatot csináltam, figyeltek rám, minden apró észrevételemet komolyan vették. Ha olyan hibát találtam azonnal kijavították. Az elkészült oldallal kapcsolatban maximálisan pozitív élményeim vannak. Nagyon ritkán találkozom ennyire profin elkészített oldallal.”
### JavaScript debuggolás 1. rész
URL: https://blog.fps.hu/javascript-debuggolas-1-resz/
Last updated: 2026-07-17T08:41:49.000Z
A JavaScript hibák kezelése elég fontos és ugyanakkor kényes dolog a frontend fejlesztők számára. A weboldalak és webalkalmazások egyre több és bonyolultabb JS kódot tartalmaznak, így a debuggolás nem állhatott meg ott, hogy egy alert tartalmaként kiíratjuk az objektumunkat. Szerencsére ezt felismerték a böngészők fejlesztői is és hatékony, jól használható eszközökkel örvendeztettek meg minket.

A fejlesztő eszközök lehetőségeiről és használatáról később esik szó, először viszont érdemes kicsit a JavaScript hibakezelésével foglalkozni.

A JavaScript roppant egyszerű hibakezeléssel bír: ha gond van, dob egy kivételt és szép csendben lehal az egész script futása (ez természetesen egy sarkított megközelítése a dolognak). Ebből persze a felhasználó csak annyit érzékel, hogy hiába kattintgat, nem vált a slider a következő képre, vagy nem tűnik el az a fránya ajax-loader.

### Hiba objektumok

Amikor hiba történik, mindig létrejön egy objektum, ami a generált hibát reprezentálja. A JavaScript nyelv hét beépített error objektumot kezel, amik a hibakezelés alapját képezik.

#### Error

Az „Error” hibatípust az általános hibák leírására használhatod. Ez a leggyakrabban előforduló objektumtípus.

```javascript

var hiba = new Error("hibaüzenet");

```

#### RangeError

Akkor generálódik, amikor szám típusú változók „nem férnek” el egy adott intervallumban. Például a toFixed() metódus hívásával lehet előidézni, aminek az argumentuma 0 és 20 közötti egész szám lehet.

```javascript

var szam = 1.234;  
szam.toFixed(100); // RangeError

```

#### ReferenceError

Ez a hibatípus akkor generálódik, amikor nem létező változóra hivatkozol. Leggyakrabban egyszerű elgépelés miatt találkozhatsz vele.

```javascript

function fuggveny() {  
    valtozo++; // ReferenceError  
}

```

#### SyntaxError

Másik gyakran előforduló hibatípus, ami akkor jön létre, ha a JavaScript szintaktikai szabályainak nem felel meg a kódod. Általában lemaradó zárójelek vagy pontosvesszők eredményezik létrejöttét.

```javascript

if (valtozo) { // SyntaxError  
    // A lezáró kapcsos zárójel hiányzik

```

#### TypeError

TypeError típusú kivétellel találod szembe magad, amikor egy objektum nem létező értékére vagy függvényére akarsz hivatkozni.

```javascript

var valami = {};  
valami.fuggveny(); // TypeError  
// A valami objektum függvény metódusa nincs definiálva

```

#### URIError

Az encodeURI() és decodeURI() metódusok által generált hibatípus, ami akkor jön létre, ha a fentiek nem tudják értelmezni a kapott paramétert.

```javascript

decodeURIComponent("%"); // URIError

```

#### EvalError

Az eval() függvény helytelen futásakor generálódó hibatípus. A legújabb EcmaScript szabvány már nem tartalmazza, viszont a visszafelé biztosított kompatibilitás miatt még támogatják az interpreterek.

![Javascript kódrészlet](https://blog.fps.hu/content/images/2016/01/trycatch.jpg)

### Hibakezelés

JavaScriptben a hibakezelés a try – catch – finally szerkezettel kezelhető le. Az elkapott *error* objektum két leggyakrabban használt értéke a *name* és *message* tulajdonságok.

```javascript

try {  
    // Futó programkód  
} catch (error) {  
    // Hiba esetén lefutó kód  
} finally {  
    // Minden esetben lefutó kód  
}

```

A fenti szerkezetben lehetőséged van típusonként lekezelni a keletkezett hibát az instanceof kifejezés használatával.

```javascript

try {  
    // Futó programkód  
} catch (error) {  
    if (error instanceof TypeError)   
        // TypeError lekezelése  
    } else if (error instanceof ReferenceError) {  
        // ReferenceError lekezelése  
    } else {  
       // Többi hibatípus lekezelése  
   }  
}

```

Lehetne még részletezni a JavaScript hibakezelését, és érdemes is, viszont a cikk célja csak az alapok bemutatása volt, hogy a következőkben megtudd, mikor és miért kapod az adott hibaüzenetet, ezzel is gördülékenyebbé téve a debuggolást.

Ha részletesebben olvasnál még a témáról, [ezt a linket ajánlom](http://nyelvek.inf.elte.hu/leirasok/JavaScript/index.php?chapter=8&ref=blog.fps.hu).
### A UX útvesztőjében
URL: https://blog.fps.hu/a-project-guide-to-ux-design-konyv/
Last updated: 2026-07-17T08:41:58.000Z
Te tudod, hogy mi a különbség az IA és az IxD között? Vagy érdekel, hogy milyen lépések előzik meg a grafikai design készítést? Netán az, hogy milyen kutatási módszerekkel ismerheted meg a leendő felhasználókat?

**Akkor ez a könyv neked szól!**

### Mit takar a UX Design?

A UX Design mint fogalom, számos szakterületet foglal magában. Ezen területek célja, hogy olyan termékeket és szolgáltatásokat alkothass, melyeket a végfelhasználók saját tapasztalataikra alapozva kényelmesen, könnyedén és élményszerűen használhassanak, vehessék igénybe.

A UX Designer pedig az az ember, aki ezen szakterületeket elsajátítva képes olyan terméket vagy szolgáltatást létrehozni, hogy az megfeleljen az imént említett kritériumoknak.

Íme a UxD három fő szakterülete:

- **User research**  
A szakterület ismerője azért felel, hogy feltárja az adott célcsoport jellemzőit, szokásait, viselkedését. Ez az egyik legfontosabb művelet, hiszen ha nem tudod, hogy kinek készítest weboldalt, akkor nagy valószínűséggel nem lesz felhasználóbarát, hiszen nem tudod a megfelelő igényekhez igazítani.
- **Information architect**  
Ezen szerep viselőjének a feladata, hogy kialakítsa egy weboldal vagy webes alkalmazás tartalmi részének struktúráját, ő határozza meg, hogy mikor, hol milyen információk (szöveg, kép, videó, stb.) kapjanak helyet. Továbbá az ő feladata az is, hogy az ügyfél és az adott célközönség igényeinek megfelelő sitemapet és menüstruktúrát alakítson ki.
- **Interaction design**  
A terület szakértőjének feladata az, hogy meghatározza a weboldal vagy webes alkalmazás viselkedését. Például ha a felhasználó megnyom egy gombot, akkor mi történjen.

![egy aranyos maci vonalrajz, ami pattog](https://blog.fps.hu/content/images/2015/12/maci.gif)

### Lássuk a medvét!

Első lépés, hogy beazonosítsd milyen féle-fajta projekttel állsz szemben. Erre azért van szükség, mert minden típusnak megvannak a maga jellemzői, tartalmi és strukturális elvárásai, melyekre építve kielégítheted mind az ügyfél, mind pedig a leendő felhasználók igényeit.

Minden weboldal vagy webes alkalmazés lefedhető a következő négy alaptípus egyikével, vagy ezek speciális keverékével.

- **Márkajelenlét**  
Ezek általában olyan állandó jellegű weboldalak, melyek célja, hogy összekössék az adott márkát a nagyközönséggel.
- **Marketing kampány**  
Olyan időszakos (vagy állandó jellegű) weboldal, mely feladata az, hogy elérjen egy adott célközönséget és megismertesse őket az adott márka termékeivel vagy szolgáltatásaival, miközben az eléréseket pontosan mérik.
- **Tartalom szolgáltatás**  
Ezekre a webhelyekre jellemző, hogy olyan tájékoztató vagy szórakoztató jellegű leírásokat, cikkeket, képeket és/vagy videókat stb. tár a nagyközönség elé, melyeket nagy valószínűséggel csak itt kaphatnak meg.
- **Feladat orientált alkalmazás**  
Ezek az alkalmazások olyan szolgáltatást vagy szolgáltatások csoportját nyújtják, melyek hasznosak lehetnek az adott célközönség számára akár a munkájukban, akár a napi rutinjukba illesztve azt.

### Ismerd meg az ügyfelet

A hatékony együttműködés kulcsa a jó kommunikáció és a kölcsönös bizalom. Ezt, csak abban az esetben tudod elérni, ha megismered, hogy kinek és miért dolgozol.

Íme néhány kérdés, melyek használatával jobban megismerheted az ügyfeled:

- Mely projektekre a legbüszkébbek és vajon miért lett ez annyira sikeres?
- Volt-e olyan projektjük, melyre nem szívesen emlékeznek vissza és mondják el, hogy mi okozhatta a problémát?
- Dolgoztak-e már hasonló szakirányú emberrel egy másik projekten?
- Aggódnak-e a projekttel kapcsolatban és miért?

### Tégy javaslatot

Ahhoz, hogy a projekt futása alatt elkerüld az esetleges félreértéseket, készítened kell egy olyan javaslatot az ügyfél számára (és magadnak is), amiben például leírod, hogy milyen lépésekkel, milyen ütemben és milyen határidőkkel stb. fogsz haladni.

A teljesség igényével itt egy lista azokról a főbb pontokról, melyeknek szerepelnie kell ebben a bizonyos dokumentumban:

- **Címoldal**
- **Frissítések** (a dokumentum esetleges idő közbeni módosításainak időpontjai)
- **Projekt áttekintés**
- **Projekt megközelítése** (ütemterv lépései, hogyan fogod elvégezni a feladatot)
- **Hatályok** (elvárások/megfelelések mind az ügyfél, mind a saját részedről)
- **Szükségletek** (például, minden mérföldkő után egyeztetés az ügyféllel)
- **Teljesítések** (például, a wireframek elkészítése után az ügyfél elé tárni azokat)
- **Tulajdonjogok** (mind az ügyfél, mind a saját részedről)
- **Járulékos költségek és díjak**
- **Árazás** (a teljes projekt költsége)
- **Fizetési határidő(k)**
- **Köszönetnyilvánítás és aláírás**

![egy alvó ember fejéből egy gondolatbuborék jön elő benne UX felirat](https://blog.fps.hu/content/images/2015/12/alma.gif)

### Mindenkinek van egy álma…

A sikeres projekthez vezető út másik fontos momentuma, az úgynevezett kickoff, vagy más néven projekt indító megbeszélés. A megbeszélés lényege, hogy alaposan képbe kerüljön mindenki a projekttel.

Négy fontos dolgot kell tisztázni:

- Miért fontos ez a projekt az ügyfélnek?
- Mikor lesz sikeres a projekt?
- Milyen módszertan alapján érdemes haladni a projektben?
- Melyek azok a fő mérföldkövek és dátumok, melyeket mindenki be tud tartani?

Mikor először ülsz össze egy projekttel kapcsolatban, és felteszed az első két kérdést, előfordulhat, hogy ahányan vannak, annyiféle válasz fog érkezni. A cél, hogy a különféle válaszokat összefésüld, és egységes célokat fogalmazzatok meg.

Egy jó célra jellemző, hogy:

- egyszerű és érthető
- egyedi, tehát nem egy másik cél kicsavart módosulata
- mérhető, azaz összehasonítható lesz korábbi adatokkal

Érdemes elkövetni egy úgynevezett SWOT elemzést, mely segít, a megfelelő célok kialakításában. Az elemzés lényege, hogy megismerd a cég (ügyfél) erősségeit, gyengeségeit és lehetőségeit.

### Üzleti igények

A projekt indító megbeszélés eredményeként már van egy szép cél listád az ügyfél által, ám most itt az ideje, hogy több szemszögből is megvizsgáld őket.

Annak érdekében, hogy minél hatékonyabb megoldásokat tudj eszközölni rájuk, vedd őket sorban egymás után, és tégy fel kérdéseket azokkal kapcsolatban több embernek az ügyfél- cégen belül.

Tegyük fel, hogy az egyik cél ez volt:  
**„A felhasználók legyenek képesek nyomon követni a rendeléseiket.”**

Kérdezz rá:

- *„Miért fontos ez az önök számára? Netán azért, hogy ezzel lecsökkentsük a türelmetlen vásárlóik hívásait?”*
- *„A cégük jelenleg is rendelkezik ilyen követő rendszerrel? Ha nem, akkor szükség lesz rá, vagy esetleg egy harmadik féllel megoldhatják.”*
- *„Mennyire pontos rendszert szeretnének és milyen információkat kellene megjeleníteni?”*

Tegyük fel, hogy két embert kérdezel meg és mind a két embernek más volt az elképzelése. Nagyon fontos, hogy még a projekt elején kérdezz és együtt az ügyféllel beszéld is meg, máskülönben a munka végén derül ki a turpisság, akkor pedig már késő.

Ahogy haladsz előre, egyre tisztább képet fogsz kapni a célokról. Foglald őket egy listába, majd priorizáld azokat a projekt fő célja alapján.

Ha a feladatod, egy meglévő oldal áttervezése, akkor még most érdemes átkattingatnod. Valószínüleg lesznek olyan részei, melyeket át kell emelni az általad készített oldalba. Ez azért szerencsés, mert így már most észreveheted, mely részek nem a legmegfelelőbbek és javaslatot tehetsz rá egy összehívott megbeszélés keretein belül az ügyfélnek.

### Felhasználói igények

Az üzleti igények mellett ez a másik sarokköve egy jól működő weboldalnak, hiszen ha a produktum nem tesz eleget a felhasználói igényeinek, akkor nagy valószínűséggel nem is fogják használni azt, legalábbis nem szívesen.

Van jó néhány módszer, melyeket bevetve már a kezdetekkor feltérképezheted a célcsoportba tartozó felhasználók igényeit, például: kártyarendezés, kérdőív, interjú, fókuszcsoport stb.

Az elvégzett teszt vagy tesztek után, birtokában leszel jó pár olyan valós felhasználói viselkedésnek, döntésnek, tulajdonságnak, melyekre alapozva létrehozhatsz úgynevezett perszónákat.

### Perszónák

A perszónák olyan dokumentumok, melyek jellemzik az adott célcsoportba tartozó felhasználókat. A perszónák által tiszta képet kaphatsz arról, hogy az adott célcsoport hogyan fogja használni a weboldalt.

A perszónáknak két típusa létezik:

- **Célzott marketing perszóna**  
Mutatja, hogy mi motiválja a felhasználód vásárlásra.
- **Interaktív perszóna**  
Megmutatja a célközönséged viselkedési modelljét.

Egy perszónának az alábbi tartalmi elvárásoknak kell megfelelnie:

- **Profil kép**  
A legjobb, ha egy természetes, nem beállított képet használsz, ezáltal sokkal emberibb képet kapsz majd.
- **Név**  
Lehetőleg, olyan nevet válassz, ami elég természetes, szokványos és persze illeszkedik a választott archoz is.
- **Kor**  
Ügyelj rá, hogy ezt is a választott kép alapján határozd meg.
- **Lakhely**  
A lakhely nagyban befolyásolja a kulturális és viselkedési mintákat, ezért ezzel is körültekintően bánj.
- **Foglalkozás**  
A választott foglalkozás is sok mindenre utalhat. Például egy bolti eladó, nap mint nap számos emberrel találkozik.
- **Életrajz**  
Az életrajzi sztoritól lesz majd igazán életszerű a perszónád. Itt bele kell venni a származását, azt hogy miket szeret, miket nem stb. MInél részletesebben dolgozod ki, annál életszerűbb lesz.

### A UX és a SEO

Hogy jön össze a két szakterület?  
Nagyon egyszerű. A SEO specialista abban tud neked segíteni, hogy feltárja számodra a felhasználók viselkedését, akár a korábbi weboldalról, akár hasonló weboldal felhasználásával. Meg tudja mondani, hogy mely linkeket kattintották a legtöbbször, mely tartalmak után érdeklődtek a legtöbbet stb.

Később az oldaltérkép és az URL struktúra kidolgozásában is számíthatsz a segítségére, ezért ha lehet, élj a lehetőséggel és kérj tanácsot egy ilyen szakembertől.

![egy szem ikon, ami nézelődik és pislog](https://blog.fps.hu/content/images/2015/12/blink.gif)

### Vizualizálj

Első lépés, az úgynevezett Storyboarding készítés lesz. A módszert még a filmesek is előszeretettel használják, hogy rapid módon felvázolhassanak folyamatokat/jeleneteket anélkül, hogy a kamera előtt próbálgatnák el őket sok-sok pénzért. Másrészt azért is hasznos, mert az emberek szeretik a történeteket, és még inkább azonosulni tudnak a szereplőkkel. Ha ezzel állsz oda az ügyfél vagy a fejlesztőcsapat elé, akkor gond nélkül meg fogják érteni a dolgot.

Ehhez arra lesz szükséged, hogy a perszónáidból kiindulva felhasználói sztorikat készíts, pl.: „Károly szeretné megnézni, hogy merre jár a csomagja, mert már nagyon várja az érkezését.” Mivel tisztában vagy Károly kompetenciáival, viselkedésével, így le tudod modellezni, hogyan fog reagálni a helyzetre.

A következő lépésben az iménti sztorit kell felskiccelned 4 kockában.

- Károly ül a fotelben, már itt kellene lennie a futárnak, de nincs sehol.
- Károly kinyitja laptopját és behozza az oldalt, ahol egyből meg is találja a nyomon követési funkciót.
- Ráklikkel, és látja, hogy a csomagja 1 óra múlva ér oda.
- Károly boldog!

Ezek után a sztorikat priorizálnod kell a projekt fő céljának figyelembevételével.

A következő lépés az, hogy közös pontokat alkotsz a felhasználói és üzleti igények kapcsán, priorizálod azokat, majd ezt összeveted a technikai lehetőségekkel, amiben a fejlesztők lesznek a segítségedre.

Sajnos előfordulhat, hogy a három halmaz valamelyike nem idomul a másik kettőhöz. Ekkor annyit kell tenned, hogy a halmazokat addig alakítod, még ki nem hozod egyensúlyba.

Ha megvan, akkor össze kell hívni a csapatot, átadni nekik a priorizált követelménylistát mind a felhasználók, mind az üzleti fél részéről és alátámasztani a felhasználói történetekkel.

A végén a perszónákat is nyugodtan oda lehet adni nekik, hiszen így biztos, hogy végig tudni fogják, mit miért csinálnak.

### Sitemap és folyamatok

Már megvan a végleges követelménylistád is. Most el kell készítened a site egyes oldalainak hierarchikus felépítését, vagyis az oldaltérképet. Ez majd nagy segítség lesz a fejlesztőknek, a SEO szakembernek és az ügyfélnek is. Törekedj rá, hogy minnél kevesebb oldalad legyen és arra is, hogy minél kevesebb szinted.

A következő teendőd, hogy folyamatábrákat készítesz. Ezek azért jók, mert egyrészt már itt látod ha valami nem stimmelne, másrészt pedig a fejlesztés szempontjából is előnyös.

### Drótvázak és kommentek

A drótvázakkal és azon jól elhelyezett kommentekkel remekül prezentálhatod a javasolt tartalmakat és szerkezetet, valamint az oldal funkcionális viselkedését az ügyfél, a grafikus és a fejlesztők számára. Ráadásul ha kombinálod a korábban elkészített oldaltérképpel és folyamatokkal, akkor remek kis prototípust is készíthetsz belőle.

A drótvázakat ajánlatos szürkeárnyalatos formában elkészíteni, így nem fog értetlenkedni az ügyfél, és a grafikust sem vezeted tévútra. Lehetőleg ne használj benne képeket és egyedi betűtípusokat sem.

Érdemes felkommentezni az egyes részeket, hogy átadás után minden egyértelmű legyen mindenkinek, mi mire való. Bár a legjobb, ha minél kevesebb kommentet használsz, hiszen ez azt jelenti, hogy tiszta, egyértelmű felületet készítettél.

Íme néhány példa, hogy miket érdemes felcímkézni:

- tartalmak
- megjelenítési kötöttségek
- interakciós kötöttségek
- folyamatok
- rendszer üzenetek

Ügyelj rá, hogy a kommentjeiddel ne hagyj kiskapukat, azaz ne írj olyat, hogy „ezt vagy azt így kellene”, légy határozott és írd ezt: „ezt vagy azt így kell”.

Ha elkészítetted a terveket, akkor tárd az ügyfél elé, de először is magyarázd el neki, hogy ez nem a végleges felület, csak annak a terve.

### Prototipizálj

A legjobb módja, hogy leteszteld a megtervezett folyamatokat az oldalon még mielőtt késő lenne nem más, mint a prototípus készítés. A lényege, hogy az előzőleg legyártott drótvázakat interakciókkal látod el.

Természetesen, már a drótvázak elkészítése előtt is készíthetsz prototípusokat, méghozzá papíron. Előnye, hogy gyorsan elkészíthető, letesztelhető, és csak papír, valamint ceruza kell hozzá.

Az, hogy melyik módszert választod, gyorsan eldől, csak rá kell nézni az órára.

Akármelyik utat választod, miután elkészültek a prototípusok, érdemes letesztelni őket valódi felhasználókkal is. Előfordulhat, hogy olyan problémák jönnek elő, melyekkel nem is számoltál. Aggodalomra semmi ok, ebben a fázisban még bátran korrigálhatod a terveket. Persze a módosítás után, újabb tesztekre lesz szükség mindaddig, még az összes felbukkanó nagyobb hibát ki nem javítottad.

### Végső állomás

Ezen a ponton már azt hihetnéd, hogy nyugodtan hátradőlhetsz, de az igazság az, hogy a projekt sosem ér véget.

Azon túl, hogy végig kell követned mind a grafikus, mind pedig a fejlesztők munkáját, egy olyan folytonos tesztelési fázis veszi kezdetét, mely a termék „haláláig" tart.  
A különféle tesztelési és kutatási módszerek segítségével élezheted, finomhangolhatod a produktumot, hogy még inkább megfeleljen az amúgy is állandó jelleggel változó felhasználói igényeknek…
### Kezeld úgy a felhasználóid, mint a gyermeket
URL: https://blog.fps.hu/felhasznalok-mint-gyermekek/
Last updated: 2026-07-17T08:42:07.000Z
A minap olvastam egy [cikket](http://uxmag.com/articles/treat-your-users-like-children?ref=blog.fps.hu), ami nagyon érdekes oldalról közelíti meg azt, hogyan gondoljunk a felhasználóinkra. A gyermeki elméket szinte lehetetlen megfejteni, és legalább annyira nehéz irányítani. A szülők sokszor előre megtervezik, hogyan nevelik majd a gyermeküket, vagy hogyan terelik őket a megfelelő útmutatás segítségével céljaik eléréséhez. Mindez sokszor elvesztegetett időnek tűnik. A gyerekek általában nem hajlandóak követni ezeket a mintákat, bármennyire is hasznos lenne ez számukra. Kapcsolatban lenni ilyen kisemberekkel nagyon is emlékeztet engem a UX szakemberek mindennapjaira.

### Tekints rájuk gyermekként

Azonnal megváltozik a userekről alkotott képed, ha belegondolsz, milyen nehéz gyereknek lenni. Ahogyan a gyermek folyamatosan felfedezi a világ ismeretlen dolgait, a userek is ugyanúgy viselkednek, amikor a szolgáltatásoddal először találkoznak. Bennük is ott a sok megválaszolatlan kérdés és kíváncsiság. A mi feladatunk, hogy a felfedezéshez vezető utat kényelmessé és érdekessé tegyük számukra.

### Türelmetlenség

Légy őszinte, mennyi időt töltenek valójában a felhasználóid a siteodon azzal, hogy minden információt tüzetesen végigolvassanak? Kutatások bizonyítják, hogy ha egy tartalom feleslegesen ismétlődik és még más „inzultus” is éri őket (pl. lassú az oldal), akkor jó esetben sem mennek egy-két oldalnál tovább. Az átlag türelmi idő mobilon 2-3 , desktopon pedig 7-8 másodperc. A felhasználóidat csak a lényeges információk érdeklik és olyan gyorsan, amilyen gyorsan csak lehetséges. A gyermekek is pont ilyenek, csak próbálj meg egyet is megváratni 30 másodpercre egy olyan dologgal, amire már nagyon vágyik, pedig karnyújtásnyira van. Amikor a tartalom stratégiádat tervezed, legyen ez az egyik fő szempont.

![egy kisgyerek ül az apja nyakában](https://blog.fps.hu/content/images/2015/12/jutalmazas_ele.jpg)

### Jutalmazás

Gondolj bele, mennyi időt töltesz tesztekkel annak érdekében, hogy lásd azt, hogy a szolgáltatásodban mely pontokon akad el a user. Ha a felhasználóidban nincs meg a kellő elégedettségérzés az első másodpercekben, mert mondjuk nem talál valamit, akkor ott valamit jobban ki kell találnod és fejlesztened. A gyermek is pontosan így működik, mert ha egy gyermek valamit megszokással keres, de nem találja meg azt, akkor kezdődik a szülők által jól ismert nyafogás.

### Tekints magadra szülőként

Most hogy gyermekként tekintesz a felhasználódra, ahhoz, hogy jól megértsd ezt a kapcsolatot, ideje magad szülőként vizsgálni ebben a komplex szimbiózisban.

### A legjobbat cselekedni…

A számítógéped és a folyamatábráid felett ülve a legfontosabb cél mindig ugyanaz, hogyan tudod a lehető legjobb élményt megteremteni és a felhasználóid életét könnyebbé, élhetőbbé tenni. Nagyszerű dolog ez a fajta elkötelezettség. Ahogyan a szülőknek a legfőbb elkötelezettsége a gyermek, egy tervezőnek is pontosan ezzel a habitussal kell hozzáállni a felhasználóihoz. Ahogyan a szülő a legjobbat szeretné a gyermekének, egy tervezőnek is ezt kell szem előtt tartania.

### Keresd a biztonságot a konvenciókban

Minden tervező szakmai életében eljön az a pont, amikor egy projektben el kell döntenie, hogy a konvencionális kitaposott úton közelíti meg a problémát, vagy vállalja a kockázatokat és letér arról. A szülők is pontosan ilyenek, mert mindig a biztonságosabb utakat szeretik járni, pláne ha a gyermekeikről van szó. Nagyon jó okokat kell találni a szülőknek, hogy másfelől közelítsenek a gyermeknevelés felé. A felhasználóidra is pontosan így kell gondolnod, amikor új konvenciókkal közelítesz feléjük.

![két kölyök öltönyben](https://blog.fps.hu/content/images/2015/12/utolso_ele.jpg)

### Mégse légy túl konvencionális

Ahogyan a világ változik, egy tervezőnek ezzel együtt kötelessége vele változni. Meg kell értened a világ rezdüléseit, és vele változtatnod a saját szabályaidat is. Kitűnő példája az, ahogyan Steve Jobs is képes volt megváltoztatni a világnak a technológiai eszközök használhatóságról alkotott képét. De ne kövess el kockázatos és nagyon szokatlan, a felhasználóidtól teljesen idegen megközelítéseket. Ne félj az új dolgoktól, ha kellőképp tesztelted és megismerted milyen hatást fog kiváltani a usereidből. Amikor a szülők elkövetik ezt a hibát a gyereknevelés során, akkor olyan kis felhasználókat hoznak létre, akik egész felnőtt korukban utálni fogják azt a szokatlan mentalitást, ami mentén nevelték őket, főként ha semmilyen pozitív fejlődéssel nem jár.

### Akár egy csecsemő

Minden új projekt olyan akár egy csecsemő. Egy újszülött rengeteg odafigyelést és törődést igényel ahhoz, hogy minden rendben legyen, még ha el is kell tűrni az álmatlan éjszakákat és az állandó pelenkacserét. Ugyanez mondható el egy folyamat tervezéséről. Erős jelzéseket kell alkotnod, mert ugyanúgy, ahogy egy gyermeknek szüksége van jelentős pozitív megerősítésekre, úgy szüksége van a szignifikáns pozitív interakciókra a felhasználóidnak is. Ahogy a gyermekben is elraktározódnak a negatív élmények a gyenge rossz kapcsolatok emlékeiről (implicit memória), ez ugyanúgy kialakul a usereidben, ha nem ápolod és fejleszted a velük való interakciókat. Tehát mindig add meg a kellő figyelmet és törődést a felhasználóidnak.

### Egyetértés

Ahogy egy projekted a „serdülőkorba” kerül, nagyon fontos az őszinteség és az egyetértés. Amikor egy projekt során több ember dolgozik együtt, úgy nagyon fontos a mérföldkövek és a végső cél lehető legpontosabb definiálása. Abban az esetben, ha egy projekten belül különböző elképzelések vannak a végső eredményről a partnerek között, azt már a kész alkotás fogja megsínyleni, és ezekkel együtt nő a hibalehetőségek száma. A családban is nagyon fontos, hogy a két szülőnek azonos képe legyen a nevelésről, különben a gyerek személyisége fogja megsínyleni, és figyelme megosztottá válik. A nevelésben is ha ez bekövetkezik, akkor általában a gyermek kamaszkorában elég nehezen kezelhetővé válik. Ez később általában az őszinteség rovására megy, és némely viselkedési normák mutációja vagy hiányossága általában később bukik ki.

### Összegzés

A tervezők arra összpontosítanak, hogy a legmegfelelőbb megoldásokat nyújtsák felhasználóik számára, pontosan úgy, ahogyan egy szülőnek is édes kötelessége törődni a gyermekével, hogy az a legmegfelelőbb itinert kapja az élethez. A tervezők és szülők egyaránt az idejük nagy részét olyan kérdések megválaszolásával töltik, ami megóvja a kényelmetlenségektől és a kellemetlenségektől úgy gyermekeiket, mint a usereket.

Az analógia segít téged, hogy olyan örömmel és törődéssel foglalkozz a projektjeiddel, mint ahogyan az emberek törődnek életük legfontosabb teremtményeivel. Ha őszintén teljes értékű emberként tekintesz az első pillanattól gyermekedre, úgy könnyítheti meg az Ő és saját életedet, ha megadod mindazt az útmutatást, ami segít neki a boldogulásban akkor is, ha már nem fogod a kezét!
### Mit mond valójában az ügyfél?
URL: https://blog.fps.hu/mit-mond-valojaban-az-ugyfelnek-a-grafikusoknak/
Last updated: 2026-07-17T08:42:15.000Z
Grafikusok, accountok, project managerek számára nélkülözhetetlen puska, ami segít abban, hogy megértsd valójában mit is jelentenek az ügyfeleid visszajelzései és aszerint cselekedj lerövidítve a folyamatokat. :)

Az alábbi infografika [eredetijét](http://imgur.com/31aifUS?ref=blog.fps.hu) átültettük hazánk nyelvezetére, hozzáadtunk és elvettünk belőle. Reméljük hasznos lesz számodra és kellemes perceket is okoz neked.

![Mit mond valójában az ügyfél a grafikusnak?](https://blog.fps.hu/content/images/2015/12/blog_140515_tom.jpg)
### Digitális PR a jobb SEO eredményekért
URL: https://blog.fps.hu/digitalis-pr-jobb-seo/
Last updated: 2026-07-17T08:42:25.000Z
A Google március végén hozta nyilvánosságra a legfrissebb, több mint 200 keresési találati rangsorolási faktorát, melyen a PR is megjelent. Az elmúlt hónapokban azoknál a weboldalaknál, akiknek erős digitális PR jelenlétük volt, jelentős javulás mutatkozott a weboldal keresési találati eredményeiben. Ezek szerint a közvetlen linkkapcsolat nélküli PR tevékenység is javítja a SEO eredményeket?

A válasz röviden: igen, és ezért a digitális PR kétség kívül még nagyobb szerepet kap az online marketing eszköztárában.

### Hogyan lesz a PR-ból SEO rangsorolási faktor?

A közzétett lista szerint az úgynevezett „implied” linkek (magyarul talán a hallgatólagos, névleges linkeknek lehetne fordítani) pozitívan járulnak hozzá a weboldal keresőoptimalizálási eredményeihez. Ezek a kapcsok általában a brandhez kapcsolódó nevek, termékek, amelyek valójában nem tartalmaznak direkt linket a weboldalra, de a keresőrobotok márkanév alapján összekapcsolják a tartalmakat. A PR kiváló lehetőséget biztosít a brand természetes környezetben való megjelenésére, így maximálisan tudja támogatni az egyéb megjelenéseket, ezáltal a keresőoptimalizálást is.

### Növeld a brand ismertséged, növeld a SEO eredményeket

Online marketing szempontból minden kiemelt fontosságú, amit a Google támogat. A Google már a kezdetektől fontos rangsorolási faktornak tartotta az oldalra mutató linkeket. A Pingvin algoritmusfrissítés óta viszont alaposan vizsgálja ezeket a linkeket, és próbálja kiszűrni az „épített” linkeket a természetes linkek javára. És ugye természetes linkeket nem könnyű szerezni, nagyon jó tartalom kell ahhoz, hogy elkezdjenek hivatkozni az oldalunkra. Az online PR által létrejött kapocs is kézzelfogható eredményeket hoz.

Ha eddig nem foglalkoztál ezzel a területtel, érdemes rá időt és energiát szentelni. Sosem árt a márkád vagy terméked ismertségét növelned, ha komolyan veszed a keresőoptimalizálást, akkor nem okoz problémát a brandépítéshez szükséges tartalom előállítása sem.

### Márkanév a domainben

Négy-öt évvel ezelőtt még ölre mentek a cégtulajdonosok egy-egy kulcsszavas domain névért. Ma már ennek a jelentősége csekély, ezért bátran merem ajánlani, hogy ha brandet szeretnél építeni, használj a brandet erősítő és támogató domain nevet.

Még jobb SEO eredményeket szeretnél? Kezdj el még ma PR-al foglalkozni, hogy minél hamarabb jöjjenek az eredmények. Ha nem tudod, hogyan kezdj hozzá, kérj PR-ban vagy online marketingben jártas szakembertől segítséget.
### Hogyan készül: a keresőoptimalizálás
URL: https://blog.fps.hu/keresooptimalizalas-seo-hogyan/
Last updated: 2026-07-17T08:42:37.000Z
Az utóbbi időben egyre több régi és új ügyfél érdeklődött nálam a keresők működéséről és a keresőoptimalizálásról. Többen jelezték is, ha úgyis rendszeresen blogolok, miért nem írok erről is. Engedtem a nyomásnak és megszületett ez a kis összefoglaló. Figyelem! Ez a poszt azoknak szól, akik NEM foglalkoznak keresőoptimalizálással, így csak akkor olvass tovább, ha érdekel.

### Miért fontos a keresőoptimalizálás?

Az internet hajnalán, a kilencvenes évek elején még napi pár száz megabájtnyi tartalom került fel a netre naponta, 2014-ben becslések szerint naponta 2,2 millió terabájtnyi új információval bővül a világháló. (1 terabyte = 1024 gigabyte). Akkora adatmennyiség áll rendelkezésünkre, hogy el se lehet képzelni. Ebben a hatalmas adattengerben a felhasználók naponta 4 milliárd keresést végeznek. Akik a keresők segítségével szeretnének információhoz jutni, nagyon fontos, hogy számukra releváns találati eredményeket kapjanak kézhez, ehhez szükséges a keresőoptimalizálás.

### Hogyan működnek a keresők?

Minden keresőmotor (Google, Yahoo, Bing, stb.) nagyjából hasonló keresési algoritmus szerint dolgozik. A keresési algoritmusok folyamatosan változnak éppen azért, hogy ebben az irgalmatlanul nagy adathalmazban a számunkra leginkább releváns tartalmakat találja meg. Több száz féle paramétert vesz figyelembe a keresőmotor, ezt nagyjából tudja is minden keresőoptimalizálással foglalkozó szakember, mivel időről-időre közzéteszik ezeket. Azt viszont nem teszi közzé egyik keresőóriás sem, hogy melyik paramétert mekkora súlyozással vesz figyelembe. És itt jön képbe a keresőoptimalizálással foglalkozó szakember munkája. Ő ismeri ezeket a paramétereket, a feladata, hogy a lehetőségekhez mérten minél több paraméter a lehető legoptimálisabban legyen használva. Folyamatosan figyeli az eredményeket és módosít, tesztel, elemez, újratervez, hogy minél előrébb szerepeljen a keresési találati listán az adott weboldal.

### Hogyan változott a keresési algoritmus?

Mivel Magyarországon a Google a kereső piac 98%-át birtokolja, így a továbbiakban csak erről lesz szó. A Google 1997-es indulása óta több ezer algoritmusfrissítést hajtott végre. (2000-ig visszamenőleg a nagyobb változtatások a [moz.com](http://moz.com/google-algorithm-change?ref=blog.fps.hu)\-on megtekinthető) Az első 10 év gyakorlatilag a kulcsszavakra való optimalizálásról szólt. Ahhoz, hogy valaki a keresési találati lista élére kerüljön elég volt annyi, hogy minél többször szerepeltette az oldalán az adott kulcsszót, épített rá néhány linket, és már fel is ugrott az első pozícióba. Erre hamar rájöttek az ügyeskedők, no meg a Google is, ezért egyre többféle paramétert vett figyelembe a rangsoroláskor, illetve elkezdett egyre szigorúbban fellépni az ún. [black hat seo](http://hu.wikipedia.org/wiki/Black%5FHat%5FSEO?ref=blog.fps.hu) ellen.

### Google Panda és Pingvin a rossz minőségű tartalom kiszűrésére

Az első nagyobb támadás a Google részéről a Pandának elnevezett algoritmus váltás volt. 2011 nyarán lépett életbe, célja hogy kiszűrje a régi, elavult, gyenge minőségű, nem frissülő tartalmakat. Ez jelentős átrendeződést hozott a találati listákon. 2012 áprilisában a Pandát követte a Pingvin névre keresztelt következő „csapás”, melynek célja, hogy kiszűrje a nem megfelelő minőségű és mennyiségű linkeket, spammeléseket. Ennek valamivel kisebb volt az érezhető hatása, de jónéhány oldal, aki átvészelte a Pandát, belebukott a Pingvinbe. Jó esetben csak hátrasorolás lett a büntetése, rosszabb esetben hosszabb-rövidebb időre kitiltotta az oldalt a keresőből.

[![Google panda, pingvin és kolbiri doodle egyben](https://blog.fps.hu/content/images/2015/12/eva_panda_pingvin_kolibri.jpg)](http://hub.uberflip.com/h/i/1816482-meet-the-google-zoo-understanding-how-the-animals-of-the-internet-affect-your-business?ref=blog.fps.hu)

### Új irány: Google Kolibri

Az évek előre haladtával és az információk exponenciális növekedésével párhuzamosan egyre többen kezdtek el ún. long tail (több szóból álló kifejezések) kulcsszavakkal keresni, mivel így pontosabban meg lehet határozni a keresés célját, és ez jóval specifikusabb találati listát eredményez. Ezzel egyre közelebb kerülünk a [szemantikus web](http://hu.wikipedia.org/wiki/Szemantikus%5Fweb?ref=blog.fps.hu)hez. Többek között ez is szerepet játszott abban, hogy a Google is segítse ezt a törekvést, és 2013 közepén szabadjára eresztette a Kolibrit. A Kolibri célja, hogy az egyedi keresőkifejezések helyett a teljes keresési információbázist figyelembe véve próbálja meg a Google keresője kitalálni, hogy mely találatok a leginformatívabbak a felhasználó számára. Ezzel ismét feladta a Google a leckét a keresőoptimalizálással foglalkozó szakembereknek. Ez a fajta váltás teljesen más megközelítést jelent SEO szempontjából, az eddigi technikai rész picit háttérbe szorul, és a tartalom került fókuszba.

### Hogyan lehet ma a találati lista élére jutni?

Ez egy nehéz és összetett kérdés. A perszonalizált keresési találati oldalak már eleve nehezítik a helyzetet, ugyanis könnyen előfordulhat, hogy ugyanarra a keresési kifejezésre ugyanaz az oldal három embernél három különböző pozícióban jelenik meg. Persze fontos, hogy minél magasabb pozícióba legyen az oldal, hiszen a keresőt használók 70%-a nem lapoz tovább a találati oldalak között. Gyakorlatilag nincs különbség abban, ha a 4\. vagy a 14\. oldalon jelenik meg az oldal. Mobilon ez hatványozottabban igaz, mert míg desktopos keresőfelületen egy képernyőn az első 4-6 találatot látjuk (a hirdetések számától függően), addig mobilon legjobb esetben is az első három-négy találatot.

Ha keresési forgalomról beszélünk egy weboldal esetében, ne a kulcsszó pozíció legyen a mérőszám, hanem a keresőkből érkező forgalom mennyisége.

A fentiekből is látszik, hogy amikor keresőoptimalizálásról van szó, mennyi mindenre kell odafigyelni ahhoz, hogy a keresőkben megtalálják a felhasználók az oldalt, és át is kattintsanak. Ha megkérdezik tőlem, hogyan lehet ezt jól csinálni, egy nagy társasjátékhoz szoktam hasonlítani a keresőoptimalizálást, ahol lépésről lépésre haladok előre, ha jó mezőre lépek, nagyot ugorhatok előre, de néha előfordul, hogy egy-két lépést vissza kell lépni, vagy még egy kört kell futni, de előbb-utóbb célba érek.

Ha még mindig érdekel a keresőoptimalizálás, olvasgass [korábbi posztjainkat](https://blog.fps.hu/tag/seo/) a témában.
### Problémás az ügyfél?
URL: https://blog.fps.hu/porblemas-az-ugyfel/
Last updated: 2026-07-17T08:42:46.000Z
Ez is a te hibád, vagy a csapatodé. Hányan nyavalyognak, hogy ilyen-olyan idóta az ügyfelük. Réges-régen még külön oldalt is indítottak erre a témára ([Clients From Hell](http://clientsfromhell.net/?ref=blog.fps.hu)), ami persze vicces, magam is jókat röhögök rajta. Viszont meggyőződésem, hogy alapvetően nem az ügyfelek a problémásak, hanem a hiba benned, a csapatodban, de legfőképpen a kommunikációtokban rejlik. Felsorolok pár eshetőséget, lehet megtalálod, hol lehet a kutya elásva…

### Nem tudsz nemet mondani

Nézz magadba. Már az első alkalommal megérezted, hogy ez a kapcsolat nem fog menni, ugye? Akkor miért is nem mondtál nemet? Gondolkozz ezen. Olyan ez, mint egy párkapcsolat ([digitális szimbiózis](https://blog.fps.hu/digitalis-projektek-partnerseg-szimbiozis/)), hosszabb távra kell tervezni (az egyéjszakás kalandokat most hagyjuk, nem ide tartoznak). Beszélned kell erről az ügyfélnek, tisztába kell tenned, hogy mire vállalkozik veled és a csapatoddal közösen. Lehetetlen határidőkkel, elképzelésekkel érkezett? [Mondj nemet](https://blog.kolboid.eu/nemet-mondani-jo/?ref=blog.fps.hu)! Ha ekkor csak megemlíted, hogy ezt így és úgy nem lehet, de végül mégis megköttetik a szerződés, akkor később ne rinyálj, hogy az ügyfél eszement. Pár perces beszélgetés után kiderülhet, hogy működik a kémia köztetek, vagy éppen nem. Megérti amiről beszélsz? Elfogadja a véleményed, tapasztalatod vagy sokkal okosabbnak gondolja magát (Igen? Akkor nincs is rátok szüksége)? Ha a kérdések valamelyikére nem a válasz, akkor legyen a te válaszod is nem, különben egy újabb „hülyét” veszel a nyakadba. Ööö, ki is a hülye?

### Nem szántál rá elég időt

Már rég megy a projekt és folyamatosan újabb és egyre hajmeresztőbb ötletekkel áll elő az ügyfél? Tekints vissza. Elég időt szántál a kommunikációra? Biztos, hogy türelmesen leültél és megbeszéltétek, hogy miért azt az irányt választottátok? Valóban felelős döntést hozott az ügyfél? Biztos, hogy a megfelelő ember hozta ügyfél oldalról a döntést? Tisztáztátok előre a felelősségi, döntési hatóköröket? Nem? Kinek lett volna feladata, kinek a legfőbb érdeke, hogy ez világos legyen mindenki számára? Persze, hogy a te feladatod és a csapatod érdeke.

Most fordítsd meg a lapot. Kicsit légy te az ügyfél. Megbíztál egy csapatban, cégben, akik mindig „eltűnnek”, fogalmad sincs mi folyik, csinálnak valamit a projekteddel, vagy mi a helyzet? Írsz egy emailt, de napokig nem kapsz választ. Mi van ezekkel, rosszul választottam? Szépen lassan feltúrod az agyad és később mikor felbukkannak, hiába jönnek a legjobb megoldásokkal, eleve van egy rossz hozzáállásod az egészhez és azt tutira ki is töltöd rajtuk. Fordítsd vissza a lapot.

Ha elhanyagolod az ügyféllel való törődést, ne csodálkozz ha „problémássá” válik. Valójában ki is a problémás? ;) Ráadásul, ha a másik oldalon egy nagy, vagy nagyobb szervezet áll, akkor az ottani kapcsolattartó szinte biztos, hogy védeni fogja a saját sejhaját. Hogyan? Rád, vagy rátok fog mutogatni, hogy nem csináltátok meg időre, nem erről volt szó stb. Te és a csapatod lesz a hibás. Megint érkezik a nagy szöveg: „Ezzel az ügyféllel nem lehet együtt dolgozni”. Ha hagyod, hogy probléma alakulhasson ki, ha hagyod, hogy az akuttá váljon. Ne csodálkozz. A lustaságod, a konfliktustól való félelmed, a „nemtörődömségetek” okozza a galibát és nem az ügyfélnél kell keresni azt a bizonyos szálkát.

### Kommunikáció még mindig

Vess egy pillantást a web site-odra, vizsgáld felül a kommunikációd. Milyen posztokat tolsz a Facebook, twitter, Google+, LinkedIn csatornádon? Azt vonzod be, amit magadról közvetítesz.

Ha elolvastad a fenti mondatokat és egyik sem igaz az esetedre, akkor tényleg egy problémás ügyfélbe botlottál, szabadulj meg tőle MOST ;) Ne feledd, nem kell megfelelned mindenkinek. Foglalkozz inkább azzal, aki megérdemli!
### 9 kihagyhatatlan Photoshop plugin
URL: https://blog.fps.hu/9-photoshop-plugin/
Last updated: 2026-07-17T08:42:55.000Z
Photoshop. Már itt véget is érhetne a poszt, hisz mi az, amit nem lehet megvalósítani benne? Idővel. És a hangsúly most is, mint meg annyiszor, az időn van.

Plugin. Okos, kis beépülő programok, scriptek, mik megkönnyítik hétköznapjainkat és egyben időt spórolnak. Ebben a posztban összeszedtem 9 olyan plugint, amik azon felül, hogy ingyenesek, valóban megkönnyítik munkánkat.

Mielőtt a listával feltüzelnélek, viszont nem telepítettél plugint pár éve, vagy egy újabb verziójú Photoshopot használsz, nem árt, ha letöltöd az aktuális [Adobe Extension Manager](http://www.adobe.com/hu/exchange/em%5Fdownload/?ref=blog.fps.hu)\-t. Ezen keresztül történnek mostanság a pluginok beágyazódásai, sok „Elfogadom”, „Tovább” és „OK” után.

### Social Kit

![Social Kit képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_1.jpg)

A [source](https://madebysource.com/?ref=blog.fps.hu) csapatának ingyenes bővítménye. Telepítés után nem sok mindent kell mondani róla. A 4 fő social site (Facebook, Google+, twitter, YouTube) profil sablonját generálja 1 klikkre, amit utána a „smart object”-eknek köszönhetően könnyedén személyre szabhatjuk. Facebooknál applikációs oldalt és hirdetést, Google+-nál a profil oldalon felül hirdetési felületet is tudunk generálni. Bónusz a „Social buttons” opció. Próbáld ki! És persze automatikusan frissül, ha valamelyik site változtat a megjelenésén.

[Letöltöm](http://socialkit.madebysource.com/?ref=blog.fps.hu)

### Random User Generator

![Random User Generator képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_2.jpg)

Szorosan az előző bővítményhez kapcsolódik a Random User Generator. Volt már, hogy kellett egy Facebook profil, képpel, névvel? Megoldás, kitalálok egy nevet és letöltök egy átlagos arcot a Google-ről. És 50? Ezért van ez a plugin.

Használata nem bonyolult. Csak generálsz egy felhasználót, akinek a képét „drag and drop” a megfelelő helyre, a nevét pedig, ha nem akarsz gépelni, csak kimásolod. A képek teljesen átlagos profil képek, a nevek azonban angol és spanyol nyelvterületről származnak. Így nekünk marad a Gipsz Jakab vagy a [magyar névgenerátor](http://hu.fakenamegenerator.com/gen-random-hu-as.php?ref=blog.fps.hu).

[Letöltöm](http://randomuser.me/extension/?ref=blog.fps.hu)

### Trevor Morris Scripts

![Egyforma betűközt mutató képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_3.jpg)

Személyes kedvencem. Találkoztál már azzal a mérhetetlenül idegesítő problémával, amikor egy menünél szeretnéd a szöveges menüpontokat azonos távolságra rendezni? Nem véletlenül kezdődik ennek a bővítménynek a panelja a „Horizontal Spacing” opcióval. Azonos távolság. Imádom. Ha csak ez az egy lehetőség lenne, már akkor is megéri telepíteni, de persze található még vertikális igazítás, réteg keresés név alapján, és még pár lehetőség, köztük az „Array Generator”-ral. Bármilyen típusú réteget, általad megadott számú oszlopba és sorba duplikál. És a legjobb, te állíthatod be a távolságot is. Szerintem nem kell tovább ecsetelnem az ebben rejlő lehetőségeket.

[Letöltöm](http://dmonzon.com/freebies/12-photoshop-tools-cs6/?ref=blog.fps.hu)

### Flaticon

![3 flat ikon](https://blog.fps.hu/content/images/2015/12/tompost_4.jpg)

41 394\. Igen, a [flaticon.com](http://www.flaticon.com/?ref=blog.fps.hu) megcsinálta. A site ingyenes ikonjai Photoshopban. Benne. Nincsen hova töltöttem, nincsen nyissuk meg az Illustratort az .svg miatt. Egyszerűen keresünk, kiválasztunk és „drag and drop” vagy dupla klikk. Vektorosan. Mondtam már, hogy 41 394 ikon? Annyival kitapétázom az irodát. Nem is rossz ötlet.

[Letöltöm](http://www.flaticon.com/download-plugin?ref=blog.fps.hu)

### Guide Guide

![Guide guide képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_5.jpg)

Tadám! 960px. Osztva hárommal, mínusz 40px space-ing. Kétszer. Mínusz oldalsó margók…

Mennyi? Hol jártam?

E helyett. 3 oszlop, 40px közzel. Generáld! Franc! A margót elfelejtettem. OK. Törlés. Balra 30, jobbra 31\. Generál. És ott vannak a segédvonalak által behatárolt 273 pixel széles területeim. Ennyi? Nem. Nem csak az aktuális felület (vászon) méreteit veszi alapul, hanem az aktuális kijelöléssel is működik. Ezután a site builderek imába foglalják a neved.

[„This grid is mathematically impossible.”](http://www.crystalinks.com/escherevolutioncircle.jpg?ref=blog.fps.hu) Hangosan nevettem a hibaüzeneten.

[Letöltöm](http://guideguide.me/?ref=blog.fps.hu)

### Layer Guides

![Layer Guides képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_8.jpg)

Az előzőnek egy egyszerűbb verziója, ha még nullákat se akarunk írni, a Layer Guides. Kiválasztod a megfelelő réteget. Alja, teteje, oldalai, közepe. Máris ott vannak a segédvonalak. Ennyi. Nem tud többet, nincs túl bonyolítva, és mire elolvasod ezt a részt, már túl is magyaráztam.

[Letöltöm](http://gastonfig.com/2013/05/layer-guides-extension/?ref=blog.fps.hu)

### Layrs

![Layrs képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_6-1.jpg)

Túl sok a „Rectangle 1 copy…” réteged? Kikapcsoltál egy rakás felesleges effektet és nincs kedved egyenként kitörölgetni? Vagy pont layereket akarsz generálni az effektekből? Ha nem rendelkezel gépsoron dolgozó emberek monotonítástűrő képességével, akkor ez a bővítmény kell neked.

[Letöltöm](http://madebyvadim.com/layrs/?ref=blog.fps.hu)

### Cut&Slice me

![Cut&Slice me képernyőkép](https://blog.fps.hu/content/images/2015/12/tompost_7.jpg)

Mobilról desktopra. Babra munka, de ezt is meg kell csinálni. Hoverestül, méretestül, ikonostul, mindenestül. Gyakran találkozol ezzel a folyamattal? Szerintem csak nézd meg [ezt a videót](http://www.youtube.com/watch?v=bwEVPQ79Ayg&ref=blog.fps.hu) és még a vége előtt telepíteni fogod.

[Letöltöm](http://www.cutandslice.me/?ref=blog.fps.hu)

### WebINK

![Extensis WebINK](https://blog.fps.hu/content/images/2015/12/tompost_9.jpg)

Direkt a végére hagytam. Nem kell fontokat telpíteni, amik lassítják a géped. Ehelyett megnyitod az alkalmazást, és máris válogathatsz a WebINK és a Google Web Fonts ingyenes fontjai közül. Később, amikor már a site build következik, akkor csak a WebINK vagy a Google Fonts oldaláról a használt font CSS kódja könnyen kimásolható és… A többiről kérdezd a fejlesztőinket. ;)

[Letöltöm](http://www.webink.com/webfontplugin/?ref=blog.fps.hu)

**Kihagytam a kedvenced? Kommenteld!**
### Szükséged van mobil tartalom stratégiára?
URL: https://blog.fps.hu/szukseged-van-mobil-tartalom-strategiara/
Last updated: 2026-07-17T08:43:05.000Z
Tisztában vagy vele, a weboldalad forgalmának hány százaléka érkezik valamilyen mobil eszközről? És arról van-e információd, mennyi konverzió érkezik ezen eszközökről? Ha mindkét kérdésre fejből tudod a választ, akkor is olvass tovább, hidd el, megéri.

Az okostelefonok, tabletek mindennapi életünk nélkülözhetetlen eszközévé váltak. Átalakították a tartalomfogyasztási szokásokat is, mivel általuk hely- és időfüggetlenné vált az internethasználat.

A weboldalakat napról napra többen keresik fel mobil eszközökről, 2014-ben már a teljes forgalom átlagosan 5-15%-át teszi ki a mobilos forgalom. Ha már működik mobilra optimalizált verzió is, ez a szám jóval magasabb, elérheti, sőt néhány esetben meg is haladhatja az 50%-ot. Az oldalad tartalom struktúrája követi ezeket a trendeket?

![Google Analytics – tablet 44,76%, desktop 33,03%, mobile 22,21%](https://blog.fps.hu/content/images/2016/01/statisztika.jpg)

### A konverzió mindenek felett

Minden weboldalnak van valamilyen konverziós célja, ami miatt létrejön. Ez gyakorlatilag bármi lehet: információközlés, tudás átadás, értékesítés, kapcsolatfelvétel, stb.. A weboldal tervezése, készítése, majd üzemeltetése során MINDIG azt kell szem előtt tartani, hogy a felhasználók sikeresen véghezvigyék a konverziót. Függetlenül attól, milyen eszközről, böngészőből, stb. érkeznek a látogatók. És itt jön elő a tartalom stratégia. (Ha most hallod ezt a kifejezést először, olvasd el [korábban írt posztomat](https://blog.fps.hu/tartalom-strategia-content-strategy/) a témában.) Úgy kell kialakítani a tartalom struktúrát, hogy a felhasználók - akár több lépésen keresztül is – könnyen célba jussanak, azaz konvertáljanak.

### A mobil nem csak egy eszköz

A mobilra ne úgy tekints, mint bizonyos hordozható eszközök csoportjára, hanem egy csatornára, amelyből a felhasználóid egy része érkezik. Az igaz, hogy ezekre az eszközökre optimalizálni kell a tartalmi megjelenést, de attól még ez egy külön csatorna, ahol a felhasználók egy jól körülhatárolható viselkedésformát követnek.

Ahhoz, hogy megismerd ezt a viselkedésformát, alaposan meg kell vizsgálni a célcsoportot. Ha újonnan induló oldalról van szó, érdemes utánanézni, készültek-e kutatások az adott területen, ha nem, mindenképp érdemes csinálni vagy csináltatni. Igaz, hogy mindez idő és pénz, de üzleti szempontból mindenképp kifizetődő, mert rengeteg időt és költséget lehet vele spórolni a későbbi tervezési és fejlesztési feladatokból.

Ha már meglévő oldalról van szó, akkor az analitikai adatokba kell beleásnod magad (vagy megbízol egy szakértőt, aki részletes elemzést készít számodra). Külön kell megvizsgálni a desktopos, és a mobilos forgalmat, viselkedést, majd összevetni a kettőt. Szépen ki fognak rajzolódni a hasonlóságok és a különbözőségek. A különbözőségeket több szempontból is elemezni kell: milyen lépéseket kell tenni annak érdekében, hogy mindkét csatornából érkező látogatók igényeit maximálisan ki tudd szolgálni. Itt fog eldőlni, milyen technológiai megoldás lesz az ideális számodra: responsive weboldal, külön szeparált mobil oldal, mobil app, stb..

### Lépj időben, mielőtt késő nem lesz

Ha folyamatosan növekszik a mobilos forgalmad, de nincs megfelelő felületed a kiszolgálásukra, minél hamarabb lépned kell, különben könnyen elveszítheted őket. A versenytársak sem ülnek a babérjaikon, aki leggyorsabban lép, az előnyhöz juthat a többiekkel szemben. Légy te az első!

### Tervezz, tesztelj, módosíts

Amikor egy már meglévő oldalt átalakítanak reszponzívra, legtöbbször annyi történik, hogy a megjelenést az eszközöknek megfelelően alakítják ki. Elkészül az oldal, jönnek a mobilos felhasználók, szépen megjelenik a tartalom, örülünk. De arra ritkán kerül sor, hogy néhány hét, pár hónap múlva újra megtörténjen az analitikai elemzés, amiből feketén-fehéren kiderül: jól működik a mobil csatorna konverziója vagy sem.

Mindig az üzleti célokat kell szem előtt tartani. Ha az adatok azt mutatják, hogy nem működik a mobil csatorna, ki kell kiderítened az okokat. Ha ezek kisebb tartalmi módosításokkal, átalakításokkal megszüntethetőek, tedd meg. Akár A/B teszttel, akár másféle tesztelési módszerrel ellenőrizd az eredményességet. Ha így sem sikerül kiküszöbölni a problémákat, jön a kérdés: hogyan tovább? Ez már stratégiai döntést követel. Mérlegelni kell a lehetőségeket, meg kell minden aspektusból vizsgálni a történetet és dönteni.

![Mobiltól desktopig illusztráció](https://blog.fps.hu/content/images/2016/01/mobile-desktop.jpg)

### Milyen a jó mobil stratégia?

**Kövesd a mobile first elvet.** A design tekintetében már egészen jól működik ez a gondolkodásmód. Tartalom tekintetében azonban még nagyon kevesen gondolkodnak mobilban. A mobil keresések száma lassan eléri a desktop felületről indított keresések számát. Ma már az nem elég, hogy kisebb bekezdésekre tördeljük a szöveget, hogy jobban nézzen ki mobilon. Át kell gondolni, mit és hogyan „tálaljunk” a mobilos felhasználóknak. Tartalom esetén is igaz: ami maximálisan kiszolgálja a mobilos felhasználókat, az a desktop felhasználóknak is megfelelő lesz.

**Rövid kontra hosszú tartalom:** Az eddigi adatok és tapasztalatok azt mutatják, hogy jól működnek a hosszabb tartalmak is mobilon. Ennek több oka van: egyrészt a hosszabb tartalom minőséget is jelent a látogatók számára, mellyel értéket is teremtünk. Másrészt keresőoptimalizálás szempontjából is értékesebb a hosszabb tartalom (különösen a Google Kolibri megjelenése óta, amely a tartalmi kontextusra helyezi a hangsúlyt). Viszont SEO szempontból az is fontos mérőszám, hogy hányan olvasták végig az adott tartalmat, mivel ez is egy rangsorolási faktor. Akkor mégis a rövid szöveg a jobb, mert nagyobb eséllyel olvassák végig? Ez nagyban függ a célcsoporttól. Ezért (is) kell jól ismerni őket.

**Ismerd meg a mobil felhasználóid szokásait, viselkedését:** Minél jobban ismered a látogatói szokásokat, annál jobb tartalmat tudsz adni számukra. Vajon az alábbi kérdések mindegyikére tudsz válaszolni?

- Az összes látogatód közül hányan használják az oldalad mobil eszközről?
- Akik használják, okostelefonról vagy táblagépről használják inkább?
- Milyen tevékenységeket végeznek az oldalon mobil eszközről? És desktopon?
- Milyen tartalmakat használnak?
- Mennyi időt töltenek átlagosan az oldalon?
- Fogyasztanak vizuális tartalmat is?
- Milyen más oldalakat használnak még mobilról? (pl. social media)

**Fókuszálj a címekre:** használj olyan főcímeket, amelyek megragadják a látogatók figyelmét, felkeltik az érdeklődését, és cselekvésre ösztönzik őket. Ez mobilon kiemelten fontos, mivel gyakorlatilag a cím alapján döntik el, tovább olvasnak-e vagy sem.

**Figyelj a bevezető szövegekre is:** az első két-három mondat után dől el, folytatja-e a látogató az olvasást. Hosszabb tartalmak esetében (ami több mint 2000 szó) érdemes használni mobil felületeken a kivonatolást (hanganyagok esetében ezek a podcastek). Ha ezek alapján továbbra is érdekes a tartalom a felhasználónak, ott a lehetőség a teljes tartalom megtekintésére/meghallgatására.

**Figyelj a formázásra:** a desktopos tartalom újratördelése még nem elég. Ha azt akarod, hogy vonzó és kívánatos legyen a további olvasásra a tartalmad, az alábbiakat fontold meg:

- a lead szövegben foglald össze röviden, miről szól a tartalom és miért érdemes végignézni
- a tappolható részeket (szavak, kifejezések, szövegrészek stb.) egyértelműen jelezd
- nagyobb betűméretet használj a jobb olvashatóság érdekében
- használj vizuális elemeket, de csak mértékkel
- a szöveg elrendezés tiszta, áttekinthető és egyértelmű legyen

**Fogalmazz a célközönséged nyelvén:** van egy régi szövegírási irányelv az újságírók között, amely így hangzik: mindig úgy fogalmazz, hogy egy nyolcadik osztályos is megértse. Ezt én úgy fordítanám a webes tartalom előállításra, hogy úgy fogalmazz, ahogy a célközönséged beszél. Fogalmazz egyszerűen, érthetően, olyan szakszavakat használj, amit vagy ők is megértenek, vagy magyarázd meg, mi mit jelent. Például ha a vízvezeték szerelők a célcsoportod, ne fogalmazz úgy, mintha jogászokhoz szólnál.

![kép, videó, infografika ikonok](https://blog.fps.hu/content/images/2015/12/2-2.jpg)

**Használj vizuális tartalmakat:** a képek, videók, infografikák egyre fontosabb tartalommá váltak. A mobil tartalom stratégiába tökéletesen beleillenek, érdemes tesztelni, melyik működik a legjobban. Videók esetében érdemes kipróbálni az ún. mikro videókat. (pl. Vine videók)

### Most már tudod a választ: szükséged van mobil tartalom stratégiára?

Ha eddig elolvastad a posztot, már biztosan tudod, szükséged van-e rá. Ha nálad minden flottul működik mobilon is, és teljesíti az oldalad a kitűzött konverziós célokat, akkor neked már van egy jól működő mobil tartalom stratégiád. Viszont ekkor sem szabad kényelmesen hátradőlnöd, hogy akkor minden rendben, időről-időre át kell nézni az analitikai adatokat, hogy lásd, továbbra is jól haladnak-e a dolgok.

Minden más esetben szükséged lehet mobil tartalom stratégiára. Nézz rá az analitikai adataidra még ma, mert lehet, hogy már régen aktuális lenne lépni mobil ügyben. Gondold át a fentieket, mielőtt belevágsz, legyen egy jól megfontolt, megtervezett mobil tartalom stratégiád, így nemcsak időt, de költséget is spórolhatsz.
### Visszajelzésfüggők vagyunk
URL: https://blog.fps.hu/visszajelzes-feedback-ui/
Last updated: 2026-07-17T08:43:15.000Z
Te is, én is, mindenki. Ha interakcióba lépsz bármivel, vagy bárkivel, akkor az agyadnak szüksége van valamilyen visszajelzésre ahhoz, hogy úgy érezd ténylegesen megtetted azt. Az öt érzékszerved valamelyikén keresztül feltétlen szükség van egy inputra, minél hamarabb, annál jobb.

Ha nem kapsz vissza jelet, akkor gyorsan kényelmetlenül érzed magad, vagy egyszerűen azt gondolod, hogy nem működik, nem hatásos, nem jó, hibás az eszköz, vagy ha egy humanoidról van szó, akkor nem érdekled, nem vagy számára fontos. A visszajelzés csökkenti a stresszt, a bizonytalanságot. Evidens ez, mégis megfeledkezünk róla. (amúgy ez egy feljegyzés magamnak is)

### Hétköznapi példák

A samponok habzanak, mert olyan vegyi anyagokat kevernek bele, hogy hajmosás közben habozzon. Ennek semmi előnye nincs, nincs szükség az anyagra a tisztítás szempontjából, de neked nagyonis, mert onnan tudod, hogy megtisztult a hajad. Ugyanígy igaz ez a fogkrémre is, amiben a habzó anyagokon túl hűvös és bizsergető érzést keltő vegyi anyagokat is kevernek. Amint ezt érzed és látod a habot a szádban, tudod, tiszta lett a fogad.

![üzenetek típusai egy mobil képernyőjén](https://blog.fps.hu/content/images/2015/12/140324_blog2.jpg)

### Alkalmazások

A digitális eszközöknek és az azokon futó szoftvereknek szintén visszajelzést kell adniuk a felhasználónak, ha azok valamilyen interakciót kezdeményeztek. Mennyi időn belül kapnak visszajelzést? Nos, ez az idő meghatározza meg az alkalmazás sebességérzetét (is). Nem kell magyarázni mennyire fontos, hogy az emberek gyorsnak érezzék a programodat.

Tipikus probléma egy űrlap elküldő gombja, amire kattintva nem történik semmi. Nem küldtem el? Mellékattintottam? Mellétappoltam? A felhasználó azonnal kattint, tappol legalább 42-szer, hogy biztos legyen az eredmény. Különösen igaz ez az érintőképernyős eszközök világában, ahol még kevesebb visszajelzést kapunk. Ha várni kell valami időigényes feladat elvégzésére, akkor azt inkább csináld a háttérben, viszont a felületen rögtön mutasd, hogy kész van. Jellegzetes még, amikor a felhasználó elvégzett egy feladatot és arról nem kap megerősítést.

Néhány példa, milyen lehetőségeid vannak alkalmazások esetén:

- Üzenetek (hiba, sikeres, figyelmezető)
- Felugró ablak üzenet
- Szín, forma változása
- Egér kurzorának változása
- Folyamatjelző sávok, ikonok (progress bar, loader…)
- Hangok

![Facebook értesítés képernyőkép](https://blog.fps.hu/content/images/2015/12/140324_blog1.jpg)

### Emberek

Emberek hétköznapjaiban is lényeges a visszajelzés. Rendszeresen elfelejtünk egymásnak visszajelzést adni arról, hogy jól, vagy rosszul végezte el a másik a feladatát. Pedig óriási szükségünk van rá. Nem tudjuk, hányadán állunk a másikkal. Ha nem mondod, nem tudhatom, hogy rosszul csináltam. Egyszerű, nem? Most mondd a párodnak, hogy szereted! ;) Másik a munkánkat érintő jellemző hiányosság, mikor kapsz egy emailt és arra nem válaszolsz, csak megjelölöd későbbre. A küldő így semmiféle visszajelzést sem kap és teljes bizonytalanságban ül és nem tudja mi a helyzet. Egyszerűen dobj vissza egy mailt, hogy köszönöm, megkaptam, hamarosan foglalkozom vele és mindenki boldog lesz.

*Update 2014.05.05.*

Az alábbi videót be kellett szúrnom ide, mert zseniálisan szemlélteti, hogy mennyire visszajelzésfüggő az agyunk és teljesen szétcsúszik a rendszer, ha időben elcsúsznak a dolgok :)
### 10 php osztály, ami még hasznos lehet
URL: https://blog.fps.hu/hasznos-php-osztalyok/
Last updated: 2026-07-17T08:43:28.000Z
Ha saját vagy open source framework-öt használsz, általában fel van készítve a legtöbb probléma kezelésére (felhasználó- és adatbáziskezelés, routing, email küldés, stb). Ám sokszor adódhat olyan eset, hogy ezen funkciók valamelyike hiányzik, vagy csak egy kisebb projekthez van szükséged már kész megoldásokra, esetleg a saját keretrendszered hegeszted. Remélem, találsz hasznos vagy új dolgokat az alábbi listában.

### 01\. Medoo

A medoo egy roppant kis méretű (\~10k) SQL adatbázisokkal való munkát megkönnyítő osztály. Automatikusan véd az SQL injection ellen, nagyon könnyen használható és jól dokumentált. Támogatja többek között a MySQL, MSSQL, SQLite, MariaDB adatbázismotorokat.

[Megnézem](http://medoo.in/?ref=blog.fps.hu)

### 02\. Simple router

Egyszerű és jól működő router a “szép-url-ek” lekezelésére. Támogatja a GET, POST, PUT, DELETE, OPTIONS, PATCH és HEAD request metódusokat. Az előre meghatározott sémák mellett kezeli a regexp patterneket is. A demót kipróbálva mindenre fény derül, nekem remekül bevált.

[Megnézem](https://github.com/bramus/router?ref=blog.fps.hu)

### 03\. Xajax

Hatékony megoldás az ajax hívások tisztán php szintű lekezelésére. Nem kell külön a JS szkript megírásával töltened az időt, mindent megold helyetted. A működését egyszerűen szemlélteti az oldalán található példakód.

[Megnézem](http://www.xajax-project.org/?ref=blog.fps.hu)

### 04\. Mobile detect

Szerver oldali script, amivel megtudhatod, hogy a felhasználó milyen eszközön nézi oldaladat (mobil, tablet, desktop). A RESS technológia (Responsive Webdesign + Server Side Components) elengedhetetlen kelléke. Mi is ezt használjuk.

[Megnézem](http://mobiledetect.net/?ref=blog.fps.hu)

### 05\. Util.php

A util.php függyvénytár olyan hasznos funkciók gyűjteménye, amikre bármikor szükség lehet és van is. Több, mint 35 függvényt és snippetet tartalmaz, amelyek megkönnyítik a fejlesztést és a tömbökkel való munkát, a stringek manipulálását vagy az url-ek feldolgozását. Minden funkció részletes leírása megtalálható az oldalán, érdemes átfutni.

[Megnézem](http://brandonwamboldt.github.io/utilphp/?ref=blog.fps.hu)

### 06\. Php mailer

Talán az egyik legtöbbet alkalmazott email küldő osztály. Megkönnyíti az email header és tartalom összeállítását és küldését SMTP vagy a php mail függvényének használatával. Könnyen használható, nem kell bajlódni a csatolmányokkal és beillesztett képekkel.

[Megnézem](https://github.com/PHPMailer/PHPMailer?ref=blog.fps.hu)

### 07\. TCPDF

Pdf fájl generálása php kóddal sosem volt egyszerű. Ezután sem lesz az, mert midig macerás minden elemet tökéletesen bepozicionálni a helyére, de legalább a többi résszel nem kell foglalkoznod, mert a TCPDF osztály megoldja helyetted.

[Megnézem](http://sourceforge.net/projects/tcpdf/?ref=blog.fps.hu)

### 08\. Wideimage

GD alapú, a képmanipulálást megvalósító osztály. Személy szerint azért szeretem, mert nagyon egyszerűen tudok vele méretezni, kivágni és minden alapvető effektet ráerőltetni a feltöltött képekre. Biztosan akad még sok ilyen jellegű oszrály, és ezt már nem is frissítik, de kiválóan ellátja a feladatát.

[Megnézem](http://wideimage.sourceforge.net/?ref=blog.fps.hu)

### 09\. Phperror

Fejlesztés során (és szigorúan csak ebben a periódusban) rendkívül hasznos lehet, ha minél bővebb reportot kapunk a hiba okáról és helyéről. A phperror osztály használatával részletes képet és backtrace információkat kapunk a hibáról, ráadásul kellemes megjelenésben.

[Megnézem](http://phperror.net/?ref=blog.fps.hu)

### 10\. hybridAuth

Ha a felhasználóknak lehetőséget szeretnénk adni, hogy Facebook, Twitter vagy Google fiókjuk használatával azonosítsák magukat, akkor ideális választás a hybridAuth osztály. Az azonosításon túl lehetőségünk van (persze csak a megfelelő engedélyek megszerzése után) a felhasználó nevében megosztani, állapotfrissítést küldeni, ismerősök listájához hozzáférni és egyéb dolgokra is. Van benne mySpace connect is. Vajon valaki kihasználja? :)

[Megnézem](http://hybridauth.sourceforge.net/?ref=blog.fps.hu)

**Tudsz más hasznos PHP osztályt? Oszd meg velünk és mindenkivel komment formájában!**
### Öt miért, miért?
URL: https://blog.fps.hu/ot-miert-5-whys-modszer/
Last updated: 2026-07-17T08:43:39.000Z
Létezik egy nagyon jó módszertan, melyet még valamikor a századelőn ötlött ki Sakichi Toyoda, a Toyota alapítója. Remélhetőleg találkoztál már a 5 Whys módszertannal, melyet végül Taiichi Ohno vezetett be a Toyotánál és tett a vállalat alapvető tudományos szemléletévé.

A 5W egy nagyszerű eszköz problémamegoldásra. Alkalmazásával a probléma valódi gyökerét lehet megtalálni, szimplán úgy, hogy legfeljebb öt miérttel kezdődő kérdést teszel fel a problémával kapcsolatban és az esetek 99%-ában az ötödik miért kérdésre adott válasz felfedi a probléma valódi, mélyen gyökerező okát. A [magyar Wikipedian is találsz példát](http://hu.wikipedia.org/wiki/5W?ref=blog.fps.hu) erre, melyet itt most nem ismétlek meg.

A módszertan a tervezés során is hasznos eszköz lehet a kezedben, sőt azért írom a posztot, hogy a használatára ösztönözzelek. Van egy saját termék, szolgáltatás ötleted? Ügyfeled, partnered jelentkezik nálad az ötletével? Vesd be az eszközt. Miért is? Egyrészt megérted (és az ügyfeled) is megérti valójában milyen emberi érzelemhez kötődik a terméke, szolgáltatása. Ugyanis annyiszor kell feltenni a miért kérdést, amíg a válaszban eljutsz egy érzelemig. Tudnod kell, hogy a termék, szolgáltatás valójában miért és milyen problémára ad megoldást. Az eredmény sokszor meglepetést okoz az ötlet gazdájának is. Mutatok egy példát, hogy érthetőbb legyen.

Adott egy site, mondjuk az [izeselet.hu](http://izeselet.hu/?ref=blog.fps.hu), ami egy gasztrobarangoló oldal, ami főként recepteket tartalmaz. Lássuk a hipotetikus kérdéseket.

**1\. Miért menjek az ízesélet.hu-ra?**  
Mert egy jó gasztro oldal, ahol sok recept van.

**2\. Miért van szükséged receptekre?**  
Mert mindig valami újat kell főznöm.

**3\. Miért kell mindig újat főznöd?**  
Mert szeretném, ha változatosan étkeznénk és ízletes ételeket ennénk.

**4\. Miért kell ízletes ételeket főzni?**  
Mert örömet akarok okozni a szeretteimnek és persze magamnak.

Hoppá! Itt már négy kérdésből eljutottunk egy fontos ponthoz: *örömet okozni a szeretteinek*. Egészen más megvilágításba kerül a termék, nyomban segítséget ad a szöveges tartalomhoz, a grafikához stb.

A megfelelő kérdésfeltétel kulcsfontosságú, mert könnyen el lehet térni az eredeti problémától, ezért kínosan kell ügyelni arra, hogy a kérdés a témához kapcsolódjon, ha kell kanyarodjon vissza és feltétlen a válaszra reflektáljon. Nyilván ez a módszertan is igazából a termék, szolgáltatás felhasználóit megkérdezve a leghasznosabb. Csak a felhasználó szükségletének pontos megértésével lehet jó terméket tervezni.

Érzelmeket kell tervezni, mégpedig olyan érzelmeket, melyekről azt akarod, hogy a látogatók érezzék. Így is kialakíthatsz érzelmi kötődést a termékeddel, szolgáltatásoddal kapcsolatban. Ne termékeket, érzelmeket és/vagy hitet árulj.
### fps
URL: https://blog.fps.hu/fps-alkotas-es-elmeny-tisztelet/
Last updated: 2026-07-17T08:43:49.000Z
Miért választja valaki az fps-t? Sok hasonló cég van a világban, de azt is tudjuk, hogy [digitális szimbiózisra](https://blog.fps.hu/digitalis-projektek-partnerseg-szimbiozis/) van szükség. Szavakba öntjük hitünket, hogy a hasonló emberek megtaláljanak minket, hogy egymás és a felhasználók örömére legyünk.

### Alkotás és élmény

Minden helyzetben az a célunk, hogy jót csináljunk. A tökéletes megalkotására törekszünk, és pontosan tudjuk, hogy csak azok képesek kiemelkedőt teremteni, akik szeretik, élvezik azt, amit csinálnak. **Mi játszani akarunk, élvezni akarjuk a munkánkat, mi teremteni, alkotni akarunk,** még a legszürkébb hétköznapon is, akkor is, ha sokszor nem sikerül. De sebaj! Biztosak vagyunk benne, hogy a következő sikeres lesz!

![TISZTELET felirat](https://blog.fps.hu/content/images/2016/01/tisztelet.jpg)

### Tisztelet

Igen, a tisztelet. Mindennek az alapja.

1. **Tiszteljük csapattársainkat, kollégáinkat.** Bízunk egymás személyében, tudásában, szakértelmében és segítjük a másikat, ha szüksége van rá és tiszteljük azt, ha valaki kérdezni mer. Tudjuk hogy számíthatunk egymásra és hogy csakis együtt, csapatban tudunk nagyszerűt kreálni.
2. **Tiszteljük a partnereket, ügyfeleket.** Azzal fejezzük ki tiszteletünket, hogy együttműködünk, hogy kommunikálunk, hogy betartjuk a határidőket. Megtiszteljük őket véleményünkkel, és tudásunkkal, még akkor is, ha ez ellenkezik az övékkel. Egyébként hogy is várhatnánk el, hogy bízzanak bennünk, ha mi nem ezt tesszük?
3. **Tiszteljük a felhasználókat.** Hiszünk benne, hogy őket kell igazán boldoggá tenni. Végülis a létrehozott termékeket ők fogják használni, nem? Megtiszteljük őket figyelmünkkel, és alázatunkkal. Ha ők boldogok, akkor a partnerünk, ügyfelünk is boldog lesz, és ezáltal mi magunk is.

#### A mottónk is kifejezi a fent leírtakat:

> Ember-központú mobil, web tervezés és fejlesztés.

### Mindezt miért?

Miért van, mi célból létezik az fps? Egyszerű. Hiszünk abban, hogy **munkánkkal az emberek életét könnyítjük meg** úgy, hogy olyan termékeket adunk a kezükbe, melyek **növelik elégedettségüket és csökkentik mindennapi frusztrációjukat**. Így tesszük jobbá a világot.
### Klasszikus programozó reakciók
URL: https://blog.fps.hu/programozo-fejleszto-reakciok-valaszok/
Last updated: 2026-07-17T08:43:59.000Z
Nincs tökéletes program, ezt mindenki tudja, illetve Murphy törvénye is kimondja: ha egy program módosítása beválik, akkor valószínűleg nem arra a módosításra volt szükség. Ha hiba van, nincs mit tenni, mint odasétálni a programozóhoz, fejlesztőhöz, vagy egyéb úton jelezni felé a problémát.

A programozók első reakciói legendássá váltak és csakhamar kialakultak aranyköpések, melyekből szemezgettünk, hogy legyen min derülni. Sok helyen elérhető a neten mindenféle lista, ezekből állítottuk össze az általunk is ismert és nagyra tartott mondatokat. ;)

Álljon itt a szerintünk 15 leggyakoribb válasz, amit a programozó mond, ha nem működik a kódja…

![15 leggyakoribb válasz, amit a programozó mond, ha nem működik a kódja](https://blog.fps.hu/content/images/2015/12/15-programozo-valasz-fps.jpg)

1. Nálam működik.
2. Ez a verzió pont nem kompatibilis a rendszereddel.
3. Nem lehet, hogy vírusos a géped?!
4. Valaki biztos belepiszkált a kódomba.
5. Tuti, hogy működik, csak még nem lett letesztelve.
6. Ez nem is az a forráskód?!
7. Nem tesztelhetek mindent!
8. Ez csak valami szerencsétlen véletlen lehet.
9. Biztosan rossz verziót használsz.
10. Ehhez a modulhoz hetek óta hozzá sem nyúltam!
11. Tuti hardver hiba!
12. Ez meg hogy lehet?
13. Tegnap még működött.
14. Sosem csinált ilyet előtte.
15. Hát ez fura…  
(+1) Frissíts!
### Horrorli
URL: https://blog.fps.hu/horrorli-hatterzaj-generator/
Last updated: 2026-07-17T08:44:09.000Z
A [noisli](http://www.noisli.com/?ref=blog.fps.hu) ihlette oldalon, horror filmek hangeffektjeit használhatod saját ijesztgetésed háttérzajaként, vagy csak hogy játssz kollégáid, ismerőseid idegeivel. Otthon. Este. Egyedül az igazi, de azt csak kivételesen bátraknak ajánljuk. 14 különböző önmagában is hátborzongató zajt kapcsolgatva és hangerejük egyedi keverésével állíthatod elő a számodra legborzasztóbbat. Vigyázat addiktív!

**[Készen állsz, kipróbálod MOST!](http://horrorli.fps.hu/?ref=blog.fps.hu "horrorli")**

Mi komolyan vesszük a tervezést, a kivitelezést és a tesztelést is; UAT003 - accepted! A valósággal való egyezés a véletlen műve.

[![horrorli képregény](https://blog.fps.hu/content/images/2016/01/horrorli-comic.jpg)](http://horrorli.fps.hu/?ref=blog.fps.hu "horrorli")
### Guest blogging: hasznos vagy káros?
URL: https://blog.fps.hu/guest-blogging/
Last updated: 2026-07-17T08:44:20.000Z
Néhány napja futótűzként terjedt online marketinges berkekben az a hír, mely szerint a guest blogging (vendégblogolás) halott. Gondolom, nagy valószínűséggel most hallasz erről először, és fogalmad sincs, miről van szó. Összefoglalom röviden, miről is szól a guest blogging és miért beszélnek máris a haláláról.

A guest blogging vagy vendégblogolás azt jelenti, hogy egy-egy blogger egy másik bloghoz ír vendégposztot. Miért jó ez neki? Mert visszahivatkozik az eredeti blogra, így egy linkkapcsolat jön létre, amely ha megfelelő minőségű, azaz tartalmilag releváns egymáshoz, akkor segíti a keresőoptimalizálást. Másrészt ha egy kevésbé nagy látogatottságú blog írója posztol egy népszerű blogba, népszerűséget és forgalmat is tud generálni a blogjára.

### Miért hasznos a guest blogging?

- a guest blogginggal kapcsolatot építhetsz más bloggerekkel
- segítheted a keresőoptimalizálást
- segítségével bemutatkozhatsz eddig ismeretlen csoportok előtt is (akár a blogon, akár a bloghoz kapcsolódó social media csatornákon keresztül)

Tehát a vendégblogolás az online marketing eszköztár egyik viszonylag jól működő eszköze, ha okosan és bizonyos dolgokat figyelembe véve csinálják. Azaz:

- értékes, minőségi tartalmat írsz
- nem tömködöd tele kifelé mutató linkekkel
- olyan blogba adj tartalmat, amely szintén egyedi, minőségi posztokat tartalmaz és a posztok nagy része a blog tulajdonosának saját írásai

### Miért halott a guest blogging?

Mint nagyon sok mindenben, sokaknak itt is sikerült átesni a ló másik oldalára. Elkezdtek silány minőségű, sokszor duplikált tartalmú posztokat gyártani, teletömködve mindenféle linkekkel és kulcsszavakkal, amelyekkel teleszemetelték a webet. A guest blogging azonban NEM egy linképítési eszköz. Sokan a linképítési stratégia részeként tekintenek rá, és emiatt született [Matt Cutts posztja](http://www.mattcutts.com/blog/guest-blogging/?ref=blog.fps.hu) a guest blogging haláláról. Matt Cutts a Google webspam elleni csapatának a vezetője, akit sokan áldanak (azok a szakemberek, akik a tiszta játékszabályokat szeretik) és sokan átkoznak (akik szeretik a kiskapukat kijátszani és nem megengedett eszközöket használni). Többek között neki és csapatának köszönhetjük a Google állatait is, a Pandát, a Pingvint és a Kolibrit.

A Google felismerte ezeket a trükközéseket, és erre reagálva Matt Cutts posztjában felhívta a figyelmet arra, hogy az egyértelműen SEO szempontból íródott posztok ellen keményen fel fognak lépni. Az eddigi Google állatoknak is az a céljuk, hogy büntessék a spamet és megfelelően rangsorolják a minőségi tartalmakat. Ez alól a blogok sem kivételek.

[![Guest Blogging diagram](https://blog.fps.hu/content/images/2015/12/bemyguest.jpg)](http://www.pinterest.com/pin/119838040058688471/?ref=blog.fps.hu "Mi a vendégblogolás - infografika")

### Nem kell félni

Természetesen akik megfelelően használják a vendégblogolást, nincs mitől félniük, a szigorú fellépés itt is a spam tartalom „büntetéséről” szól. Nem kell törölni, illetve töröltetni a vendég posztokat, ha azok tartalmilag és minőségileg rendben vannak. Ha pedig van ilyen jellegű poszt a blogodban, vagy netalántán te írtál ilyen jellegű posztokat, még nem késő eltávolítani, mielőtt komolyabb büntetést ró ki rád Google barátunk. A guest blogging tehát nem halott, de kiemelt figyelmet fordít rá a Google.

### Új eszköz a minőségi tartalom igazolásához: Google Authorship

Néhány hónappal ezelőtt vezette be a [Google Authorship](http://www.google.com/insidesearch/features/authorship/?ref=blog.fps.hu#getstarted) (szerzőség) funkciót, amely lehetőséget biztosít arra, hogy a Google által is elismert szerző váljon belőled. Azzal, hogy a Google+ fiókodat összekapcsolod az általad írt tartalommal, a kereső és a felhasználók felé is hitelesen tudod igazolni magad, mellyel bizalmat tudsz építeni, illetve szakértői képet is fel tudsz építeni magadról. Arra figyelj, hogy hosszú távon is minőségi tartalmat állíts elő, így elismert íróvá, bloggerré válhatsz, amely sokat segíthet a tartalmaid rangsorolásában is.

### Quality content forever

Ha mindig minőségi tartalmat adsz ki a kezeid közül, változhat akárhogyan is a Google keresési algoritmusa, akkor sem lesz mitől tartanod. Matt Cutts és csapata mindent el fog a jövőben is követni a spam tartalmak visszaszorítása érdekében, ebben biztos lehetsz.
### Pókember ahol tud segít!
URL: https://blog.fps.hu/pokember-ahol-tud-segit/
Last updated: 2026-07-17T08:44:31.000Z
Férfiként elég sokszor találkozom a mellékhelyiségben azzal a problémával, hogy a WC ülőke nem hajtható fel biztonságosan – rosszul van felszerelve, vagy kicsi a hely – és az ülőke rész folyton visszazuhan.

Kellemetlen mindez, ha az ember már elkezdte a dolgát, hisz nem történik más, mint mikor egy pingpong ütővel a vízsugárba csapunk.

Tapasztalt férfi társaim felszisszenek, de ugyanígy a nők is, hiszen végül is azt az ülőkét ők többször illetik szabad bőr felülettel, mint mi.

Persze ez a probléma néhány erősen domesztikált nem-társunkat nem érinti, őket már ülve pisilésre szoktatták. Mi, viszont – gyanítom többségben – nadrág szárunkon hordozzuk ezen élmények nyomát.

Aki nem vesződik az ülőke felhajtásával, attól elnézést kérek, hogy raboltam értékes idejét, viszont nem szeretnék ebbe a táborba tartozónak tűnni, csak azért mert akció közben rám borul az ülőke… eredményét tekintve ugyanis nagyon hasonló a két szituáció, pisi mindenütt!

A kis applikáció azoktól nem véd akik eleve nem a felhajtósok, bár megkísérlem picit azok is elgondolkoznak, talán még játszanak is vele mielőtt levizelik az ülőkét!

Nem kell hozzá sok, nem is magyarázom túl, a mechanikus ülőkeledőlésgátlómat :)

**Használjátok egészséggel!**

Csak a két oldalas ragasztó az, ami nincs feltétlenül minden háztartásban, a többi biztosan megtalálható mindenhol.

**1\. Szedd össze**: használt ceruza elem (AA vagy AAA), grafit cerka, színes filctollak (piros, kék), olló, papír, madzag.

![használt ceruza elem (AA vagy AAA), grafit cerka, színes filctollak (piros, kék), olló, papír, madzag](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040pyi4Es1r105v8.jpg)

**2\. Rajzold elő!**

![papírra skiccelve a pókember figura](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040qjH0kB1r105v8.jpg)

**3\. Vágd ki!**

![pókember figura kivágva a papírból](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040r0RvxF1r105v8.jpg)

**4\. Színezd!**

![pókember figura kékre és pirosra színezve filccel](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040rgzE5g1r105v8.jpg)

**5\. Ragaszd hozzá!**

![elem a madzaghoz ragasztva](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040rsQWOZ1r105v8.jpg)

**6\. Ragaszd hozzá!**

![a pókemberfigura az elemre ragasztva](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040saCVkJ1r105v8-1.jpg)

**7\. Ragaszd hozzá!**

![a pókember figura az elem másik oldalára is felragasztva](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040sqTPhW1r105v8.jpg)

**8\. Hagyd szárazon az ülőkét! :)**

![pókember lóg a WC ülőkén](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040t99HqC1r105v8.jpg)

![pókember mászik a WC ülőkén](https://blog.fps.hu/content/images/2016/01/tumblr_inline_n040tlqqrd1r105v8--1-.jpg)
### SEO: amit meg szoktál kérdezni, és amit nem
URL: https://blog.fps.hu/seo-amit-meg-szoktal-kerdezni-es-amit-nem/
Last updated: 2026-07-17T08:44:41.000Z
Kulcsszavas legyen a domain? Hányszor szerepeljen egy kulcsszó az oldalon, hogy jól optimalizált legyen? Milyen gyakran frissüljön a tartalom? Ez a három kérdés szinte mindig elhangzik, amikor a keresőoptimalizálási feladatokról egyeztetek egy ügyféllel. Ezen kívül van még egy csokorra való kérdés, ami titekek, ügyfeleket érdekel.

[Brian Dean A Google 200 rangsorolási faktoráról szóló posztját](http://backlinko.com/google-ranking-factors?ref=blog.fps.hu) olvasgatva szinte a fülembe csengtek a fenti és a lenti kérdések, így most ezekre próbálok választ adni.

### Régi vagy új domaint használjak?

Ez a kérdés általában újonnan készülő weboldalak esetén szokott felmerülni. A domain kora régebben nagyobb hangsúlyt kapott a rangsorolásban, a mai napig benne van a faktorok között, de jelentősége csökkent. A Google figyeli ugyan a domain korát, de egy új domainnel is lehet valaki a találati lista élén.

### Kulcsszavas legyen a domain, vagy inkább a cég neve?

Itt is hasonló a helyzet, mint a domain koránál, a jelentősége csökkent, de még mindig a kulcsszó relevancia jele, ha már a domain névben visszaköszön a domináns szó vagy kifejezés. A kulcsszavas kontra cégneves domain kérdésnél egyébként azt kell mérlegelni, hosszú távon mi a célod az oldallal: brandet is szeretnél építeni, vagy csak a konverziókra fókuszálsz? Brandépítés esetén egyértelmű, hogy a cégnév vagy a brand név legyen lehetőleg a fő domain név. A kulcsszavas domain esetében arra érdemes figyelni, hogy ne legyen se túl hosszú, se túl bonyolult a név, mert egyrészt a látogatók nehezen fogják megjegyezni, másrészt a keresőben jóval kisebb eséllyel fogják az adott kulcsszavakat beírni.

### Kulcsszavas vagy kattintós oldal leírást használjak?

Ez az egyik legfogósabb kérdés, ugyanis mindkettőnek megvan az előnye és a hátránya is. A kulcsszavas description nagyon fontos keresőoptimalizálás szempontjából, mivel a keresőrobot a title után rögtön ezzel találkozik. Az itt használt kulcsszavaknak kiemelten fontos szerepe van az oldal tartalmának egészére. De ne feledkezzünk meg arról sem, hogy a description szöveg jelenik meg a Google találati oldalán is, és ezen a szövegen áll vagy bukik az átkattintás. Az én álláspontom az, hogy az oldal tartalmára vonatkozó legfontosabb kulcsszó/kulcsszavak mindenképp jelenjenek meg a leírásban, lehetőleg már az első mondatban, és próbáld meg úgy megfogalmazni azt a cirka 140 karakternyi szöveget, hogy felkeltsd az érdeklődést a tartalmad iránt. Ugye, hogy nem is olyan egyszerű?

### Hányszor forduljon elő egy kulcsszó a tartalomban?

![SEO felirat](https://blog.fps.hu/content/images/2016/01/seo.png)

Régi SEO-s mítoszok arról szóltak, hogy a teljes tartalom 6-10%-át tegye ki a kulcsszó. Ha jobban belegondolsz, ez egy kicsit durva arány, főleg, ha csak pár száz karakteres szövegről van szó. Én azt szoktam javasolni, hogy a domináns kulcsszó a lehető legtöbbször jelenjen meg, de úgy, hogy az ne menjen se a minőség, se az olvashatóság rovására. Biztosan te is találkoztál már olyan szöveggel, amiben iszonyatosan sok volt a szóismétlés, és voltak olyan nyakatekert mondatok, hogy nem is értetted, miről van szó. Lehet, hogy ezzel a fent emlegetett kulcsszó sűrűséget elérték, de a felhasználók számára élvezhetetlen és használhatatlan az ilyen tartalom. A Google azt vallja, ami jó, és amit szeretnek a felhasználók, azt ő is szereti, és ezt a rangsorolásban is díjazza. Tehát a szövegírásnál mindig a felhasználó érdekeit tartsd szem előtt és azt is, a kevesebb néha több.

### Milyen gyakran frissüljön a tartalom?

Ez az a kérdés, amire nem lehet sablon választ adni, mert mindig meg kell vizsgálni a helyzetet. Egy alapvetően statikus tartalmakkal rendelkező céges weboldal tulajdonosának nem mondhatom azt, hogy naponta töltsön fel valamilyen friss, egyedi, minőségi tartalmat. Az egyedi, minőségi, - a legújabb ajánlások szerint legalább 2000-2500 karakteres - tartalmak előállítása sok esetben nem egyszerű dolog. A keresőrobotokat gyakoribb látogatásra csábíthatod friss cikkekkel, tartalmakkal, ami mindenképpen jótékonyan hat a keresőoptimalizálásra. De hogy ne térjek ki a válasz elől, a weboldal típusa, nagysága, célközönsége, látogatottsága alapján a napi több frissítéstől a havi egy új tartalomig terjedhet.

### Mennyi kifelé mutató linket használjak?

Néhány tartalmilag releváns kifelé mutató link nagyon hasznos tud lenni keresőoptimalizálás szempontjából. Ezzel a tartalom minőségét is tudod növelni. Itt is érvényes a kevesebb néha több elv, ugyanis ha túl sok kifelé mutató link van, könnyen spamnek tekintheti a keresőrobot az oldalt.

### A helyesírás mennyire befolyásolja a keresőoptimalizálást?

Ha sok helyesírási hiba van az oldalon, közvetlenül nem befolyásolja a keresési rangsort (kivéve, ha a kulcsszó is helytelenül van leírva), viszont jelentősen rontja a felhasználói élményt. Ha tudod magadról, hogy rossz a helyesírásod, mindenképp használd a szövegszerkesztő helyesírás ellenőrzőjét, vagy kérj meg valakit, nézze át a tartalmat, mielőtt publikálod.

### A weboldal felépítése is befolyásolja a keresőoptimalizálást?

Igen. A könnyen áttekinthető, rendezett struktúrájú oldalakon már a nyitóoldalon kiderül, melyek a főbb tartalmak és a hozzá kapcsolódó kulcsszavak. Ez emeli a minőséget és a tartalmi relevanciát, amely pozitívan hat a jobb pozíció elérésére. A megfelelő belső linkelésekkel a keresőrobotok munkáját könnyítheted meg.

### Melyik a fontosabb: kifelé mutató linkek, vagy az oldalra mutató linkek?

![két egymásra mutató nyíl illusztráció](https://blog.fps.hu/content/images/2016/01/kifele_mutato_linkek-3.png)

Mindkettő egyformán fontos, és különösen érdemes odafigyelni a minőségre és a tartalmi relevanciára. Egy rosszul megválasztott linkelhelyezés (pl. egy linkfarmra felkerült link) akár kitiltáshoz is vezethet a keresési találati listából, úgyhogy csak óvatosan a linképítéssel.

### A mikroformátumok tényleg segítik a SEO-t?

A mikroformátumok használata önmagában nem segít és nem javít a találati pozíción, viszont jelentősen megnövelheti az átkattintási (CTR) arányt azzal, hogy a felhasználók számára hasznos és értékes információkat jelenít meg a találati listában. (pl. értékelés, termék ára, stb.) Korábban [egy egész posztot szenteltem a mikroformátumoknak](https://blog.fps.hu/mikroformatumok-seo/), ha érdekel, olvasd el.

### Mennyi idő múlva lesz látható a változás?

Ez attól is függ, hogy egy újonnan induló oldalról, vagy már régóta üzemelő oldalról van szó. Egy új oldal esetében a folyamat valamivel hosszabb, mivel meg kell mutatnod a keresőnek, hogy van egy ilyen site és jöhet a keresőrobot indexelni. Ha nem egy néhány oldalból álló weboldalad van, több alkalom is szükséges lehet ahhoz, hogy teljesen beindexelje a teljes tartalmat. Mivel két indexelés között napok, vagy akár hetek is eltelhetnek, így idő kell, hogy megjelenjenek az első eredmények. Tapasztalatom alapján három-négy hónap után érdemes az eredményeket figyelembe venni és szükség esetén módosítani az oldalon/tartalmon. Már régebb óta üzemelő oldal esetében ez az időtartam rövidebb, mivel már valamilyen ütemezés szerint történik az indexelés. Általánosságban elmondható, hogy minél gyakrabban frissül az oldal, annál gyakrabban jönnek a keresőrobotok is. Hírportálok esetében, ahol napi több tartalom is felkerül, akár naponta többször is megfordulhatnak a robotok.

### Summa summarum

A keresőoptimalizálás mint láthatod egy folyamatosan változó és fejlődő iparág, ahol csak az marad versenyben, aki folyamatosan nyomon követi a kereső algoritmusok változásait. **Ha kérdésed van, írd meg kommentben és szívesen válaszolok**.
### 10 dolog, ami által jobb fejlesztő leszel
URL: https://blog.fps.hu/10-dolog-ami-altal-jobb-fejleszto-leszel/
Last updated: 2026-07-17T08:44:49.000Z
Az [appdesignvaulton](http://www.appdesignvault.com/betterdeveloper/?ref=blog.fps.hu) találtunk egy zseniális listát arról, hogyan lehetsz egyre jobb és jobb fejlesztő, mit kell tenned azért. Gondoltuk magyarítjuk és formába öntjük számotokra és persze saját magunk számára is. Ha szeretnéd, le is töltheted pdf-ben és kinyomtathatod a falra, hogy folyamatosan szem előtt legyen. Mi már kinyomtuk a falra ;)

![10 dolog, ami által jobb fejlesztő leszel grafikai formában](https://blog.fps.hu/content/images/2015/12/fejleszto_tartalom.jpg)

1. Tanulmányozd mások kódjait
2. Ha teheted, nézesd át valakivel a munkád
3. Javítsd ki a bugokat, mielőtt új feladatba kezdenél
4. Tanulj és alkalmazz új technológiákat
5. Törekedj az egyszerűségre
6. Írj blog posztokat a munkádról
7. Vegyél részt open-source fejlesztésekben
8. Javítsd ki ahelyett, hogy hackelnéd!
9. Napi teszteléssel növeld a minőségi kódbázisod mennyiségét
10. Óránként tarts szünetet, relaxálj

**Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!**

[Töltsd le a posztert (0 letöltés)](https://www.fps.hu/presentations/10-dolog-ami-altal-jobb-fejleszto-leszel.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### Digitális szimbiózis
URL: https://blog.fps.hu/digitalis-projektek-partnerseg-szimbiozis/
Last updated: 2026-07-17T08:44:58.000Z
Sokan azt gondolják, hogy odamennek egy ügynökséghez, egy fejlesztő csapathoz és elkészíttetik velük a web site-ot, webshopot, portált, appot, alkalmazást, majd kifizetik, átveszik és azzal minden rendben van, itt véget is ért a projekt. A CMS-sel majd frissítik a tartalmat, esetleg az ügyviteli rendszerükkel is összeköttették az alkalmazást, tehát nincs szükség többé az ügynökségre, fejlesztőkre. Az igazság ezzel szemben az, hogy a projektnek gyakorlatilag sosincs vége, hacsak nem szűnik meg a cég, a termék, a szolgáltatás, vagy nem kerül kompletten újraépítésre.

### Partnerség

Többek között ezért is fontos, hogy a megfelelő partnert válaszd. Szándékosan használom a partner szót, mert itt nem a klasszikus értelemben vett (egyirányú) eladó-vevő kapcsolatra kell gondolni. Egy sok szálon kötődő, kétirányú, egészséges partneri viszonynak kell kialakulnia – egyfajta digitális szimbiózisnak – különben rengeteg fejfájással jár majd a projekt mindkét fél számára. Partneri viszonyról beszélek, mert mindkét oldalon nyitottságot, türelmet, nagyfokú bizalmat követel meg az együttműködés, ami kimondottan hosszú időre is összekötheti a két felet. Nem kell kényszerű egymásra utaltsági viszonyban létezned, ezért kardinális kérdés a hozzád passzoló csapat kiválasztása.

Korábban összeszedtük egy posztba szerintünk „[Hogyan válassz digitális ügynökséget?](https://blog.fps.hu/digitalis-ugynokseg-valasztasa/)”, most pár pontban fejtem ki, hogy miért kell hosszútávon számítanunk egymásra.

### Bugok, hibák…

Nincs tökéletes program. Ha megfigyeled, a több ezer fejlesztővel készülő és külön tesztelő laborokkal felszerelt óriás cégek alkalmazásai is hemzsegnek a hibáktól. Egyszerű az ok, emberek vagyunk, tökéletlen másai Istennek. Tudd, hogy a te alkalmazásodban is vannak és lesznek is hibák. Ráadásul némelyik egy év múlva fog kiderülni, illetve egy megfelelően komplex alkalmazás esetében történt változtatás felszínre hozhat olyan hibákat, melyekről addig senkinek sem volt tudomása. Ide kell igazán a türelem és persze a bizalom is.

A bugokról mindig a [Bugs](http://www.lyricsfreak.com/p/pearl+jam/bugs%5F20106398.html?ref=blog.fps.hu) c. Pearl Jam szám jut eszembe és annak kérdései, majd a végkövetkeztetés:

> „Do I kill them?  
> Become their friend?  
> Do I eat them?  
> Raw or well done?  
> Do I trick them?  
> I don’t think they’re that dumb  
> Do I join them?  
> Looks like that’s the one"

### Fejlődik a technológia

Rendszerint összefügg az előző ponttal. Ilyenkor bukkan fel a jól ismert „Bug vagy Feature?“ kérdés. :) Nyilván pontosan tudod, hogy az informatika világában minden irdatlan tempóban fejlődik. Teljesen esélytelen felkészíteni egy alkalmazást az akár a közeli jövőben megjelenő újabb verziókra. Itt szóba jöhet gyakorlatlag minden: a futtató környezettől (web szerver, adatbázis szerver, program nyelv stb.), a különböző böngészők különböző verzión keresztül az operációs rendszerekig. A mobilok világa ráadásul ezt a problémát még tetézi is azzal, hogy hatalmas mennyiségű és minőségű készülékekkel állunk szemben. Gondolj bele, még a tesztelés is lehetetlen ennyi eszközön. Tehát légy tisztában azzal, hogy a friss alkalmazásodat lehet 2 hónap múlva át kell írni. Ééés nem nem bug, hanem fícsőr. :)

[![2013, 2014, 2015 években rengeteg böngészőverzió jött ki](https://blog.fps.hu/content/images/2015/12/internet.jpg)](http://meyerweb.com/eric/browsers/timeline-structured.html?ref=blog.fps.hu)

### Online marketing

A legzseniálisabb stratégia mellett is kiderül később, hogy be kell vetni egy újabb eszközt, melyek majdnem mindig hatással vannak az alkalmazásra és ott változtatásokat kell eszközölni, például mérés miatt. Itt fontos megemlíteni a [google algoritmusának folyamatos változásait](http://moz.com/google-algorithm-change?ref=blog.fps.hu) is, mely biztosan hatással lesz a SEO tevékenységre, ami végsősoron a tartalomban eredményez majd változást, vagy lehet akár kódszinten is. A közösségi média szüntelen változó dolgait már nem is említem.

### Mindig lehet jobb – ötletek

A tökéletlenségből fakadóan és az állandóan formálódó környezet miatt is új ötletek, változtatási igények jelennek meg és persze mindig, mindent lehet jobban csinálni. Sosincs vége.

### Változnak a felhasználók

A felhasználók fejlődnek. Egyrészt újak jönnek, másrészt a visszatérők és általában véve a felhasználók egyre okosabbak lesznek (a termékeddel, szolgáltatásoddal kapcsolatban és technológiai értelemben is). Nem utolsó sorban változnak az igényeik is, melyet bizonyára a céged lekövet. Érdemes folyamatosan szondázni a felhasználói szokásokat, viselkedés mintákat és aszerint változtatni a felületeken, megoldásokon. Ki kell őket szolgálni, különben odébbállnak egyik pillanatról a másikra.

### Változik az üzleti környezet

Új versenytársak jelennek meg a piacon, a korábban jól menő termékekre már nincs szükség, helyüket más termékek veszik át, hasonlóan a szolgáltatások esetében is. Minden változik ezerrel, így az alkalmazásodnak is változnia kell.

### Változik az üzleti modell

A fentiekből egyenesen következik, hogy az üzleti modell is változhat. Azt pedig le kell kezelni, bár gyakorta egy ilyen alapvető változás a korábbi projekt „halálával” is jár.

**és még?**

*[A fejléc kép wirdou grafikájának egy részlete](http://wirdou.com/2013/03/05/types-of-chemical-bonds/?ref=blog.fps.hu)*
### Konverzió optimalizálás 187 lépésben
URL: https://blog.fps.hu/konverzio-optimalizalas-cro-tippek/
Last updated: 2026-07-17T08:45:08.000Z
A konverzió optimalizálás célja még több vásárló szerzése, akik megvásárolják a terméket vagy szolgáltatást. Ebben az e-könyvben nem kevesebb, mint 187 specifikus és ingyenes tippet találsz, melyeket, ha rám hallgatsz, kinyomtatsz és egytől-egyig alkalmazol a webshopod optimalizálása során.

A letölthető e-könyv alapja Benjamin Gundgaard „Conversion rate optimization in 187 steps” című blog posztja volt, melyet lefordítottunk és honosítottunk nektek. A fordítást külön köszönjük a Favorit Fordító Irodának.

**Jó olvasást!**

[Töltsd le a könyvet (0 letöltés)](https://www.fps.hu/presentations/konverzio-optimalizalas-187-lepesben-fps.pdf?ref=blog.fps.hu "Töltsd le a Konverzió optimalizálás 187 lépésben könyvet PDF formátumban!") 

**Köszönd meg azzal, hogy megosztod barátaiddal, ismerőseiddel és feliratkozol hírlevelünkre!**
### Flat vector Christmas icons for free
URL: https://blog.fps.hu/free-christmas-flat-icons-vector/
Last updated: 2026-07-17T08:45:17.000Z
Our present for the world! Free vector based (pdf) flat icons for Christmas. Download and use it wherever and whenever you want. Free for personal and commercial use as well.

**Merry Xmas!**

![Christmas Flat Icons with dark blue background](https://blog.fps.hu/content/images/2015/12/christmas_flat_icons_square-1.jpg)

![Christmas Flat Icons with light gray background](https://blog.fps.hu/content/images/2015/12/christmas_flat_icons_circle-1.jpg)

[Download for free (0 downloads)](https://www.fps.hu/presentations/christmas%5Fflat%5Ficons%5Ffps.zip?ref=blog.fps.hu "Download flat vector Christmas icons pack for free") 

**It is allowed to share with your friends and others if you like it!** ;)
### Könyvajánló: Microinteractions
URL: https://blog.fps.hu/konyvajanlo-microinteractions/
Last updated: 2026-07-17T08:45:27.000Z
Mindennapi életünk során számos interakcióval találkozhatunk, melyeket észre sem veszünk. Akkor ezek jelentéktelenek lennének? Nem!

Rögtön egy példa: a legtöbb benzinkúton lévő csap. Mikor a kezed a csap alá tartod, az elkezdi folyatni a vizet mindaddig, amíg a mancsod oda tartod. Mekkora ötlet, nem kell mások után fogdosni a kallantyút, nem kell a csuklóddal bénázni, hogy nehogy elkapj valamit, csak szimplán odatartod a kézfejed és kész is a csoda.

### De mi is az interakció pontosan és hogyan épül föl?

A hivatalos definíciója szerint: *két vagy több dolog kölcsönhatása, kölcsönös kapcsolata*.

A mikrointerakciókat 4 részre lehet bontani:

- **TRIGGER**  
Az interakciót kiváltó dolog. Például egy gomb lenyomása. Ám fontos megjegyezni, hogy egy interakciót nem csak egy élőlény tud elindítani, hanem egy gép is: ha a telefonod merül, ezt érzékeli és feldob egy ablakot: “Merülök, dugj töltőre”
- **RULES**  
Ez határozza meg, hogy milyen esetekben mi történjen, mondjuk villanjon fel a lámpa, pulzáljon stb.
- **FEEDBACK**  
Azért felelős, hogy visszajelzést adjon: igen, már folyik a munka.
- **LOOPS and MODES**  
Az utolsó rész futási időt, ismétlést és módokat határoz meg.

### Miért fontosak a mikrointerakciók?

Hogy a terméked ne csak egy szükséges rossz legyen. Az interakciók segítségével teheted terméked használhatóvá és szerethetővé. A részletek nem csak egyszerűen részletek… a részletek maguk képezik a terméket.

### Gondolkodj kicsiben, váltsd meg a világot!

Ám a jó interakciók nem jönnek létre maguktól, tervezni kell. A tervezésnek pedig megvannak a maga trükkjei.

Egy **trigger** tervezésénél oda kell figyelni, hogy egyértelmű legyen, ez egy ravasz, amit “meg kell húzni”. Ha a trigger egy gomb, akkor az a gomb illeszkedjen a környezetéhez és mégis különüljön el, legyen figyelemfelhívó.

A **szabályokat (rules)** is pontosan, ésszerűen kell meg határozni: mi történjen a ravasz “meghúzásakor”, mi történjen futás közben és mi a futás végén… A kevesebb több! Egy egyszerű logikai diagram készítése nagy segítség lehet.

A **visszajelzés (feedback)** az egyik, ha nem a legfontosabb része az interakciónak. Egyértelműen kell a felhasználó tudtára adni, hogy mi történik éppen, mire számíthat. A kevesebb több szabály itt is érvényes. A leghatásosabb visszajelzési forma, ha a hallásra vagy az érzésre hatunk, a lényeg, hogy minél kevesebb energiát kelljen beleölnie a visszajelzés dekódolásába.

Az utolsó elemi rész egy kicsit összetettebb. Külön kell választanunk a **módokat (modes)** és **hurkokat (loops)**.

A módok a szabályok (rules) visszacsatolására szolgálnak. Az a jó, ha az egyes módok nem térnek el nagyban az interakció fő céljától, hanem annak módosulatai. Például egy időjárás alkalmazásban a cél, hogy mutassa az aktuális időjárást a jelenlegi helyeden. Egy mód lehet az, hogy beállíthatod, más város időjárását is mutassa. A fő cél nem sérül, időjárást mutat továbbra is.

Alapvetően két típusú módot különböztetünk meg: spring-loaded és one-off mód.

One-off módról akkor beszélünk, ha miután az adott mód betölt elvégzi a dolgát, visszavált az alapértelmezett módra. Például egy rajzoló programban ha rákattintunk a négyzet eszközre, az mindaddig aktív állapotot jelez, amíg a négyzet nem került ki a munkalapra, majd visszaáll normál állapotára.  
Ezzel szemben spring-loaded módról akkor beszélhetünk, ha az adott mód betölt és magától nem áll vissza. Mondjuk a kurzort egy link felé húzzuk, akkor egy kis popupban megjelenik a link title, ami addig nem is tűnik el, még el nem mozdítjuk az egeret.

A **hurkok (loops)** arra szolgálnak, hogy adott időközönként és/vagy adott időintervallumon belül mi történjen. Például 30 másodpercenként próbálja lekérni a legfrissebb üzeneteket.

Négyféle hurok létezik:

- **Count-controlled:** pl.: adott másodpercig próbálkozzon csatlakozni alkalmazásunk az internethez
- **Condition-controlled:** pl.: addig próbálkozzon csatlakozni alkalmazásunk az internethez, amíg nem sikerül
- **Collection-controlled:** pl.: addig fusson, ahány tweet van a listádon
- **Infinite:** pl.: ilyen a telefonodon lévő zseblámpa alkalmazás… amikor bekapcsolod a vaku világítani kezd egészen addig, amíg ki nem kapcsolod

Ha felkeltettem az érdeklődésed, akkor vedd meg [Dan Saffer: Microinteractions c. könyvét](http://microinteractions.com/?ref=blog.fps.hu) és olvasd!
### jQuery kód optimalizálása
URL: https://blog.fps.hu/jquery-kod-optimalizalas-javascript/
Last updated: 2026-07-17T08:45:37.000Z
Fejlesztés során mindig igyekszünk spórolni az erőforrásokkal, ám kliens oldalon hajlamosak vagyunk erről megfeledkezni, gondolván “pár sornyi JavaScript, észre sem veszi a felhasználó”. Ám a responsive oldalak elterjedésével egyre fontosabbá vált minden egyes http request, minden fogadott bájt és minden egyes lefuttatott JavaScript parancs, hiszen az oldal betöltődési sebességén túl annak működési gyorsasága is fontos.

Az erősebb hardverrel megáldott okostelefonoknak meg sem kottyan egy slider megjelenítése, viszont gondolni kell azokra is, akiknek régebbi, gyengébb eszköz adatott meg. Összegyűjtöttem pár tipikus példát tesztekkel, melyeket figyelembe véve jelentősen gyorsítható a kód futásának sebessége, ezáltal javítva a felhasználói élményt.

### Natív JavaScript vs jQuery

A jQuery függvénytár jelentősen megkönnyíti már évek óta a front-end fejlesztők életét. Szinte mindenre létezik jQuery plugin és ezt sokszor lusta fejlesztőként ki is használjuk. A jQuery többek között azért lett létrehozva, hogy az eltérő JavaScript motorok közötti különbségeket áthidalja. Mára azonban a helyzet [egyre inkább normalizálódik](http://www.sitepoint.com/do-you-really-need-jquery/?ref=blog.fps.hu), így több esetben lehet használni a natív megoldásokat. Persze, ez nem azt jelenti, hogy el kéne felejtenünk mindenféle keretrendszert és az azokkal járó egyszerűbb megoldásokat, csupán érdemes néha a működés mögé nézni és a natív megoldást választani a hatékonyság érdekében.

Ha csak pár sornyi JavaScriptet szeretnél futtatni az oldaladon, a legegyszerűbb függvényekkel (pl. show(), hide()), akkor teljesen felesleges behúzni egy komplett függvénytárat, ami legjobb esetben is további 40-50Kb adatforgalommal és egy http request-tel jár.

### getElementByID()

A legegyszerűbb példának egy adott id-vel rendelkező elem elérése tekinthető, aminél jelentős különbség van a [natív és jQuery](http://jsperf.com/jc-getelementbyid-vs-jquery?ref=blog.fps.hu) megoldások között. Az eredmény magáért beszél.

![getElementByID használatával nagyságrendekkel több művelet végezhető el másodpercenként](https://blog.fps.hu/content/images/2015/12/jqueryvsnativjs-3.jpg)

Szóval, ha a sebességet szem előtt tartva, és csak egy elemre akarsz hivatkozni, érdemes a

```javascript

var foo = $('#foo');

```

helyett a

```javascript

var foo = document.getElementById('foo');

```

formulát használni.

### Selectorok optimalizálása

Ha összetettebb módon szeretnél egy, vagy több elemet elérni, akkor érdemes a működés mögé nézni. Egy szelektor megadása esetén a jQuery a natív megoldásokhoz fordul (getElementById(), getElementsByTagName(), getElementsByClassName()), míg komplexebb lekérés esetén már külön fel kell dolgoznia az egyes tagokat és azok keresését. Ha megszokod ezeket az alapvető szabályokat, egy idő után már tudat alatt optimális kódot adsz ki a kezedből.

Használd a find() függvényt a komplex selectorok helyett.

```javascript

$('#id p'); // lassabb
$('#id').find('p'); // gyorsabb

```

Törekedj arra, hogy elkerüld a selectorok halmozását, amikkel számolnia kell a jQuery-nek, hiszen az csak lassítja a futást. Az alábbi példában teljesen felesleges a *table.foo* selector, amennyiben csak egy táblázatod van, amiben bar class-szal rendelkező cella van.

```javascript

$('.data table.foo td.bar'); //lassabb
$('.data td.bar'); //gyorsabb

```

Ha nem tudsz konkrét selectorral hivatkozni egy elemre, próbáld minél pontosabban elérni a felesleges elemek mellőzésével.

```javascript

$('.foo > *'); // a lehető leglassabb
$('.foo').children(); // egy fokkal jobb
$('.foo :radio'); // inkább kerüljük a használatát
$('.foo *:radio'); // az előzővel megegyezik
$('.foo input:radio'); // a :radio jQuery-specifikus
$('.foo input[type=radio]'); // az optimális megoldás

```

### Használj for-t az $.each() helyett

A jQuery által nyújtott $.each() függvény jóval lassabb, mint a natív for kifejezést használó megoldás. Igaz, az each esetén össze tudsz kötni műveleteket (chaining), de az esetek többségében úgysem élsz ezzel a lehetőséggel.

![for használatával nagyságrendekkel több művelet végezhető el másodpercenként](https://blog.fps.hu/content/images/2015/12/eachvsfor.jpg)

Az alábbi egyszerű példát [tesztelve](http://jsperf.com/jsfor-vs-jqueryeach?ref=blog.fps.hu) is az jön ki, hogy a natív megoldás háromszor gyorsabb, mintha jQuery-vel járnád be a tömböt. Ugyanez az eredmény objektumok bejárása esetén is igaz.

```javascript

var foo = new Array();
foo[0] = 'egy';
foo[1] = 'ketto';
foo[2] = 'harom';

$.each(foo, function(index, value) {
    value.test= 1;
});

var lng = foo.length;
for(var i = 0; i < lng; i ++) {
    foo[i].test = 1;
}

```

### Kerüld a túlzott DOM manipulálást

Természetesen nem tudod teljesen kikerülni, hiszen legtöbbször ezért használsz JavaScriptet, de érdemes átgondolni, miként is nyúlsz a DOM-hoz. Ez a művelet minden esetben lassú, nincs mit tenni, de például egy naptár beszúrását több féle módon is megteheted.

```javascript

var $calendar = $('<table></table>');
for (var i = 0; i < 6; i++) {
 var $tr = $('<tr></tr>');
 for (var j = 0; j < 7; j++) {
   $tr.append('<td></td>');
 }
 $calendar.append($tr);
}

```

A fenti megoldás a szép és elfogadott, ám a lentebbi mindenképpen gyorsabb és bizonyos esetekben célratörőbb.

```javascript

var $calendar = $('<table><tr><td><td>…</tr><tr>…</tr>…</table>');

```

### Window.load a document.ready helyett

Nem olyan meghatározó a sebességet illetően, de érdemes pár szót szólni a két eseménnyel kapcsolatban. A document.ready az oldal renderelésekor fut le, amikor még töltödhtenek be/le objektumok. Ez kisebb akadásokat okozhat az oldal megjelenítésében. Barátibb megoldás a processzor kihasználtságának szempontjából, ha minden elem letöltése után kezdjük el futtatni a scriptjeinket, azaz a window.load eseményhez kötjük.

### Szelektorok ismétlésének elkerülése - objektumok cachelése

Sokszor előfordul, hogy ugyanazt a selectort több alkalommal kell használnod egymás után. Sebesség szempontjából nem mindegy, hogy a script hányszor járja be a DOM-ot, hogy megtalálja azt a selectort. Roppant egyszerű, ám igen hatékony módja az optimalizálásnak, ha ilyen esetben [“lecacheled” a selectort](http://jsperf.com/jq-cached-selector?ref=blog.fps.hu).

![cache használatával nagyságrendekkel több művelet hajtható végre másodpercenként, mint cache nélkül](https://blog.fps.hu/content/images/2015/12/cache.jpg)

Például:

```javascript

$('div.foo div.bar div.elem1').someFunc();
$('div.foo div.bar div.elem2').someOtherFunc();
$('div.foo div.bar div.elem3').someTotallyOtherFunc();

```

Optimalizálva:

```javascript

var $bar = $('div.foo div.bar');
$bar.find('div.elem1').someFunc();
$bar.find('div.elem2').someOtherFunc();
$bar.find('div.elem3').someTotallyOtherFunc();

```

Ugyanez az eset áll fenn, amikor egy elem CSS attribútumait szeretnéd módosítani. Ilyenkor tömbként átadhatod a beállítandó értékeket, továbbá cachelés helyett összefűzheted az egyes funkciókat, ezzel is kihagyva a folyamatot, hogy a jQuery minden esetben bejárja a DOM-ot a selectort keresve.

```javascript

$('p').css('color', 'blue');
$('p').css('font-size', '1.2em');
$('p').text('Lorem Ipsum');

```

A gyorsabb és erőforrás-takarékosabb forma:

```javascript

$('p').css({'color': 'blue', 'font-size': '1.2em'}).text('Lorem Ipsum');

```

Másik, szintén hatékonyabb forma:

```javascript

var p = document.getElementByTagName('p');
$(p).css('color', 'blue');
$(p).text('Lorem Ipsum');

```

### Hogyan mérj?

Ha meg akarsz bizonyosodni számszerűen is arról, mennyire sikeresen írtad át a kódot, több megoldás is lehetséges. A [jsPerf](http://jsperf.com/?ref=blog.fps.hu) oldalon egyszerűen tesztelhetsz kódrészleteket, de akár komplett scripteket is. Amellett, hogy saját teszteket készíthetsz, mások által készített benchmarkok között is böngészhetsz, érdemes kattintgatni, mert érdekes eredményekkel szembesülhet az ember.

Természetesen kézenfekvő dolog a kódba beillesztett időbélyegek összehasonlítása, viszont kevés adat nem feltétlenül ad reprezentatív eredményt.

```javascript

var start = new Date().getTime();

for (i = 0; i < 50000; ++i) {
   //foo
}

var end = new Date().getTime();
var time = end - start;
alert('Futásidő: ' + time);

```

A Chrome [DevTools](https://developers.google.com/chrome-developer-tools/docs/cpu-profiling?ref=blog.fps.hu) és a [FireBug](http://getfirebug.com/javascript?ref=blog.fps.hu) hatékonyan használható a JavaScript kód debugolására, teljesítmény mérésére és elég részletes jelentést ad ahhoz, hogy feltérképezhesd a kód lassú pontjait és javíthasd az esetleges sebességet csökkentő hibákat.
### Flow-ra fel!
URL: https://blog.fps.hu/flow-acdc-jatek-agilis-ac/
Last updated: 2026-07-17T08:45:46.000Z
Itt egy ultra egyszerű, ultra hatékony játék, amitől minden fejlesztési mutatód nőni fog! **Gamification - az anyját!**

### Örökké

Minden élethelyzetben azon töröm a fejem – gyermekkorom óta – hogy lehet azt eljátszani, mitől akarom újra és újra ugyanazt, még ha megterhelő, vagy nagyfokú koncentrációt is igényel.

Ó akkor még fogalmam sem volt, hogy ez egy komoly tudomány. „Nem járok meg mélységeket”, de nem tudom kikerülni és nem is akarom! JÁTSZANI szeretnék örökké! (kolboid segített, hogy ne féljek az örökké szótól köszi ;) ) Ez most nem kihívás, hisz van egy öt éves kislányom, aki mellett az lenne a kihívás, ha picit abba szeretném hagyni a játékot, persze nem akarom! Mi van a irodában? Hát nekem összefolyik, azaz otthon is dolgozom, bent is játszom és ahol ezt nem tudták tolerálni vagy kihasználni ott nem is tudtam sokáig a rendszer hasznára válni.

### Agilitás

Az agilis fejlesztésről tudható, hogy rengeteg minden mellett végül kellenek sztorik, a sztorikhoz szükségünk van még elfogadási kritériumokra is, (acceptence criteria – AC) hogy teljesülhessen valahogy az a sztori. Legyen valami, ami alapján azt tudjuk mondani, hogy pipa, pipa, pipa megvan köszi, (DOD stb.), kész! Nem elhanyagolható, hogy az AC-k nagy része az ügyféltől kell hogy jöjjön, de ha nem is ő találja ki, akkor legalább lássa és fogadja el azt, amit mi kitaláltunk a sztorihoz.

*Példa sztori*  
**Mint feltaláló, utazás közben, szeretném feljegyezni a hirtelen jött gondolataimat, hogy emlékezzek rá később is.**

Elfogadási kritériumok 01:

- van egy papír darab
- van egy ceruza

### ÁLLJ!

Ki látott olyan Product Ownert (PO)-t, aki nem küszködik az elfogadási kritériumokkal? Megszül néhányat, aztán azok a leleményes fejlesztők kiválóan teljesítik úgy, hogy mégis marad benne némi hiányérzete vagy a Product Ownernek-nak, vagy az ügyfélnek, vagy mindenkinek - kivéve a fejlesztőt, aki a hatalmas nyomás kényszer miatt darálja a sztorikat.

Fenti sztorinkat a fejlesztő leveszi a falról, és könnyedén meg is ugorja, hiszen benyúl a fiókjába elővesz egy papírdarabot, igényel a kincstárból egy KohiNor HB-s cerkát és úgy érzi (a fenti kritériumok alapján joggal), hogy kész. Azután jön a bemutató, elviszi a papírt és a cerkát, jóhiszeműen átnyújtja az ügyfélnek és örül.

Ügyfél is örül, de első tesztelés alkalmával rájön, hogy a tenyerében írva a papír átlyukad, a cerka hegye kitörik… ugrott a találmány… ugrott a sztori (ez nem teljesen igaz, de ezt a kis ferdítést engedje meg nekem a tisztelt olvasó). Mindenki kérdőn néz, mert bár a kritériumok alapján a story „teljesült”, valójában nem, mert menet közben még mindig nem tudja feljegyezni ötleteit. Jöhet az újabb story, illetve ugyanaz, picit bővítve.

*Példa sztori*  
**Mint feltaláló, utazás közben, szeretném feljegyezni a hirtelen jött gondolataimat, hogy emlékezzek rá később is.**

Elfogadási kritériumok 02:

- van egy papír darab, amire lehet írni
- van egy kemény papír, ami támaszt ad a papírlapnak, hogy asztal nélkül is tudjon írni
- van egy toll, amiben van tinta

…és kezdődik minden elölről! Sok iteráció után kb. így nézhet ki az elfogadási kritérium rész.

Elfogadási kritériumok 35:

- van egy spirál fűzött jegyzet tömb, legalább 10 lappal
- van egy feltöltött töltő ceruza (közismert nevén rotring :))
- a ceruza hozzá van kötve legalább 20cm-es madzaggal a jegyzettömbhöz
- a jegyzet tömb mérete nem nagyobb 15cm\*20cm-nél (zseb méret)
- a jegyzet tömbben van legalább 5 üres lap
- a töltő ceruza végében van radír

**Nem görgetem tovább!**  
Lehetne, hogy így nézzen ki a sztori egyből? Mindjárt az első ötletelés/söprögetés/grooming alkalmával? Szerintem igen!

### AC/DC

Villámjáték, villámkéz, metálvilla! A játék lefolyása nem villámgyors, hanem inkább folyamatos, viszont pofon egyszerű és szerintem hatékony.

**Minden a Product Owner(PO) által, bemutatón elfogadott elfogadási kritérium(AC) két zsetont ér! Két igazi zsetont!**

**Minden más által dokumentáltan tesztelt és valóban PO által elfogadott elfogadási kritérium a tesztelőnek egy zsetont ér.**

**Minden el nem fogadott kritérium két zsetonba kerül a fejlesztőnek, a tesztelőnek egybe.**

Ezt vezessétek be, az alábbi pontosítások mentén.

![zsetonok illusztráció](https://blog.fps.hu/content/images/2015/12/token.jpg)

### Bővebben

A backlog groomingok alkalmával a PO vért izzad, hogy ismertesse és véglegesítse a sztorikat, hogy azt a következő sprintig, még az ügyfélnél meg is futtassa, el is fogadtassa azokat. AC/DC játék segítségével a fejlesztő érdekelté vállik, hogy elfogadási kritériumokkal tűzdelje a sztorikat, mégpedig minél többel!

> Egy sztori 4–8 elfogadási kritériummal elketyeg a tapasztalatok szerint, ha ennél több sikerülne, abból az következik, hogy valamelyik kritériumunk önmagában egy sztori, vagy taszk, és tovább kell bontani addig, míg végül a 4–8 világos és egyértelmű kritériumnál meg nem nyugszik.

A groomingok hatékonyak, pörgősek és szakmaiak lesznek, miután fejlesztőnk a zsetonok miatt minél több AC-t próbál beleerőltetni a sztoriba. PO-k észnél lenni! A sztorik optimalizálódnak – szétesnek ha kell – és tele lesznek elfogadási kritériumokkal. Az elfogadási kritériumokat tényleg tesztelik a fejlesztők, mert különben nem jutnak zsetonhoz, vagy éppen fizetnek érte. Egymás sztorijait tesztelik, mert az is zsetont ér. Sokkal kevesebb sztori bukik el, ügyfél vagy PO által, ergo sokkal kevesebb a plusz munka.

### Egy kis matek

220-as velocity-s csapat heti sprintekkel, átlagosan 40-60 közti sztorit darál le. Ha egy sztorihoz 4–8 elfogadási kritériumot számolunk, akkor 320 és 1000 zseton közt osztunk szét a fejlesztők között egy sprint alatt. Ha feltételezzük, hogy közel egyforma tudású csapatunk van, akkor mondjuk 6 felé osztjuk az 1000-et és picit innen elveszünk, oda hozzáteszünk, akkor a heti győztes kb. 250 zsetont hoz össze… Nincs más, csak eldönteni, hogy mennyit ér egy zseton a főnöknek :)

Én adnék zsetononként egy ötvenes a győztesnek… Az már szemmel látható összeg! (CEO-knak: 2 túlóra)

### Kellékek

Adjunk az egészhez igazi zsetonokat, a táblán Hall of Fame szekciót, heti győztes, vándor pólót kap, amit a székére kell húznia – mondjuk egy AC/DC pólót. Péntekenként a főnök tejel, a csapat a pénzből „könyvtárba megy”. Hogy működik-e? Próbáld ki, csak a játék kedvéért!
### Írj, tesztelj, és arasd le a babérokat!
URL: https://blog.fps.hu/irj-tesztelj-copywrite-3/
Last updated: 2026-07-17T08:45:56.000Z
Találkoztál már olyannal, hogy látszólag azonos tartalom közül az egyik jobban konvertál, mint a másik? Néha tényleg csak apróságokon múlik az, hogy valaki megveszi-e az adott terméket, vagy sem. Most ilyen apróságokból gyűjtöttem össze neked egy csokorra valót.

A szövegírásról szóló posztjaim közül az [elsőben](https://blog.fps.hu/szovegiras-copyrwite-alapok-1/) bemutattam, hogyan kezdj hozzá a szövegíráshoz, melyek az első lépések. A [második posztban](https://blog.fps.hu/hogyan-nyerd-el-a-vasarloid-bizalmat-copywrite-2/) konkrét szövegírási tanácsokkal láttalak el. Ebben az írásomban pedig sok-sok apró trükköt osztok meg veled, hogy a lehető legjobb tartalmakat tudd kínálni az ügyfeleidnek. Illetve egy kis meglepetéssel is készültem, de azt majd a végén. ☺

### Építs közösséget

A legtöbb ember szeret valahova tartozni: egy csoporthoz, közösséghez, márkához, stb.. Az emberek egy termék megvásárlásakor szeretik azt érezni, hogy most beléptek abba a közösségbe, akik az adott márka termékeit használják.

Ott vannak például az Apple termék tulajdonosok. Nem csak azért veszik a termékeket, mert jobbak, mint mások (ami az esetek többségében igaz is), hanem mert ezzel beléptek az Apple terméket használók táborába. Ezek az emberek, ha újabb vásárlásra kerül a sor, ezeket a termékeket fogják előnybe részesíteni még akkor is, ha drágábbak, mint az azonos kategóriájú társaik.

### Add meg az exkluzivitás érzését

Éreztesd a vásárlókkal, hogy olyan helyen jár, ahol lehetőség van egy olyan közösséghez tartoznia, amely első kézből értesül az üzlet körüli információkról, akciókról, kedvezményekről.

Ez lehet egy hírlevélre való feliratkozás, egy regisztrációhoz kötött belső oldal, egy Facebook csoport, vagy bármi más, a lényeg, hogy a vásárló érezze, ő több mint egy átlagos vásárló.

### Mutasd meg a termékek minőségét

Győzd meg a felhasználót arról, hogy ha a te termékedet választja, akkor egy minőségi termékhez fog hozzájutni. Mondd el neki, mit kap a pénzéért, ezzel is erősítheted a kötődését a márka iránt.

### Legyél szakértő

Ha valamilyen egyedi terméket vagy szolgáltatást kínálsz, alakíts ki magadról egy szakértői képet. Írj blogot, segíts a leendő vásárlóknak a döntésben, ha hozzád fordulnak tanácsért, ne sajnáld egy-egy ügyfélre az időt, hiszen ha jó vagy a szakterületeden, a profizmusoddal el tudod nyerni a bizalmukat.

### Call to action

Használj cselekvésre ösztönző szavakat, kifejezéseket. Miért fontos ez? Irányíthatod a vásárlókat abba az irányba, ahová szeretnéd, hogy eljussanak. Pl. iratkozz fel hírlevelünkre; próbáld ki a demó verziót, stb.. Ha csak szimplán, kijelentő mondatokban írsz, elolvassál és továbblépnek anélkül, hogy bármit tennének az oldaladon. Az egyszerű, lényegre törő üzenetek bizonyítottan a leghatékonyabbak arra, hogy a vásárlók cselekedjenek.

### A sürgetés művészete

Gyakran előfordul, hogy az ügyfelek már közel állnak ahhoz, hogy vásároljanak, de valamiért még bizonytalanok. Ilyenkor a vásárlás irányába billentheted a mérleget egy kis sürgetéssel, pl.: már csak 3 darab van ebből a termékből, vegye meg még ma! vagy a kedvezményes lehetőség már csak két napig él, rendelje meg most! A két bűvös szó a ma és a most. Egyik sem erőszakoló vagy tolakodó, mégis sokszor elérik a céljukat.

A másik stratégia, amikor korlátozott ideig vagy korlátozott darabszámban áll rendelkezésre a termék. Ezzel is vásárlásra tudod ösztönözni a leendő ügyfeleket.

### Készíts egy lenyűgöző ajánlatot

Van, amikor nem elég bemutatni a termék előnyeit és azt, hogy miért jó ez a vásárlónak. Néha ennél több kell. Ilyenkor kell bevetni egy lenyűgöző ajánlatot. Úgy kell tálalni az ajánlatot a vásárlónak, hogy ne tudjon rá nemet mondani. Azokat az előnyöket kell leginkább kidomborítani, amit kommunikálni szeretnél. Lehet ez valamelyik tulajdonsága, ára, elérhetősége, stb..

### Ne felejtsd el a garanciát

Mindig tüntesd fel, hogy az adott termékre milyen formában és mennyi ideig vonatkozik a garancia. Ha van pénzvisszafizetési garancia, azt is mindenképp hangsúlyozd. Sokan azért nem merik ezeket az információkat kiírni, mert félnek a sok panasztól. De gondold csak végig: neked hányszor volt szükséged cserére vagy garancia érvényesítésére? Ugye, hogy nem sokszor. Oszd meg bátran ezeket az információkat is, ezzel csak tovább építed a bizalmat.

![Nap és felhő illusztráció](https://blog.fps.hu/content/images/2015/12/cludandsun.jpg)

### Rövid vagy hosszú szöveg: melyik a jobb?

Ez egy örök dilemma. A hosszabb szöveg sok esetben jobb, mint a rövidebb, mert sokkal több információt tud adni a vásárlók számára. Vannak esetek, amikor a rövidebb szöveg jobban működik, tömör és lényegre törő információkkal. Szintén jobban működik a rövid szöveg olyan esetekben, amikor eleve jó az ár-érték arány, és nem kell hosszasan győzködni a vásárlókat. A vásárlók szívesen olvasnak akár hosszabb szöveget is, ha az érdekes és értékes információkat nyújt számukra. Gondold át, a te termékedhez melyik passzol jobban, és azzal próbálkozz. De kipróbálhatod mindkettőt, és egy A/B teszt segítségével könnyedén kideríthető, melyik működik jobban.

### Hogyan kombináld a szöveget a designnal?

Mindkét elem szükséges ahhoz, hogy hatékonyan működjön a tartalom és a lehető legjobb eredményeket érjék el. Egy nagyszerű szöveg rossz designnal nem lesz hatékony, de fordítva is igaz, egy remek design sem tudja ellensúlyozni a rossz szöveget. Mindkét szakembernek együtt kell dolgoznia az optimális tartalom elkészítéséhez. Íme, néhány kulcsfontosságú pont:

- a design tervezése mindig előzze meg a szövegírást, amely megteremti a szöveg környezetét
- másrészről ne azért írjunk szöveget, mert a design kialakítása olyan, hogy kell még szöveg helykitöltőnek – ebben az esetben a designon kell alakítani
- az olvashatóságot mindig szem előtt kell tartani a tervezéskor
- a designer és a copywriter együtt tervezze és alakítsa ki a landing page-t, akkor fog működni leghatékonyabban

**És utoljára, de nem utolsó sorban: tesztelj, tesztelj, tesztelj**.

Sokan közhelynek tartják, pedig kulcsfontosságú a tesztelés. Hiába gondolod a szövegedről, hogy ez remekül sikerült, ha egyetlen konverziót sem hoz. Nagyon fontos, hogy többféle változatot is tesztelj, gondolj csak a pár sorral fentebb említett rövid kontra hosszú szövegre. Ha nem tesztelsz, honnan tudod, hogy jól működik-e a szöveged?

Legyen szó email kampányról, vagy webes landing page-ről, az A/B tesztelés mindkét esetben alapvető fontosságú. Az eredmények tükrében változtathatsz a tartalmon és újra tesztelhetsz addig, amíg a megfelelő eredményt el nem éred.

### Miről is volt szó eddig?

Három poszton keresztül végigvezettelek téged a szövegírás kacskaringós ösvényén. Az [első posztban](https://blog.fps.hu/szovegiras-copyrwite-alapok-1/) a termék és az ügyfelek megismerésének módjait mutattam be, a [másodikban](https://blog.fps.hu/hogyan-nyerd-el-a-vasarloid-bizalmat-copywrite-2/) a szövegírás lépéseit vettem sorba, ebben pedig további tippeket és tanácsokat adtam a még tökéletesebb tartalom előállításhoz.

### És most jön a meglepetés!

Íme, egy jó kis ellenőrző lista, hogy amikor szöveget írsz, lépésről-lépésre haladva ki tudd pipálni, amivel már elkészültél. Így garantáltan nem marad ki semmi. Sok sikert!

Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!

0 [Töltsd le a checklistet](http://www.fps.hu/presentations/copywrite-checklist-fps.pdf?ref=blog.fps.hu "Töltsd le a chekclistet vektoros PDF formátumban és nyomtasd ki magadnak!")
### Hogyan nyerd el a vásárlóid bizalmát?
URL: https://blog.fps.hu/hogyan-nyerd-el-a-vasarloid-bizalmat-copywrite-2/
Last updated: 2026-07-17T08:46:05.000Z
Miért a cím a legfontosabb egy szöveg esetében? Hogyan kell megtalálni az arany középutat a szövegírásban, hogy tartalmazza az összes fontos információt, de ne legyen se túl száraz, se túl hosszú?

Az [előző posztomban](https://blog.fps.hu/szovegiras-copyrwite-alapok-1/) arról írtam, miért fontos alaposan megismerned a terméket azelőtt, hogy értékesíteni kezd. Most pedig arról olvashatsz, hogyan írd meg úgy a szöveget, hogy aki elolvassa, meg is vegye a terméket.

### Hogyan írj konvertáló címet?

Mivel a címmel találkozik a vásárló legelőször, döntő fontosságú, milyen szavakat használsz. Ha a címmel és az első egy-két mondatos bevezetővel fel tudod a látogatók figyelmét kelteni, jó eséllyel tudsz vásárlót konvertálni belőlük. A cím sokféle lehet: egy szöveges tartalom címe, egy email tárgya, egy rövid hirdetésszöveg, stb.. A cél mindegyiknél ugyanaz: eladni a terméket.

Íme, négy ökölszabály, amelyet mindig tarts szem előtt címadáskor:

- legyen egyedi: ha olyan terméket próbálsz eladni, amit mások is forgalmaznak, ne állj be a sorba sokadikként, és vagy vásárolnak tőled, vagy nem. Próbálj valamilyen egyedi dologgal kitűnni a többiek közül, ami nem jelenti azt, hogy olcsóbban kell adnod a terméked. Például próbálj másképp kommunikálni a vevőiddel, legyen üzenete a mondanivalódnak, és ezzel máris új vásárlókat szerezhetsz. Legyél pimasz, provokatív vagy akár vicces, a lényeg, hogy keltsd fel az érdeklődést.
- legyen ultra-specifikus: amellett, hogy a főcím egyedi, azt is meg kell mutatnia, mennyire egyedi ajánlatot kínálsz. Muszáj valamilyen információt nyújtania, hogy „rákényszerítsd” a látogatót arra, hogy megnézze az ajánlatodat.
- sürgesd a felhasználót: ha lehetséges, próbálj egy időtartamot megszabni arra, hogy meddig él ez az ajánlat. Tartalmazzon valami olyan paramétert az ajánlat, amit nem lehet kihagyni. A gyors döntésért cserébe adj valami fogódzót is: x napig ingyen kipróbálhatja, pénzvisszafizetési garancia y napon belül, ha nem tetszik stb.
- legyen hasznos: a négy közül ez a legfontosabb. A leendő vásárlóidnak fontos, hogy első pillantásra lássák, miért hasznos nekik, ha a te termékedet vásárolják. Ha tudsz olyan dolgot megvillantani az elején, amire felkapják a fejüket, nagy eséllyel fogják megnézni az ajánlatot is.

### A meggyőzés titkai

Már pontosan ismered a terméket, amiről írni szeretnél, tisztában vagy az ügyfelek igényeivel és véleményével, és már azt is tudod, hogyan kell megfelelő címet adni. Most jön a legfontosabb rész: a termék bemutatása. Lássuk, hogyan kezdj bele.

![fúrógép illusztráció](https://blog.fps.hu/content/images/2015/12/furo.jpg)

#### Hangsúlyozd az előnyöket és a funkciókat

Ezek a legalapvetőbb dolgok, mégis sokszor belefeledkezünk a funkciók leírásába és specifikálásába ahelyett, hogy kiemelnénk az előnyöket. Persze, a funkciók bemutatása igenis fontos, de attól, hogy ultra specifikusan bemutatsz minden apró részt, még nem győzöd meg a felhasználót, hogy igenis, neki erre szüksége van, és vásárolja meg.

Domborítsd ki inkább az előnyöket: miért jó ez neki, miben más, mint a hasonló termékek, győzd meg, hogy neki csak a te termékedre van szüksége.

#### Legyél a lehető legrészletesebb

Ne csak általános dolgokat mondj a termékről, mutasd be részleteiben is, és mindenképp világíts rá, miért jó ez neki. A legjobb egy konkrét példán keresztül, így a témában nem járatos ügyfelek is pontos képet kaphatnak a termékről. Például víztisztító berendezést próbálsz eladni. Mutasd be az ügyfeleidnek a terméket, hogyan működik, és ha ezt használja ivásra a palackos ásványvíz helyett, akkor havi és éves szinten mennyit takaríthat meg, illetve a beruházás így mennyi idő alatt térül meg. Ha a számok magukért beszélnek, kell ennél nagyobb meggyőző erő?

#### Célozz az érzelmekre

Amikor vásárlunk, gyakran befolyásolnak az érzelmeink. Hiába mondjuk azt, hogy döntésünk logikai, az esetek döntő többségében érzelmeinkre hagyatkozva döntünk a vásárlás mellett. Ennek nagyon egyszerű oka van: az érzelmek alapvetően befolyásolják a döntéseinket. [Antonio Damasio](http://hu.wikipedia.org/wiki/Antonio%5FDamasio?ref=blog.fps.hu), a Dél-Kaliforniai Egyetem neurológia professzora kutatásokat végzett a témában, melyről könyvet is írt „Descartes Error” címmel. Damasio olyan eseteket vizsgált, ahol a pácienseknek sérült az agy frontális lebenye, épp az a rész, amely az érzelmekért felelős. A vizsgálati eredményekből kiderült, ezeknél a betegeknél egy egyszerű döntés meghozatala is nehézségekbe ütközött.

És mindez hogyan kapcsolódik a szövegíráshoz? Neked is az érzelmekre kell hatnod ahhoz, hogy vásárlásra ösztönözd az ügyfeleidet. A termékeladás nemcsak arról szól, hogy szüksége van a vevőnek a termékre, és megveszi. Hanem arról is, hogy felkeltsük benne a vágyat a termék iránt.

#### Használj vásárlói ajánlásokat

Amellett, hogy használod az eddig bemutatott eszközöket, egy igazi szövegíró tudja, hogy a végső győzelem eléréséhez be kell vetni még egy ütős fegyvert: a vásárlói ajánlásokat. Írhatsz sok-sok előnyt, funkciót, szépet és jót, az ajánlások segíthetnek igazán vásárlásra ösztönözni a bizonytalan ügyfeleket.

Például azt mondod a termékedről: ez a legfinomabb szilvalekvár az országban. Te, mint vásárló elolvasod, jó-jó, de honnan tudják, hogy tényleg ez a legfinomabb? Ekkor meglátod Juli néni véleményét, aki elmondja, tényleg nagyon ízletes ez a lekvár. Ugyancsak dicséri a terméket Tivadar is, sőt, Ödön és Klárika is áradozik róla. Ezen vélemények után ugye, hogy könnyebben döntesz a vásárlás mellett?

Az ügyfélajánlások hitelessé teszik a terméket, mellyel bizalmat építhetsz a leendő vásárlók irányába. A vásárlók véleménye mindig többet nyom a latba, mint az eladó tájékoztatása.

### Mire figyelj még?

Ha összeállt a szöveg, alaposan nézd át, különös tekintettel a helyesírásra és a stilisztikára! Nincs annál kiábrándítóbb, amikor egy amúgy profin összerakott tartalom tele van hibával. Ezzel a hitelességedet és hozzáértésedet áshatod alá. Ha nem vagy jó helyesíró, kérj meg egy hozzáértőt, hogy nézze át a szöveget, mielőtt publikálod.

### Miről is volt szó eddig?

Megnéztük, melyek a jó címadás ismérvei, és végigmentünk az ügyfelek meggyőzésének lépésein. Gyakorlatilag már minden információ a birtokodban van ahhoz, hogy professzionális szöveget írj. A trilógia befejező részében további tippeket és trükköket osztok meg veled, amellyel még ütősebbé teheted a szövegeidet.
### Hogyan adja el a weboldal magától a terméket?
URL: https://blog.fps.hu/szovegiras-copyrwite-alapok-1/
Last updated: 2026-07-17T08:46:16.000Z
A tartalom az egyik legfontosabb „eszköz” a mai digitális korban. A design, a tartalom marketing, a SEO mind-mind szükségesek a teljes online marketing tervhez, de a megfelelő szövegezés a ragasztó, hogy a fentieket egységgé formálja.

### Mit is jelent pontosan a szövegírás?

A szövegírás (copywriting) a művészet és a tudomány egyvelege ahhoz, hogy olyan tartalmakat hozz létre (weboldal/landing page szövegek, hirdetések, PR cikkek stb.), melyek eladják a terméket és meggyőzik, valamint cselekvésre késztetik a leendő ügyfeleket. Sok szempontból olyan ez, mint egy eladó az üzletben. Csak amíg az üzletben egy eladó egyszerre egy ügyféllel tud foglalkozni, addig a weboldalad párhuzamosan sok ügyfelet szolgál ki, akár azonos időben is. Ahhoz, hogy ez jól működjön, meg kell tanulnod, hogyan kell olyan szöveget írnod, amely magától eladja a terméket.

### Kezdd az alapoknál!

Mielőtt belekezdenél a szövegírásba, alaposan meg kell ismerned azt a terméket, amit el szeretnél adni. [David Ogilvy](http://www.ogilvy.com/About/Our-History/David-Ogilvy-Bio.aspx?ref=blog.fps.hu "David Ogilvy életrajza"), a legendás szövegíró három hétig aprólékosan tanulmányozta a Rolls-Royce-t és végül megszületett a tartalom. A végső verzió főcíme ez lett: 60 mérföldes sebességnél a leghangosabb dolog a Rolls-Royce-ban az elektromos óra. Ennek a mondatnak a megszületése három hétbe tellett, és elég meggyőző lett ahhoz, hogy eladja a luxusautót.

### Készíts termékleírást!

Fogj egy üres lapot vagy nyiss egy üres dokumentumot, és első lépésként írd le maximum két-három mondatban, mi is a termék. Nem kell hosszan, részletekbe menően leírni, csak tömören a lényegét. Ha ezzel megvagy, írd le azt is, mitől különleges, mitől egyedi. Miért ezt vásárolják? Mert hazai termék? Könnyű használni? stb..

Ha van olyan tulajdonsága, amely egyedülálló és más termék nem tud ilyet, akkor használd a USP-t (unique selling proposition).

Gyűjtsd össze azt is, miért jó a termék, mire, hogyan lehet használni, melyek az előnyei. Az emberek leggyakrabban két okból szoktak vásárolni: egyrészt, hogy örömet okozzanak maguknak, másrészt hogy enyhítsék a fájdalmukat. Emeld ki, a termék miben fog a használójának örömet okozni, és azt is, hogyan tudja a fájdalmát csillapítani.

Írd össze a jellemzőit. Most van itt a lehetőség, hogy részletesen összeszedd az összes jellemzőt, tulajdonságot. Ha ezekkel elkészültél, jöhet a következő lépés.

[![idő + koktél + toll = copywriter](https://blog.fps.hu/content/images/2015/12/copywriter.jpg)](http://elbookdemhs.tumblr.com/post/16425077450/im-not-an-alcoholic-im-a-copywriter-via?ref=blog.fps.hu)

### Definiáld a célközönséget!

Ha már minden részletét ismered a terméknek, itt az ideje megismerni a vásárlókat is. Ahhoz, hogy bármit is el tudj adni, mindkét fél igényeit és lehetőségeit ismerned kell, valamint azt is, melyek a terméknek azon tulajdonságai, amellyel meggyőzheted a vásárlókat.

Első lépésként azt kell megvizsgálnod, kik vásárolják jelenleg a terméket. (Fiatalok, idősek, háziasszonyok, nagycsaládosok stb.). Ezt azért fontos, hogy tudd, hogyan szólítsd meg őket.

Hogyan néz ki egy tipikus vásárló? Készíts perszónát hozzá, így könnyebb lesz a „bőrébe bújnod”. Fel kell térképezned azt is, melyek a terméknek azon tulajdonságai, ami miatt szeretik a vásárlók. Miért veszik, és miért pont ezt?

Most már jól ismered a terméket és a vásárlókat is. Itt az ideje megtudni, hogyan vélekednek a termékről.

### A titkos fegyver: tanulj a termékről a vásárlóktól!

A legtöbb szövegíró megelégszik az eddig begyűjtött információkkal, és elkezdi a tartalmakat írni. De ahhoz, hogy a legjobban konvertáló szöveget tudd elkészíteni, szükség van egy titkos fegyverre. Kérd meg a vásárlókat, beszéljenek ők a termékről, mutassák be, mondják el, mi a véleményük róla.

Jegyezd fel, amit mondanak: milyen szavakat, kifejezéseket használnak, mit gondolnak róla. Ez azért is fontos, hogy amikor írsz a termékről, használd a vásárlók által is említett szavakat, kifejezéseket, így közelebb érzik magukhoz, könnyebb meggyőzni őket a vásárlásról.

Hogyan tudod begyűjteni a vásárlói véleményeket? A legkönnyebb és legegyszerűbb mód a kérdőív kitöltése. Készíts egy kérdőívet (számtalan eszközt találhatsz ehhez, pl. Google Forms, Survey Monkey, stb.). Lehetőleg nyitott kérdéseket használj, hogy a vásárlóknak legyen lehetősége saját szavaival válaszolni. 8-10 kérdésnél lehetőleg ne tegyél fel többet egyszerre.

Ha elkészültél a kérdőívvel, meg kell határozni, hány emberrel szeretnéd kitöltetni. Elegendő 5 ember véleménye? Valószínűleg ennyi kevés lesz. Legyen akkor 1000? Ez pedig már túl sok. Próbáld meg úgy kitűzni a célszámot, hogy elegendő információt gyűjts, de gondolj arra is, a sok nyitott kérdést fel is kell dolgozni.

![ember fejek illusztráció](https://blog.fps.hu/content/images/2015/12/man-1.jpg)

Ha megérkezett a megfelelő számú kitöltött kérdőív, ki kell értékelni. Gyűjtsd külön kupacokba az egyes kérdésekre adott válaszokat, majd az azonosakat vond össze. Így egyben látod kérdésenként a válaszokat, azokat a szavakat és kifejezéseket, melyeket a vásárlók használnak.

Próbáld meg azt is megtudni a vásárlóktól (kérdezz rá a kérdőívben), általában mi akadályozza meg abban, hogy megvásároljon egy terméket. Ebben az esetben nyugodtan adhatsz válasz alternatívákat, de hagyj lehetőséget saját válaszra is. Ezen információk birtokában még inkább kiküszöbölheted a problémákat, és még jobban fókuszálhatsz a vásárlásra.

Szintén hasznos információkhoz juthatsz, ha rákérdezel, melyek a legszükségesebb információk ahhoz, hogy eldöntse, megvásárolja a terméket.

### Miről volt eddig szó?

Áttekintettük a szövegírás fogalmát, megbeszéltük, miért kell nagyon alaposan ismerni a terméket. Ezután megismerkedtünk a célcsoporttal, majd kikértük egyes ügyfelek véleményét a termékről. Ez utóbbi azért is fontos, hogy egyrészt megismerjük az ügyfél véleményét, másrészt az igényeit is felmérjük a termékkel kapcsolatban. Harmadrészt segít nekünk a megfelelő szövegezésben azzal, hogy saját szavaival mondja el mindezeket nekünk. Egy termékleírásnál hajlamosak vagyunk szakkifejezéseket használni, amitől ugyan nagyon komolynak és szakszerűnek fog tűnni a leírás, csak éppen az ügyfél nem fogja érteni, mire is jó a termék, mit akarunk eladni neki.

### Hamarosan…

Most már elegendő információd van ahhoz, hogy elkezd a tényleges szövegezést. A következő posztban az íráshoz adok majd sok-sok hasznos tanácsot. 

*A fejléc kép [Andrew B. Myers](http://www.andrewbmyers.com/?ref=blog.fps.hu) műve.*
### Chrome DevTools érdekességek
URL: https://blog.fps.hu/chrome-devtools-funkciok/
Last updated: 2026-07-17T08:46:26.000Z
Egyre több webfejlesztő használ Chrome-ot és azzal együtt a DevTools nevű eszközt. Sokan még mindig a Firefox – Firebug kombóra esküsznek, pedig a DevTools kinőtte magát és egy rendkívül hasznos fejlesztői tool lett. Legtöbben csak az oldal stíluslapjának módosítására, a DOM vizsgálatára vagy éppen a konzol elérésére használják, pedig ettől már sokkal többre képes. Az alábbi posztban kiemeltem pár érdekességet, melyek valószínűleg ismeretlenek számodra.

### Szelektorok pszeudó osztályai a stíluslap-kezelőben

Gombok, inputok, linkek és egyéb elemek szelektorai esetén használatos a :hover, :active, :focus és :visited pszeudó osztály. A DevTools stíluslap kezelője lehetőséget ad, hogy manuálisan alkalmazd ezen állapotokat bármelyik elemre a jobb felső sarokban található „Toggle Elements State” ikonra kattintva.

![pszeudó osztályok Chrome DevToolsban képernyőkép](https://blog.fps.hu/content/images/2016/01/blog_1.png)

### Overrides – Környezeti paraméterek felülbírálata

RWD fejlesztés során macerás minden eszközön egyszerre tesztelni az oldal megjelenését. Ez a folyamat természetesen nélkülözhetetlen, de kezdetben ki lehet váltani sokféle eszközzel. Léteznek erre [bookmarkletek](http://www.queness.com/post/13410/5-bookmarklets-to-test-responsive-layout?ref=blog.fps.hu), ám a DevTools is rendelkezik ilyen funkciókkal, melyek pl. a geolocation meghatározásakor, tesztelésekor kifejezetten hasznosak.

A jobb alsó sarokban található beállítások ikonra kattintva jön elő a panel, ahol elérhető az „Overrides” menüpont. Itt tudod felülbírálni a böngésző által küldött user-agentet, a pozíciódat (GPS), de akár szimulálhatsz touch eseményeket, az eszköz térbeli helyzetét (device orientation), vagy a css media értékét, ami megkönnyítheti a nyomtatási nézet lefejlesztését.

![Overrides Chrome DevToolsban képernyőkép](https://blog.fps.hu/content/images/2016/01/settings.jpg)

### Snippets – előre definiált scriptek

Személy szerint imádom a bookmarkleteket és a snippeteket. Meggyorsítják a munkát, ha az ember jól használja őket. A DevTools is támogatja ezeket, amennyiben be van kapcsolva az „Enable DevTools experiments” flag ([részletes leírás a bekapcsolásáról](https://github.com/bgrins/devtools-snippets?ref=blog.fps.hu#to-enable-devtools-snippets-in-chrome)). Írhatsz sajátokat, vagy egyszerűen gyűjthetsz ide bookmarkleteket, de akad számos, más által írt darab is, melyek [szabadon letölthetők](http://bgrins.github.io/devtools-snippets/?ref=blog.fps.hu). Ez a funkció még fejlesztés alatt áll, ezért csak experimental módban érhető el. Viszont hozzájuk rendelsz billentyű-kombinációkat, igencsak megnövelik a hatékonyságodat.

![Snippets képernyőkép](https://blog.fps.hu/content/images/2016/01/blog_2.png)

### Chrome for Android debuggolása

Zseniális funkció, amivel összekötheted az asztali számítógépen és Android telefonon futó Chrome böngészőket. Hamarosan megjelenik a funkció legújabb változata, amiben már preview képet is kapsz az eszköz által renderelt oldalról, de már mostani változatában is segítségedre lehet. A [teljes folyamatról komplett leírás](https://developers.google.com/chrome-developer-tools/docs/remote-debugging?ref=blog.fps.hu) elérhető angol nyelven, de azért összeszedem pár mondatban a lényeget.

### Mire van szükség hozzá?

- Android operációs rendszert használó tablet vagy telefon, amire telepítve van a [Chrome for Android 28](https://play.google.com/store/apps/details?id=com.android.chrome&hl=en&ref=blog.fps.hu), vagy annak későbbi verziója
- Chrome 28, vagy frissebb verziója a számítógépre telepítve
- USB kábel az eszközök összekapcsolásához
- Telepített [ADB Chrome kiegészítő](https://developers.google.com/chrome-developer-tools/docs/remote-debugging?ref=blog.fps.hu#install-adbplugin)

#### Hogyan aktiváld?

- Az ADB kiegészítő telepítése után indítsd el azt a Start ADB paranccsal (jobb klikk a címsor mellett megjelenő ikonra)
- A csatlakoztatott eszközön engedélyezd az USB hibakerersés funkciót
- A csatlakoztatott eszköz Chrome beállításai között is engedélyezd az USB hibakeresést
- Ha mindent jól csináltál, a számítógépen futó Chrome címsora mellett, a zöld számmal ellátott Android figura ikon mutatja a csatlakoztatott eszközök számát
- A böngésző címsorába írd a következőt, és nyisd meg: chrome://inspect/
- A megjelenő aloldalon hozzáférhetsz a csatlakoztatott eszközön futó Chrome lapjaihoz és kényelmesen vizsgálhatod őket, mintha csak a gépeden futna

### Workspaces

A workspace-ek használatával lehetőséged nyílik a helyben futó webszerver fájljait direkt módon elérni és szerkeszteni. Így a fejlesztés (sitebuild) 100%-a elvégezhető akár a DevTools használatával. Nagyon nem részletezem, inkább a [következő leírást ajánlom](http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/?ref=blog.fps.hu#toc-workspaces) a megértéséhez.

### A kiegészítő kiegészítése

A DevTools különálló kiegészítőnek tekinthető, ám alapfelszereltsége a chrome böngészőnek és bárki által [továbbfejleszthető](http://developer.chrome.com/extensions/devtools.html?ref=blog.fps.hu), [letölthető kiegészítőkkel](http://addyosmani.com/blog/devtools-extensions-for-webapp-developers/?ref=blog.fps.hu) bővíthető a tudása.

### Ha többet szeretnél tudni

A Google mindig kellő figyelmet fordított termékei támogatására, a fejlesztők informálására és oktatására. Nincs ez másképp ezesetben sem, hiszen számos [hivatalos](https://developers.google.com/chrome-developer-tools/?ref=blog.fps.hu) és [nem hivatalos](http://www.igvita.com/slides/2012/devtools-tips-and-tricks/?ref=blog.fps.hu#1) leírás mellett [interaktív online kurzus](http://discover-devtools.codeschool.com/?ref=blog.fps.hu) is létezik, amire érdemes rászánni az időt, hiszen biztos tanulhatsz újat, amivel kényelmesebbé és hatékonyabbá teheted a munkád.
### Tartalom: fogyasztjuk és/vagy előállítjuk?
URL: https://blog.fps.hu/tartalom-fogyasztjuk-vagy-eloallitjuk/
Last updated: 2026-07-17T08:46:35.000Z
Nagy érdeklődéssel hallgattam az online média szekció előadásait az idei [Internet Hungary](https://www.internethungary.com/?ref=blog.fps.hu)\-n, ugyanis kíváncsi voltam, megmondja-e valaki a tutit, azaz mely irányba fog elmozdulni a tartalomfogyasztás. Az írott sajtó háttérbe szorul-e a videós tartalmak térnyerésével?

Már jómagam is többször leírtam: a tartalom a király. Legelőször ez a mondat Bill Gates szájából hangzott el 1996 januárjában. Az internet hajnalán már sejtette, a tartalomé a jövő. És az idő őt igazolta. A tartalom mindig is fontos volt, de a jelentősége az utóbbi néhány évben nőtt meg. A Google is a minőségi tartalom mellé állt: 2011-ben jelentős keresési algoritmus váltást hajtott végre, melyet Panda névre kereszteltek. A Panda célja, hogy kiszűrje a spam és rossz tartalmakat, és támogassa az egyedi, minőségi tartalmakat. A Pingvin 2012-es megjelenése pedig tovább erősítette ezt a folyamatot.

Nemcsak a tartalom minősége, de a tartalomfogyasztás is jelentősen változott az elmúlt években. A televízió előtt töltött idő valamelyest csökkent, viszont a mobil eszközök (okostelefonok, tabletek) színre lépésével új tartalomfogyasztási móddal ismerkedhettünk meg: a többcsatornás tartalomfogyasztással. Ülsz otthon a tévé előtt, kezedben a tablettel vagy az okostelefonnal, és párhuzamosan használod őket. A mobil eszközöknek köszönhetően ma már gyakorlatilag bárhol, bármikor lehet tartalmat fogyasztani.

A Z generáció tagjai (a mai 15–20 éves korosztály) már teljesen másképp viszonyulnak az információs társadalomhoz. Ők már nem elégszenek meg a passzív tartalomfogyasztással, egyre inkább alakítják, formálják a digitális világot. Videókat készítenek és osztanak meg, fotóznak, blogolnak, fontos számukra az önkifejezés. Megdöbbentő az az adat is, mely a magyar Youtube használatra vonatkozik: hazánkban havonta 2,7 millió órát töltünk Youtube videók nézésével, és ezeknek közel felét! a Z generáció tagjai teszik.

### Merre tovább?

A folyamatosan növekvő versenyben, mely a fogyasztók megszerzéséért és megtartásáért folyik, kulcsfontosságú szerepe van a minőségi tartalomnak. De mit tehet a média akkor, amikor egy amatőr videó sokmilliós nézőtáborával lepipálja a szerkesztőségek által készített minőségi tartalmakat?

Egyre többen használják fel és építik be a felhasználók által generált tartalmakat. (pl. helyi hírportálok) Ezek a tartalmak már messze nem a régi klasszikus home videók. A technológiai fejlődésnek köszönhetően egy mobiltelefonnal bárhol tudunk tartalmat előállítani, pl. egy koncertről, előadásról, nyaraláskor, stb.. Ezek a tartalmak véleményformálók lehetnek, melyek fontosak a felhasználóknak. Például ha nyaralni készülünk, és nézegetjük a szálláshelyeket, mindig keressük más emberek véleményét, értékelését, hozzászólását a kiszemelt helyről, melyek nagyban befolyásolják a döntéseinket. A [Nielsen egyik kutatása](https://www.businesswire.com/news/home/20120409005607/en/Nielsen-Global-Consumers%E2%80%99-Trust-in-%E2%80%9CEarned%E2%80%9D-Advertising-Grows-in-Importance?ref=blog.fps.hu) szerint a felhasználók 92%-a bízik a más felhasználók által formált véleményben, tehát használni KELL a fogyasztók által generált tartalmakat.

Sas István előadása példákkal illusztrálva nagyon jól rámutatott arra, hogy igenis lehet integrálni a „régi” és „új” média előnyeit. „Formálódik az új (média)fogyasztókkal való együttműködés ABC-je is: Adni! Bevonni! Célozni!”

A két nap számtalan meghallgatott előadása után sem tudtam meg a tutit, de rengeteg információval és tudással lettem gazdagabb. Egy biztos: ha továbbra is versenyben akarunk maradni a fogyasztók kegyeiért, mindenképp őket kell a fókuszba állítani és mindent megtenni értük, hogy boldogok és elégedettek legyenek. Mert ha a fogyasztó elégedett, akkor mi is azok vagyunk.
### Reszponzívan jól
URL: https://blog.fps.hu/reszponzivan-jol/
Last updated: 2026-07-17T08:46:44.000Z
A responsive web design napról-napra terjed, mind többen alkalmazzák. Örvendetes dolog, hogy egyre többen érzik úgy, ki kell szolgálniuk a mobilos, tabletes felhasználókat is, és ehhez web esetén a reszponzív megoldást választják. Az fps-nél lassan 2 éve merültünk el a témában, fejlesztünk rwd site-okat és sok tapasztalatot gyűjtöttünk. Ezzel kapcsolatban írom le néhány gondolatom, mik a buktatók, melyek azok a pontok, melyekkel rendre nem foglalkoznak.

### Mobile first

Ezt hangoztatja mindenki most már. Ellenben érdekes, hogy ki, mit ért alatta. Szerintem nem azt jelenti, hogy elsődlegesen a mobil eszközökre kell fókuszálni. Ott van a desktop és még sok csatorna. A mobilok is csak eszközök. Egy, esetleg két újabb csatorna, amin a felhasználóid ki kell szolgálnod.

**A mobile first egy tervezési és fejlesztési paradigma**. Először mobil: az eleve kicsi képernyőre tervezd a jelenléted, a tartalmad. Segít fókuszálni a lényegre, ezáltal minden sallangot lehánthatsz. Fejlesztési szempontból pedig azért kell a mobil változattal kezdened, mert a projekt végére kevesebb és világosabb lesz a kód (CSS+HTML), ami a gyorsasághoz, illetve a könnyebb karbantartáshoz is hozzájárul.

### Szemléletmód

Amikor responsive web designra esik a választás, akkor a projekt legnehezebb része, hogy az ügyfelet rávegyük erre a gondolkodásmódra. Sőt, továbbmegyek. Az ügynökségen, cégen belül is át kell állni, ami egyáltalán nem könnyű, ugyanis el kell szakadni a hagyományos munkafolyamattól.

Nézd meg az alábbi ábrát. Így néz ki jelenleg a piacon megtalálható iOS és Android eszközök képernyő mérete, képaránya. Durva.

[![Android alatt elképesztően sok képernyőméret van, míg iOS alatt csak pár](https://blog.fps.hu/content/images/2015/12/imagesize.jpg)](http://opensignal.com/reports/fragmentation-2013/?ref=blog.fps.hu)

Egyszerűen az a modell, hogy megtervezzük 320 px, 480 px, 768 px és 1024 px (mobil álló, mobil fekvő, tablet álló, tablet fekvő – desktop) méretekre az oldalt már nem alkalmazható. Olvastam egy nagyon jó mondást ezzel kapcsolatban:

> Kezdd a legkisebb képernyő mérettel, majd méretezd addig, amikor már gagyin néz ki. Na ott kell töréspontot beszúrnod!  
> – Stephen Hay

**Ebből sok minden következik:**

- 320px-re tervezd meg az oldalt, esetleg egy általános tabletre (768px), végül pedig desktopra. A köztes állapotokat teljesen felesleges tervezni, ott szorosan együtt kell működni a fejlesztőkkel és on-the-fly tervezni.
- Fluidnak kell lennie a design-nak, sok esetben teljesen felesleges a hagyományos design tervezés (Photoshop). Egyszerűbb és költséghatékonyabb direkten a böngészőben CSS-sel grafikai designt készíteni.

Az ügyfél? Várja a hagyományos látványterveket. Nézi a prototípust, a fejlesztés különböző állapotait a saját eszközén. Nehéz megértetni vele, hogy sokszor kompromisszumot kell kötnie (a fentiek miatt).

Olvastam mostanában egy [nagyszerű blog posztot](http://www.elezea.com/2013/09/responsive-design-agency-workflow/?ref=blog.fps.hu), melyben az RWD-nél ajánlottan alkalmazandó munkafolyamatot ábrázolt a szerző.

![Iteráció illusztráció](https://blog.fps.hu/content/images/2015/12/workflow.jpg)

### Problémák

Jónéhány rwd site-ot láttam már, ezért pontokba szedtem a tipikus hiányosságokat:

- olvashatatlan szöveg (kicsi betűméret, kontraszt hiánya)
- tappolható felületek méretei nem elég nagyok (min. 1,5 cm*1,5 cm – kb. 44 px*44 px)
- tappolható területek átfedik egymást, könnyen félre lehet tappolni (távolság min. 2 mm – kb. 8 px)
- „retina” kijelzők nincsenek kiszolgálva – homályos, elmosódott ikonok, képek
- beviteli mezőknél a virtuális billentyűzetkiosztás nincs kihasználva (email, tel, number, date, search, url) – csak érdekességképpen az iOS7 Safari mobile már nem támogatja a datetime típust
- érzékeny beviteli mezőknél nincsenek letiltva a böngésző autocorrect, autosuggest, autocomplete funkciói
- nincsenek kihasználva az érintőképernyő, a mobil beépített szenzorainak lehetőségei (swipe, GeoLocation stb.)
- nincsenek közösségi megosztási lehetőségek – belépésnél, regisztrációnál nincs lehetővé téve, hogy közösségi fiókot használjon a felhasználó

Mindezekről a [Mobile Monday rendezvényén](http://www.mobilemonday.hu/?ref=blog.fps.hu) a Sanománál beszéltem.  
Tessék a prezentáció.
### Responsive email, de hogyan?
URL: https://blog.fps.hu/responsive-email-de-hogyan/
Last updated: 2026-07-17T08:46:54.000Z
A [II. Email Marketing konferencián](http://www.emailmarketingkonferencia.hu/?ref=blog.fps.hu) elhangzott rövid előadás szkriptje a responsive email designról. Néhány gondolat a html email tervezésről, pár hasznos tipp és a gmail folyamatos szidalmazása. Dióhéjban.

A világ legreszponzívabb emailje az egyszerű plaintext, azaz a sima szöveges email. Sajnos ezt nem lehet mérni, illetve a képekről, designról is le kell mondani, tehát ez nem megoldás.

[Litmus kutatásából](https://litmus.com/blog/the-how-to-guide-to-responsive-email-design-infographic?ref=blog.fps.hu) azt látni, hogy világszinten 47% a mobilról megnyitott emailek aránya. A konferencián elhangzottak szerint hazánkban 17% ([Protopmail](https://www.google.hu/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCwQFjAA&url=http%3A%2F%2Fwww.protopmail.hu%2F&ei=3JBMUqmaI4fuswb2loDIDQ&usg=AFQjCNGo14V1cC5OQyDsLF4KvDajTcNzbQ&bvm=bv.53537100,d.Yms) adatok), de a kiküldés utáni első órában ez a szám 23%. Kicsit furák nekem ezek a magyar számok. Több konferencia résztvevővel is beszéltem, akik rendre nagyobb számokról számoltak be, egyébként az fps hírlevél – köszönhetően nektek – a világ arányaira hajaz. Egy biztos. Ha az email nincs optimalizálva a mobil eszköz email kliensére, akkor azt a felhasználók 80%-a nyomban törli.

A viselkedési minták ([MailChimp kutatás](http://mailchimp.com/resources/research/email-on-mobile-devices/?ref=blog.fps.hu)), melyek simán ráhúzhatóak a hazai viszonyokra is, azt mutatják, hogy nagyon nehéz megjósolni, hogy a kiküldött emailünk milyen kontextusban éri éppen a felhasználókat.

- 77% minden körülmények között ellenőrzi az emailjeit
- 87% egyben kezeli az üzleti és a személyes levelezését
- 72% ágyban, reggel és este csekkolja a maileket
- 14% tömegközlekedési eszközön teszi ezt
- 12% étteremben, bárban, kávézóban levelezik
- 8% pedig várakozás közben (bank, orvos stb.)
- érdekességként toaletten nem emailezünk, ott inkább a social media felületeit fogyasztjuk :)

![buszmegállóban és a toaletten mobilozó ember illusztráció](https://blog.fps.hu/content/images/2016/01/buszmegallo.jpg)

### Tervezés

- mobile first – segít fókuszálni a lényegre
- tömör, rövid, érhető és világos szöveg
- nem kell telezsúfolni ajánlatokkal a hírleveled, maximum 3–4 ajánlat bőven elég – ne frusztráld a felhasználóid a túl sok választási lehetőséggel
- egyértelmű linkek és gombok
- kontraszt
- tappolható felület mérete megfelelő legyen (1,5 cm*1,5 cm – kb. 44 px*44 px)
- tappolható területek egymástól elég távol kerüljenek (2 mm – kb. 8 mm)
- egyoszlopos megjelenés

Habár meg lehet oldani, hogy több oszlopos email legyen, de egyszerűen nem éri meg a szenvedést, a ráfordítást és szinte biztos, hogy találunk olyan email klienst, ahol nem lesz kielégítő a megjelenés.

Érdemes szimplán a tipográfiára helyezni a hangsúlyt. Vertikális ritmus, egyszerű font méretekkel, white space-szel, színekkel és lineákkal játszani. Ez gyors letöltést, világos és egyértelmű hierarchiát eredményez. Ha fotót, képet akarsz beletenni, akkor gondolkozz teljes szélességben, ami szép is lesz és az életed is megkönnyíti. Ha már az email kliensek fejlesztői erre nem hajlandóak. 

### Grafikai tervezés? Photoshop?

Responsive emailnél? Őszintén? Teljesen felesleges. Egyszerűen, akár egy böngészőben összedobható. Nyilván kell hozzá szépérzék, tipografiai alapismeret.

### Tippek

- ha sok tartalom van az emailedben, azaz jó hosszú lett, tégy a bevezető szöveg után egy tartalomjegyzéket, melyek sima anchor hivatkozással (#) odaugranak a megfelelő pontra
- nyilván remote image-eket használsz (külső helyen tárolt képeket hivatkozol be) – ezeknek töltsd ki az alt tulajdonságát, hogy a képek letöltése nélkül is értelmezhető képet kapjon a felhasználó
- okostelefonokon a social media természetes dolog, ezért érdemes megosztó linkeket tenni az emailedbe
- a mobilos email kliensek az email lista képernyőn megmutatják a html tartalom elejét, tehát ne kezdd a html email azzal, hogy „ha az email nem jól jelenik meg, akkor nyissa meg a böngészőjében” – sokkal inkább valami figyelemfelkeltőbb szöveget tégy oda (melyet akár display:none-nal el is rejthetsz)

![iOS, Android, Windows Phone, Backberry eszközök egy képen illusztráció](https://blog.fps.hu/content/images/2015/12/mobile.jpg)

### Támogatottság

A mediaquery-t, ami egy igazán jó responsive megoldásnak az alapja minden okostelefon beépített email kliense támogatja (kivéve Windows Phone8). Ellenben sajnos a Gmail, a Mailbox és a Yahoo mail egyetlen operációs rendszeren sem támogatják.

Létezik egy sima [százalékos megadással történő megoldás](http://zurb.com/playground/responsive-email-templates?ref=blog.fps.hu), mely igazából sokban csökkenti a lehetőségeket, viszont működő alternatíva Gmail, Mailbox és Yahoo Mail esetében is. Ennek a finomhangolás hiánya melletti hátránya, hogy Outlook 2007, 2010 és 2013 desktop email kliensek alatt szétcsúszik a design a kliens széléig.

A megfelelő megoldást érdemes a célközönségünk, a hírlevél listánk felhasználói szerint megválasztani. Az fps hírlevél a mediaquery-re támaszkodik, tehát sajnos a Gmail appot és Mailbox appot mobilon használók nem az optimalizált felületet kapják. Esetünkben az Outlookot használók tábora nagyobb, mint a Gmail apposoké és sok az IOS-t futtató tag.

**UPDATE – 2013.11.04.**

Közben olvastam két nagyszerű posztot, melyeket úgy gondoltam mindenképp be kell tennem ide.

Elsőként az [Outlook 2007 feletti verziókra van egy nagyszerű hack](http://blog.fogcreek.com/responsive-html-emails-a-different-strategy/?ref=blog.fps.hu), amit érdemes alkalmazni:

```markup

<!--[if (gte mso 9)|(IE)]>
  <table width="540" align="center" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td>
<![endif]-->
[EMAIL BODY HERE]
<!--[if (gte mso 9)|(IE)]></table>
      </td>
    </tr>
  </table>
<![endif]-->

```

Másodsorban pedig, ha szép gombot szeretnél a hírleveledbe, akkor használd a Campaign Monitor által fejlesztett [gomb generatort](http://buttons.cm/?ref=blog.fps.hu). Nagyon jó!

#### Miért Gmail szidalmazás?

Mert a mobil forradalom egyik nagy képviselője, a Google, érthetetlen okokból olyan email klienst fejleszt, mely nem támogatja megfelelően a mobilos html email megjelenítést. Azt kell mondjam, hogy egy html email sablon készítőnek a Gmail most olyan, mint az IE6-IE8 a webfejlesztőnek. Reméljük, azért változni fog ez is.

### Végül

Sok teszt, sok teszt, sok teszt. Arra azért figyelj, hogy a szuper mobilra optimalizált hírleveledben található linkek hova vezetnek. Azok a tartalmak is jól jelennek meg az okostelefonon? Ha igen, akkor hajrá!

*UPDATE*  
A Google végre 2016\. szeptember végére megígérte, hogy [Gmailben támogatni fogja a media query-k használatát](https://www.campaignmonitor.com/blog/email-marketing/2016/09/responsive-email-support-in-gmail-is-coming/?ref=blog.fps.hu)! \\o/
### Erősítsd webshopodat email marketinggel
URL: https://blog.fps.hu/erositsd-webshopodat-email-marketinggel/
Last updated: 2026-07-17T08:47:03.000Z
Minden vállalkozás alapvető célja, hogy minél hamarabb megtérüljön a befektetés, és minél hamarabb bevételt, profitot termeljen. A sikeres vállalkozók tudják, hogy pénzt csak pénzből lehet csinálni. Általában rengeteg időt, energiát és pénzt fordítanak arra, hogy megszülessen az a termék vagy szolgáltatás, amelyet a későbbiekben értékesíteni szeretnének. Ekkor jön el az a pont, hogy el kell dönteni, milyen marketing eszközt válasszon az értékesítés támogatásához: online vagy offline hirdetés, PPC kampány, social media megjelenések, PR-cikk, eDM, és még sorolhatnám tovább.

Az email marketing nem új keletű dolog, régóta jelen van a piacon. Az email marketing lehetőséget nyújt arra, hogy közvetlen kapcsolatot építs ki a vásárlóval, ezzel bizalmat építesz az oldalad iránt, melyet a vásárlód a hűségével fog honorálni. Íme néhány tanács ahhoz, hogyan tudd az ecommerce tevékenységedet magasabb szintre hozni az email marketing segítségével.

### Növeld a konverziót szegmentálással!

Hogyan tudsz még több konverziót elérni hírlevél segítségével? Felejtsd el azt, hogy hetente kiküldesz egy általános emailt a teljes adatbázisra. A heti hírlevél arra jó, hogy a vásárlóid látókörében maradj, de ettől még nem fognak vásárolni.

A webshopok a vásárlások során számtalan információt rögzítenek az egyes vásárlókról. Ezen adatok felhasználásával szegmentálni tudod az adatbázisodat, és az egyes vásárlói csoportoknak célirányos (eseményvezérelt) ajánlatokat tudsz küldeni. Például mobiltelefonokat és tartozékokat forgalmazol. Az egyik ügyfeled egy mobiltelefont vásárol. A vásárlást követően küldesz neki egy olyan hírlevelet, melyben a vásárolt készülékhez kapcsolódó tartozékokat kínálsz neki. Ugye, hogy jóval nagyobb az esélye annak, hogy fog még valamit vásárolni, mintha ugyanezt a hírlevelet kiküldenéd a teljes adatbázisra?

Ilyen eseményvezérelt emailek lehetnek például:

- születésnapi köszöntők
- vásárlás utáni elégedettség mérés
- a vásárolt termékhez/szolgáltatáshoz kapcsolódó egyéb dolgokról való értesítés
- hűségprogrammal kapcsolatos információk, stb.

Ezek az automatizált emailek személyre szólóak legyenek, a nevükön szólítsák meg az ügyfeleket, és tartalmazzon olyan konkrét információt, amelytől az ügyfél azt érezze, fontos számodra, ezzel is erősítheted a bizalmat és a hűséget.

### Kérj visszacsatolást az ügyfeleidtől!

Használd az email marketinget arra, hogy megtudd, mit gondolnak az ügyfeleid a vásárolt termékről/szolgáltatásról. Egyrészt ez egy nagyon jó visszacsatolás számodra, másrészt, ha felteszed a termék mellé ezeket a visszajelzéseket, bizalmat építhetsz a leendő és a már meglévő ügyfeleid felé. Az új vásárlóknak különösen fontos mások visszajelzése. Akár jutalmazhatod is őket, például egy kedvezményes kuponnal a következő vásárláshoz. Ezeket az emaileket is automatizálhatod, a vásárlás után x idővel kiküldöd ezt a levelet. Ezekkel az ügyfelek által adott visszajelzésekkel optimalizálhatod a termékoldaladat is. Egyrészt tartalmazni fogja az összes olyan információt, amely szükséges a vásárláshoz, másrészt ismételten csak bizalmat építhetsz, pl. Ezt a terméket már 120-an értékelték/kommentelték, stb.. Vagy akik ezt a terméket vásárolták, ezt és ezt a terméket is megvették hozzá, stb..

További előnye az ügyfél visszajelzéseknek, hogy maguk az ügyfelek generálják az egyedi tartalmat az oldaladra, így a keresőoptimalizálást is aktívan segítik. Ez a plusz tartalom vonzóbbá teszi a vásárlást az új ügyfelek számára.

### Van ~~élet~~ email a konverziókon túl is

Az email marketinget nemcsak a konverziós célok eléréséhez használhatod, hanem edukációs céllal is. Például a megrendelést követően küldesz egy vásárlást visszaigazoló emailt az ügyfelednek, mely nemcsak a vásárlásra vonatkozó információkat tartalmazza, hanem teljes körűen tájékoztatod a további teendőkről, pl. mit tegyen, ha x napon belül nem érkezik meg a csomag, ha online letölthető a termék, mi a teendője, hol találja a GYIK-et vagy a súgót, kihez fordulhat, ha problémája van, stb.. Ezek ugyan nem nagy dolgok, de sokat segíthetsz az ügyfeleknek abban, hogy egyedül is elboldoguljanak, és pozitív érzésekkel térjenek a későbbiekben vissza az oldaladra. A jó kommunikáció a siker egyik titka!

Szintén egy nagyon jó lehetőség a proaktív emailek küldése. Ezekhez szintén a vásárlás során tárolt adatokat hívhatod segítségül. Sokféleképpen lehet kihasználni az ebben rejlő lehetőségeket. Pl. az egyik ügyfeled 60 db-os pelenkacsomagot vásárolt. Nagyjából kiszámolható, hogy mennyi idő alatt fogy el (ha már többször is vásárolt az ügyfél, akkor még könnyebb a dolgod) a pelenka. A várható elfogyás előtt néhány nappal küldesz neki egy emlékeztető emailt, hogy hamarosan esedékes lesz újabb csomag vásárlása, és a levélből kattintva már rendelheti is a következő csomagot.

### Inaktív ügyfelek aktivizálása

Minden ügyféladatbázisnak van egy olyan része, amelyben az inaktív felhasználók találhatóak. Inaktivitásuk több okból adódhat: csak kíváncsiságból beregisztráltak, de nem vásároltak semmit, vagy egyszer vásároltak, és azóta se jártak az oldaladon, stb.. Ők azok, akik csak a statisztikákban mutatnak jól, de bevételt nem termelnek.

Őket mindenképp érdemes megpróbálnod aktivizálni! Próbáld meg szegmentálni őket, kik azok, akik már vásároltak nálad, őket megszólíthatod valamilyen akciós/kedvezményes ajánlattal, és kik azok, akik még nem is vásároltak tőled, nekik is küldhetsz egy speciális, csak az ő részükre szóló ajánlatot.

Ha csak néhány ügyfelet sikerül aktivizálnod, már nyert ügyed van, nő a bevételed, az oldalad forgalma, és akár még visszatérő vásárló is lehet belőle.

De mi a helyzet akkor, ha ezek a levelek se váltanak ki semmilyen reakciót? Két lehetőséged van:

- Távolítsd el őket az adatbázisból, így nem pazarolsz rájuk több energiát, és nem áll fenn a veszélye annak, hogy a számukra folyamatosan küldött hírleveleket spamnek jelöljék, amely a lehető legrosszabb számodra
- Tedd őket egy külön csoportba, így pontosan el tudod különíteni egymástól az aktív és inaktív ügyfeleket, ráadásul ezzel tisztítod is az adatbázisodat, jobbak lesznek a konverziós értékek.

Akármelyik lehetőséget választod, az eredmény ugyanaz lesz: tisztább, minőségibb ügyfél adatbázis.

### Jutalmazd a hűséges ügyfeleket!

Időközönként jutalmazd az igazán hűséges ügyfeleidet! Találd ki, mi az a határ, ami felett automatikusan megajándékozod az ügyfeleidet. Lehet ez egy bizonyos összeg feletti vásárlás, bizonyos számú vásárlás, bizonyos gyakoriságú vásárlás, vagy bármi más. Amikor elérték az általad megszabott feltételeket, automatikus emailt küldesz nekik a kapott jutalomról/kedvezményről, és az ezzel kapcsolatos információkról.

A jutalom pedig gyakorlatilag bármi lehet: egyszeri kedvezmény, folyamatos kedvezmény, ingyenes kiszállítás, hűségpontok gyűjtése, nálad vagy máshol felhasználható kupon stb. Itt viszont egy dologra mindenképp figyelj: ha B2B vásárlóid is vannak, akkor úgy találd ki a jutalmazást, hogy ők is élni tudjanak vele.

### Akkor mit is kell tennem?

Legelőször is megtervezni az email marketing stratégiád, mit, mikor, kinek és hogyan kommunikálj. Ne sajnáld rá az időt és az energiát, ugyanis ha egyszer jól megcsinálod, a későbbiekben minimális ráfordítást igényel. Próbálj minél több visszacsatolást szerezni az ügyfelektől, a hűséget pedig jutalmazd. Az adatbázisodat tartsd karban, az inaktív ügyfeleket próbáld aktivizálni. És ne keseredj el, ha elsőre nem sikerül jó eredményeket elérni. Kísérletezz, próbálkozz, tesztelj bátran, és a siker nem marad el.
### Házi SEO ellenőrző lista
URL: https://blog.fps.hu/seo-checklist/
Last updated: 2026-07-17T08:47:15.000Z
A keresőoptimalizálás elsőre nem tűnik bonyolult feladatnak. Van egy lista, amin végigmenve be kell állítani dolgokat és kész. Ez tényleg nem nagy ördöngösség. Csak épp azt felejtik el sokan, hogy mindezt úgy kell csinálni, hogy a folyamatosan változó kereső algoritmusok ellenére is mindig jó eredményeket kell produkálni. És ez az igazi kihívás!

A keresőoptimalizálás jóval bonyolultabb annál, mint amilyennek látszik. És nem az elvégzendő feladatok miatt, hanem a keresőalgoritmusok folyamatos változása miatt. Van, amikor egy új dolog kerül be az algoritmusba, van, amikor egy évek óta meglévő paraméter esik ki, és ami a leggyakoribb, a meglévő paraméterek súlyozása változik. Például míg néhány évvel ezelőtt ha a megfelelő kulcsszavakat beírtuk meta keywordsnek, máris jó pozícióba kerülhettünk a keresőkben. Ma már ezt a tag-et nem is veszi figyelembe a rangsorolásnál a keresőrobot.

Ha keresőoptimalizálásról van szó, gyakran felmerül a kérdés: Hol is kezdjem? Ha például felteszel egy új tartalmat a weblapodra, már meg is tetted az első lépést. A SEO nem egy egyszer elvégzendő feladat, ez egy folyamat, melynek az elején több feladat van, majd folyamatosan kell dolgozni az eredmények javításáért illetve fenntartásáért. Amíg működik a weboldalad, mindig lehet rajta dolgozni, hogy még jobb eredményeket érjen el a keresőkben.

Az alábbiakban [Ben Norman infografikáját](http://www.bitrebels.com/technology/ultimate-seo-checklist-infographic/?ref=blog.fps.hu) alapul véve összeállítottam azt a bizonyos listát, amely alapján fel tudod mérni, hogyan is áll az oldalad keresőoptimalizáltsága. A lista hasznos tippeket is ad ahhoz, hogy a megfelelő SEO alapokkal rendelkezhessen a weboldalad, melyet a poszt végén PDF-ben is letölthetsz.

### SEO checklist

#### Technikai SEO

- Felhasználó és keresőbarát URL-eket használsz? (pl. [www.valami.hu/akarmi/barmi](http://www.valami.hu/akarmi/barmi?ref=blog.fps.hu))
- Minden oldaladon egyedi címet (Title) használsz?
- A title nem hosszabb, mint 70 karakter?
- Minden oldaladon egyedi leírásokat (description) használsz?
- A leírás nem hosszabb 160 karakternél?
- A leírás összefüggő szöveg, mely tartalmazza az oldal releváns kulcsszavait?
- Van robots.txt fájl? (Ha nincs, célszerű pótolni)
- Van validált sitemap az oldaladhoz? (Ha nincs, mindenképp pótold!)
- Használsz 301/302-es átirányításokat a megszűnt/ideiglenesen nem elérhető tartalmaknál? (Ha nem, használj mindenképpen)
- Használsz H tageket a tartalmakban? (főcím, közcím, egyéb címek)
- Képeknél használod az alt és title elemeket?
- Időnként szoktad ellenőrizni az oldal betöltődési sebességét? (Ha túl lassú, optimalizálni kell a forráskódon is)

#### Navigáció és használhatóság

- Minden link működik az oldalon?
- Minden kép megfelelően jelenik meg?
- A táblázatokat, grafikonokat, stb. tartalmazó képek nagyíthatóak?
- Megfelelően jelennek meg az oldalon a videók?
- Jól olvasható a tartalom?
- Könnyen navigálhatnak a felhasználók az oldalon?
- Vannak kapcsolódó tartalomra vivő linkek?
- A legnépszerűbb böngészőkben megfelelően jelenik meg az oldal?
- Ugye nincsen felesleges flash tartalom és JavaScript?
- Van oldaltérkép?
- Használsz 404-es oldalt?

#### Tartalom

- Nincs duplikált tartalom az oldalon?
- Ha mégis van, be van a canonical URL állítva?
- Vannak helyesírási/elgépelési hibák az oldalon? (Ha igen, javítani kell!)
- Minden oldalon az oldal céljának és üzenetének megfelelő tartalom van?
- Megfelelő a tartalmak kulcsszó sűrűsége?
- Vannak belső keresztlinkelések az oldalakon?
- Kerül fel rendszeres időközönként friss tartalom? (minimum havi 1)
- Van(nak) social media megosztási lehetőség(ek)?

### Letölthető, nyomtatható változat

Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak, vagy az online marketingesnek!

[Töltsd le a checklistet (0 letöltés)](https://www.fps.hu/presentations/seo-checklist-fps.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### Ezért hagyom el a website-od 10 másodpercen belül
URL: https://blog.fps.hu/okok-amiert-elhagyom-az-oldalad/
Last updated: 2026-07-17T08:47:25.000Z
Chris Lake posztja adta az ihletet, hogy összegyűjtsük azon problémákat, melyek mindegyike arra készteti a felhasználót, hogy nyomban kilépjen a zseniális web site-odról. [Chris listáját](http://econsultancy.com/hu/blog/63207-22-more-reasons-why-i-ll-leave-your-website-in-10-seconds?ref=blog.fps.hu) alaposan átszabtuk, meghúztuk és jónéhány ponttal kiegészítettük. Lehet érdemes átküldened a webfejlesztő csapatodnak az alábbiakat? Nyugodtan tedd meg, a zsebedre válik! Jó mazsolázást.

### Lassú betöltés

A sebességoptimalizálás kiemelkedően fontos, különösen mobil web esetén. Türelmetlen vagyok, nincs időm az oldaladra. Ha lassú vagy, faképnél hagylak.

### Fejlesztés alatt, üres oldal

Feljesztés alatt van a web site oldala, funkciója, jelenleg nincs cikk, hamarosan feltöltitek, akkor minek teszed ki? Dobbantok.

### Ha mást kapok, mint amire számítok

Socialben, vagy SEO-ból bekeveredem az oldaladra, ahol valami egészen más fogad, mint amire számítok, nyomban távozom. Egy jó példa a [www.nissan.com](http://www.nissan.com/?ref=blog.fps.hu).

### Gagyi design, használhatatlan oldal

Ezen nincs túl sok magyaráznivaló. A csillogó animált gifek, az izgő-mozgó flash menü és a körbevágott ember a bizalmamat lerombolja. Ha meg azt sem tudom, hova, mire kattinthatok, nem ismerős egyetlen menüpont név sem, akkor padlógázzal tépek tovább.

### Nem tudom elolvasni a szöveget

Ha olyan kicsik a betűk, hogy szemüveggel is hunyorgok, vagy olyan kicsi a kontraszt, hogy 120 fokból kell néznem a monitort, hogy lássak valamit, akkor biztosan elhúzom a csíkot.

### Az arcomba nyílik valamilyen layeres popup ablak 1 mp után

Ez a legidegesítőbb. Nem érdekel a hírleveled, majd eldöntöm én, hogy fel akarok iratkozni, vagy sem. Hidd el, a legjobb ajánlatod sem érdekel és nem akarom lájkolni a facebook oldalad sem! Felnyitod? CLOSE!

### Cookie figyelmeztető, melyet nem lehet bezárni

Az EU-ban ugyebár kötelező a felhasználók figyelmének felhívása a cookie használatra. Na de az, hogy nem ezt nem lehet eltüntetni? Csőváz!

### Hirdetés hegyek

Belépek az oldalra és mást se látok, csak mindenhol villogó hirdetéseket (bannerek, Google AdSense zónák), melyek közül kihámozni sem tudom, hova kerültem. Csá csumi.

### Automatikusan lejátszódó videó

Szeretném eldönteni, hogy megnézem az elképesztően zseniális videód, vagy sem. Ne indítsd el, mert valószínűleg üvölteni fogok és újraindítom a gépet.

### Automatikusan lejátszódó zene, hangok hover állapotra

Mindent überelsz ezzel. Az ellenértéke egy kövér bezárás klikk, tapp.

### Visszaélés az üres területekkel

Sok portálon találkozom azzal a megoldással, hogy az üres területekre kattintva új ablakot nyit a böngésző és behoz valami irreleváns oldalt. Mindkettőt küldöm a süllyesztőbe.

### A cikkeknél, posztoknál nincs dátum

Mégis mikor született a lenyűgöző cikked, posztod? Egyáltalán releváns még, aktuális? Ne rejtsd el ezt az infót, mert sebtében futok tovább.

### A megúszós kapcsolat pont

Ha kiteszel egy kapcsolat pontot, akkor elvárható, hogy a link egy új oldalt nyisson, ahol a kapcsolati adataid fel vannak tüntetve, jó esetben egy űrlap is található itt. Ne tegyél egy szimpla mailto: linket rá, mert lelépek!

### Website, ami letilt billentyűket, egér jobb kattintást

Ne tiltsd le a space-t, a kurzor nyilakat, az egér jobb gombjával kattintást, mert már ott sem vagyok.

### Kizárólag Social belépés van

Ugyan nagyon hasznos és szükséges is a Facebook, Google+, twitter login használata, de ne kényszeríts rá a használatukra. Ha épp olyanom van és a kamu email címemmel akarok regelni és nem lehet, olajra lépek.

### Jelszó fetisizmus

„A megadott jelszó nem megfelelő. Kérlek, használj benne kis és nagy betűt, csak alfanumerikus karaktereket, legyen benne legalább egy szám és írd bele, hogy hány éves a kapitány!” Bye-bye

### Nem optimalizáltad az oldalad mobilra

Nem magyarázom, szeretném használni a web site-od mobilról is, ha nagyítgatásra késztetsz, akkor felszívódom.

### Mobil web site, ami a mobil app letöltésével indít

Ajánlom figyelmedbe a [WTF Mobile Web tumblrt](http://wtfmobileweb.com/?ref=blog.fps.hu). Mobil webnél, mindig jusson eszedbe: Content first! Navigation second! Ha ezt az elvet megsérted, azonnal kilépek.

### Szeparált mobil web site, amiről nem lehet átváltani desktop verzióra

Ha már valamilyen oknál fogva szeparált mobil web site-ot fejlesztettél és történetesen a desktop változathoz képest csökkentett funkcióval, tartalommal hoztad létre (ezt se tedd), akkor legalább adj lehetőséget átváltani a desktop változatra. Ha nem találom, eltolom a biciklit!
### Landing page tippek
URL: https://blog.fps.hu/landing-page-tippek-konverzio/
Last updated: 2026-07-17T08:47:34.000Z
Belefutottunk egy nagyszerű, jól összeszedett checklistbe, ami mindenkinek segítségére lehet, mikor a landing page-ét (landoló oldalát) tervezi, vagy már elkészült vele. Lehet azt hiszed, hogy az oldalad nagyon jól konvertál, de ha végigmész ezen a listán, akkor biztosan találsz olyan pontot, amin még lehet csiszolni.

A listát az [unbounce-tól Oli Gardner](http://unbounce.com/landing-pages/checklist/?ref=blog.fps.hu "Checklist for Landing Page") állította össze, mi pedig lefordítottuk nektek, kicsit persze belenyúltunk itt-ott, hogy még jobb legyen. A poszt végén a listát nyomtatható PDF verzióban (3 oldal) letölthetővé tettük, hogy könnyebb legyen a listával végzett munka.

### Landing page checklist

- A landoló oldal főcíme egyezik a hirdetésed üzenetével?
- A landoló oldalad egyetlen célra fókuszál?
- Bárki megérti a mondanivalót 5–10 másodperc alatt? (teszteld le!)
- Egyértelmű, hogy ki a céged és hogy mit csinál? (logó és szlogen)
- Szerepel a főcím alatt olyan leírás, ami fokozza a főcím hatását?
- Használsz pontokba szedett listát, mely bemutatja a terméked/szolgáltatásod előnyeit?
- Használsz releváns, eredeti fő képet vagy videót, amely bemutatja a terméked használat közben, vagy olyan ember(eke)t, akik igénybe veszik a szolgáltatásod?
- Az üzeneted eljut a célszemély(ek)hez 30mp alatt? (Olvasd fel valakinek és figyeld meg, hogy megérti-e?)
- A főcímed választ ad a kérdésre: „Miről szól ez az oldal?“
- Eltávolítottál minden az oldalról kifelé mutató linket (pl. navigáció)?
- Megmutatja a landoló oldalad, hogy a terméked/szolgáltatásod mitől egyedi (USP)?
- Ugye a szöveg elsősorban az előnyökre és nem a tulajdonságokra fókuszál?
- Meg tudod állni, hogy szükségtelen információt kérj az űrlapon?
- Közlöd a feliratkozóval, hogy mit kap, ha végigmegy a folyamaton? (kedvezmény, ajándék stb.)
- Megjelenítesz vásárlói referenciát és véleményeket, melyek a terméket/szolgáltatást dicsérik?
- Több különböző kapcsolatba lépési lehetőséget kínálsz (telefon, email, élő chat)?
- Világos, hogy mit kapnak a látogatók, ha klikkelnek a CTA (Call to action - cselekvésre buzdítás) gombodon?
- Professzionális dizájnnal rendelkezik a landoló oldalad?
- Megegyezik a landoló oldal grafikai stílusa a hirdetés stílusával?
- Megegyezik a landoló oldal stílusa a web site-od, vagy a branded stílusával? (Akkor érdekes, ha a CTA után a látogató odakerül) Használsz layeres popup megoldást (pl. lightbox) az extra információk megmutatására az oldal elhagyása nélkül?
- Szerepeltetsz adatvédelem és felhasználási feltételek linkeket?
- Adsz bemutatót, mintát (pl. első fejezet, mint előnézet) az ajánlatodból, ha ez lehetséges?
- Tettél ki tanúsítvány, garancia, biztonságtechnikai, partner logókat (pl. Verisign, bank stb.)?
- Kijelentéseid és állításaid ellenőrizhetők?
- Megismétled az ajánlatod az űrlapon, hogy hangsúlyozd mi a célja az űrlap kitöltésének?
- Használsz bármilyen vizuális trükköt, hogy felhívd a figyelmet a CTA gombodra? (pl. nyilak)
- Elég nagy a CTA gombod, ahhoz hogy akár 2 méterről is látható legyen?
- Használsz kontrasztot a CTA gombodnál, hogy elüssön az oldal többi elemétől?
- Feltünő helyen van a CTA gombod, közel az oldal tetejéhez?
- Tettél az adatvédelmi szabályzatodra mutató linket az űrlap email cím mezőjének közelébe?
- Az űrlap email cím mezőjénél tudatod a látogatóval, hogy nem fog kapni reklámot, spamet és nem adod ki harmadik félnek a címét? (már ha tényleg nem)
- Használsz megerősítő oldalt, amely a feliratkozót további instrukciókkal látja el? (oszd meg, kövess minket, töltsd le az ingyenes ekönyvet, regisztrálj a webinarra)
- Ha az ajánlatod időben korlátozott, egyértelmű a látogató számára, hogy sietnie kell?
- Ugye különálló landoló oldalakat hoztál létre az egyes forgalmi forrásokhoz (email, social, PPC) és figyeled, hogy melyik konvertál jobban?
- Ha videót használsz, akkor ugye nem indítod el a lejátszást automatikusan?
- A videód cselekvésre buzdítással (CTA) végződik?
- A videód első 10-15 másodpercéből kiderül miről szól és felkelti a figyelmet, hogy végig is nézzék azt?
- CTA gombból csak egyet használsz? (Ha hosszú az oldalad, akkor okés, ha ismétled)
- Ha webinarra iratkoztatod fel az embereket, megmutatod, hányan regisztráltak már?
- Ugye nem használsz bezáráskor megjelenő popup ablakot?
- Végzel A/B tesztelést az oldalakon?
- Gyűjtesz be visszajelzéseket az ügyfeleidtől, hogy felállíthasd a következő teszt esetet?
- Ha több lépésből áll a folyamatod, egyértelműen kommunikálod azt a látogatók számára? (30 másodperc, 3 lépés stb.)
- Optimalizáltad a landoló oldalad, hogy a Quality Score-od (QS) 7 feletti legyen PPC kampányodhoz?
- Külön landoló oldalt használsz minden promócióhoz, kampányhoz?
- Tesztelted a rövid és hosszú verziókat, hogy megértsd mennyi információra van szüksége a látogatóidnak, hogy jól konvertáljanak?
- A landoló oldalad követi az egységesség alapelvét, amikor az oldal minden eleme egy dolog bemutatására fókuszál?
- Követted Steve Krug utasítását? Távolítsd el a szöveg 50%-át, majd töröld ki a maradék felét, hogy elérd a maximális egyszerűséget és tisztaságot.
- Ugye a CTA gombod felirata nem „Kattints ide“ vagy „Elküld“?
- Az űrlapod egy kiemelt (pl. színes hátterű) dobozban helyezkedik el, és ezáltal kiemelkedik az oldalból, mint a legfontosabb elem?

### Letölthető, nyomtatható változat

Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak, vagy az online marketingesnek!

[Töltsd le a PDF változatot (0 letöltés)](https://www.fps.hu/presentations/landing-page-checklist-fps.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### Ecommerce SEO tippek
URL: https://blog.fps.hu/e-commerce-seo-tippek/
Last updated: 2026-07-17T08:47:45.000Z
Nyitottál egy webshopot, de jóformán a családon kívül senki sem látogatja? Vagy kénytelen vagy folyamatosan hirdetni, hogy legyen némi forgalmad és bevételed? Íme, néhány hasznos tanács, melyekkel organikusan is erősítheted a webshopod forgalmát.

### Meta tagek

A Title az egyik legfontosabb elem, mivel nemcsak a keresőrobot, de a látogató is ezzel találkozik legelőször. A legfontosabb kulcsszavat lehetőleg mindig tartalmazza. Webshopok esetében ez a legtöbb esetben a termék neve. Ha a terméknek nincs rendes megnevezése (pl. A-210-i), akkor célszerű azokat a kulcsszavakat használnod a Title-ben, ahogyan azt a látogatók ismerik és keresik.

A description szövegnek elsősorban a keresők találati lista oldalon való megjelenésénél van jelentősége, ezzel tudod bevonzani a látogatókat az oldaladra. Ne használj sablon description szöveget! Vagy a termék adatlap adataiból automatikusan generáltasd le, vagy használj [mikroformátumokat](https://blog.fps.hu/post/36584399122/mikroformatumok-seo). Mikroformátumok segítségével például meg tudod a leírásban jeleníteni az árat, amely rögtön kattintásra ösztönözheti a látogatókat, akik potenciális vásárlókká válhatnak.

### Képek, linkek

A felhasználók szeretik jól megnézni az adott terméket, mielőtt megvásárolnák. Jó minőségű képeket használj, akár többet is egy-egy termék bemutatásához. Arra viszont ügyelj, hogy a képek alt és title tag-jei is meg legyenek adva, a képen lévő tartalomnak megfelelően. Ugyanis a felhasználók hajlamosak kép alapján megkeresni a vásárolandó terméket, a jól megadott kulcsszavakkal ebből a csatornából is be tudod vonzani őket. Az oldalon lévő belső és külső linkek anchor text-jei is legyenek kitöltve, ezzel is növelve a kulcsszósűrűséget.

![Chrome DevToolsban HTML kód részlet képernyőkép](https://blog.fps.hu/content/images/2016/01/forras.jpg)

### H tagek

Ecommerce oldalak esetén ez egy elég kényes pont. Mielőtt minden termék adat feliratot beállítanál valamilyen heading elemmel, gondold végig, ezek közül mi az, ami tényleg kulcsszó, és mi az, ami nem. Pl. ezek a szavak: típus, méret, leírás, megjegyzés nem kulcsszavak. Attól természetesen ki lehet formázással emelni az oldalon, de felesleges H-taget használni. Itt is érvényes a kevesebb néha több elv. Csak olyan szavakat, kifejezéseket vegyél Heading elemnek, amelyek ténylegesen kulcsszavak.

### Mikroformátumok

A mikroformátumok használatának is egyre jelentősebb szerepe van a keresőoptimalizálásban. Egyrészt segítik a keresők eligazodását az oldalon (szemantikus web), másrészt forgalomterelő hatása sem elhanyagolható (lásd description.) A mikroformátumok kiválóan alkalmazhatóak a termék adatlapokon, illetve ha van fizikai üzlet/üzletek, azok elérhetőségeinek megadására is. (Korábban írtam [egy posztot a mikroformátumokról](https://blog.fps.hu/mikroformatumok-seo/))

### URL struktúra

Használj kulcsszavas, keresőbarát URL-eket! Webshopok esetén mindig felmerül a kérdés, hogy oké, de vannak azonos nevű termékek, amelyek pl. méretben, kiszerelésben stb. különböznek csak, és ugyebár két termék nem lehet azonos linken. Erre is van megoldás.

Rossz megoldások:

/product.php?id=22333  
/category/product/22333.html  
/id=22333.php

Jó megoldások:

/noi-labbelik/szandalok/szandal-22333  
/szandalok/szandal-22333.html

Illetve az URL-eknél nagyon fontos, hogy egy tartalom ne legyen elérhető két URL-ről, mivel ez tartalom duplikációnak számít, melyet a keresők keményen büntetnek. Figyelj arra, hogy az oldal ne legyen külön elérhető www és www nélküli változatban, automatikusan irányítson át egyikről a másikra. Ugyancsak figyelj oda arra, hogy az URL végén lévő / jellel vagy a nélkül is csak egyféleképpen szerepeljen, a másik variáció legyen automatikusan átirányítva.

![Breadcrumbs példa – Kezdőoldal » Irodalom » Világirodalom » Orlando](https://blog.fps.hu/content/images/2016/01/breadcrumbs-1.jpg)

### Breadcrumbs

Fontos, hogy a látogatók tisztában legyenek azzal, merre járnak épp az oldalon belül és könnyen tudjanak navigálni. Erre nagyon jó eszköz a breadcrumbs. A navigáción kívül a belső linkkapcsolatokat is erősítik, mely nagy segítség a keresőrobotok számára. A breadcrumbs-ra is alkalmazható a mikroformátum.

### Átirányítások

Webshopok esetén különösen fontosak az átirányítások, ugyanis a látogatók zöme közvetlenül egy-egy termékoldalra érkezik a keresőkből vagy a hirdetésekből, így elég kellemetlen, ha 404-es oldalra érkezik, mert az adott termék már nincs a kínálatodban. Soha ne törölj termékoldalt, használj 301-es vagy 302-es átirányítást annak megfelelően, hogy állandó vagy ideiglenes átirányításról van szó. Próbáld meg minimalizálni a 404-es oldalak számát, a keresők nem díjazzák a sok nem létező URL-t.

### Tartalom optimalizálás

A tartalom optimalizálás szintén egy sarkalatos pontja az ecommerce keresőoptimalizálásnak. A tartalmi problémák igen sokrétűek lehet:

- nincs termékleírás
- a gyártó ragaszkodik az általa adott termékleíráshoz, viszont minden versenytárs is ezt használja
- sok helyen kapható a termék és nehéz róla újat írni - egy termék többféle színben, méretben, kiszerelésben, stb. található a webshopban, viszont mindegyikhez azonos a termékleírás

SEO szempontból egyik sem jó. Az első esetben azért, mert tartalom nélkül nehéz optimalizálni, a többi esetben viszont a tartalom duplikáció esete áll fent, amit büntethetnek a keresők. Ezekre a problémákra sablon megoldás nincs, egyedileg kell mérlegelni, hogy milyen megoldás áll legközelebb a céljaidhoz.

Egyik megoldási lehetőség lehet az egyedi tartalom készítése, de ez egy több száz vagy több ezer terméket forgalmazó webshop esetében nem igen kivitelezhető. Másik megoldási lehetőség a canonical tag használata, így megmondjuk a keresőknek, hol található az eredeti tartalom, így elkerülhetjük a büntetést, viszont nem segít a keresési pozíció javításában. És vannak egyedi megoldások is, ezek mindig az adott szituációtól függnek.

### Oldalbetöltődési sebesség

Nemcsak a felhasználók miatt fontos a gyors oldalbetöltődés, hanem a keresők miatt is. Szintén rangsorolási faktor az oldalbetöltődés. Különböző ingyenes eszközök is rendelkezésedre állnak a sebesség tesztelésére, pl. [webpagetest.org](http://www.webpagetest.org/?ref=blog.fps.hu)

![Sitemap.xml részlete](https://blog.fps.hu/content/images/2016/01/webshop.jpg)

### Oldaltérkép, sitemap

Az oldaltérkép a látogatóidnak, míg a sitemap a keresőrobotoknak ad útbaigazítást a webshopoddal kapcsolatban. Attól függően, hogy hány termék található a webshopodban és milyen gyakran változik a készleted, választhatsz automatikusan generálódó xml-t, vagy fix sitemapet.

### Ugye nem sokkoltalak?

Elég sok mindent felsoroltam, amelyekre figyelni kell, de ezeken kívül még számos dolog van, amelyek többé-kevésbé befolyásolják a keresési rangsort. A legfontosabb rangsorolási faktor a tartalom, erre kell a legnagyobb figyelmet fordítanod. Ha már üzemelő webshopod van, a poszt jó alapot ad ahhoz, hogy átnézd vagy átnézesd az oldalad, és az esetleges problémákat javítsd. Ha viszont még csak most tervezel ecommerce site-ot készíteni, olvasgasd [posztjainkat](https://blog.fps.hu/), nagyon sok hasznos információt találhatsz bennük a tervezéstől a kivitelezésig.
### A jövő CMS-e?
URL: https://blog.fps.hu/wysismuc-cms/
Last updated: 2026-07-17T08:47:55.000Z
Bizonyára olvastátok a [tartalom stratégiáról szóló posztunkat](https://blog.fps.hu/adaptiv-tartalom-adaptive-content/ "Tartalom Stratégia"), melyet Éva írt. Az nem kérdés, hogy ebbe az irányba kell elmozdulni, viszont a helyzet az, hogy jelenleg nem, vagy csak nagyon kevés CMS létezik a világon, ami strukturált tartalmat képes kezelni.

### Van ilyen?

Olcsó, bárki számára elérhető nincs. Az IBM már kidolgozott egy ilyen rendszert, de nagyon drága. (…mondjuk ebben a pillanatban már fejlesztenek a világ több pontján ilyet – lásd a poszt végén). Alább „ész nélkül”, de remélem gondolatot ébresztve leírom ötleteim, hátha valakit inspirál. :)

### Milyennek kell lennie egy ilyen CMS-nek?

Lássuk mit írt Éva.

A CMS könnyen testreszabható, platform független felületet biztosít:

- a tartalom létrehozásához és szerkesztéséhez
- egy meghatározott adatmodell szerinti tartalom tárolásához
- a tartalom megjelenítéséhez (előnézet)
- a tartalom publikáláshoz és a felhasználókhoz való eljuttatásához

Brrr. Ez nem is egyszerű feladat. Miután előre definiált sémákat nehéz alkalmazni, ezért szükség van adatmodellek létrehozására a rendszer által. Nyilván felhasználóbarátan, könnyedén. Érdekes lehet az is, hogy magát a tartalom stratégia ábrázolását is grafikus felületen lehessen elvégezni. Mint pl. egy OOP tervező eszköz. Amikor ábrázolod a rendszert, akkor a háttérben már generálja is a megfelelő elemeket. Könnyen lehet változtatni a struktúrákon, új csatornákat lehet bármikor bekötni. Az egyes tartalomcsomagokat metaadatokkal kell felruházni, ezáltal szemantikus kapcsolathálót lehet felépíteni.

A publikáláshoz szükség lehet exportáló szűrőkre, melyek az adott csatornának megfelelő outputot állítják elő. A printhez pdf-et, a webre HTML-t (microformátumokkal felruházva) stb. Az egyes csatornákon a publikálás folyamatát is automatikusan elvégzik, pl. youtube-ra kitolja. És igen, ezeket a szűrőket bővíteni lehet, könnyedén frissíteni, módosítani. Már nem is beszélve az importról, a most meglévő adatstuktúrákból betölteni információt a rendszerbe.

#### Ötletelgetek még

Az egyes tartalomcsomagokhoz rögzíteni lehetne, hol jelent meg és mikor. Össze lehetne kötni a social oldalakkal, hányan lájkolták, hányan osztották meg. Ha emailben küldték ki, hányan olvasták. Ha link van a tartalomban, hányan kattintottak. Minden kis tartalomcsomaghoz lehetne pászítani egy, vagy több mérőszámot. Mennyire volt értékes a célközönség számára csatornánként.

A rendszer figyelmeztethetne, hogy az adott tartalomcsomag még nem jelent meg valahol és hogy érdemes lenne más csatornára is eljuttatni, esetleg eltelt már egy hosszabb időszak és egy másik időpontban ismét meg lehetne jelentetni.

### WYSISMUC

Azaz What you see is…structurally marked up content. Azért vannak, akik már agyalnak ezen és elképzeltek már felületeket, sőt már létre is hoztak kezdeményeket. Ezt a [cikket érdemes elolvasnod](http://think-info.com/2013/06/05/wysismuc/?ref=blog.fps.hu), ha érdekel a téma, esetleg építeni szeretnél ilyen rendszert.
### Egy tartalom, több csatorna
URL: https://blog.fps.hu/adaptiv-tartalom-adaptive-content/
Last updated: 2026-07-17T08:48:05.000Z
Content is king, ezt már régóta halljuk. És továbbra is a tartalom a király, különösen akkor, ha megfelelően használjuk. De mit is jelent az, hogy megfelelően használni? Egy szöveget és egy hozzá tartozó fotót hogyan lehet megfelelően használni?

A tartalom stratégia megoldást nyújt a kérdésre. Hogy mi is az a tartalom stratégia, arról már [korábban írtam egy posztot](https://blog.fps.hu/tartalom-strategia-content-strategy/ "Tartalom Stratégia"). Röviden: a tartalom stratégia lényege, hogy úgy juttassuk el a tartalmat a felhasználóknak, hogy maximális felhasználói élményt nyújtson bármilyen eszközön. Most a tartalom stratégia egyik részét, az adaptív tartalmat fogom körbejárni, hogy megtudd, hogyan lehet egy tartalmat megfelelően használni.

### Mi az adaptív tartalom?

A tartalom önállóan is használható egységekben egy központi helyen van tárolva, így könnyedén előhívható és megjeleníthető bármilyen eszközön. Amikor ki tudod használni a tartalom teljes potenciálját, akkor beszélünk adaptív tartalomról.

A jelszó: hozd létre egyszer, és használd mindenhol.

Például:

- Iphone applikáció
- Ipad alkalmazás
- mobile web
- Android applikáció
- Windows phone app
- desktop web
- blog
- social media
- print
- stb.

A tartalom előállítás az egyik legértékesebb tevékenység minden üzleti vállalkozásnál. Cikkek, tanulmányok, blogposztok, Facebook bejegyzések, stb. óriási hatalmat és lehetőséget adnak annak, akik megfelelően tudják használni. Ezt mindannyian tudjuk, mégis nehéz elkezdeni a tartalom előállítást. Sokszor az előállítás körülményesebb, mint a megjelenítése.

És mi történik akkor, ha beindul a gépezet? Jönnek a tartalmak, megjelennek egyszer, majd eltűnnek a süllyesztőbe, és sose hallunk többet felőle. A legtöbb tartalom többet érdemel, mint egy egyszeri megjelenést a nyitóoldal tetején. Például a legtöbb blogbejegyzés hamarabb „meghal”, minthogy kihasználnánk a bennük rejlő potenciálokat. Ez elriasztja a tartalom előállítókat attól, hogy újabb kontenteket készítsenek. És ez rossz. De van megoldás!

### Hogyan épül fel az adaptív tartalom?

A jól strukturált tartalom a kulcs. A tartalmat kis darabokra kell tördelni és a metaadatok segítségével strukturálni, így jóval rugalmasabb és használhatóbb lesz. A téma elismert szakértője, Karen McGrane öt részre osztotta az adaptív tartalmat:

- **Újrafelhasználható tartalom:** egyszer kell előállítani és bármely platformon használható
- **Strukturált tartalom:** a tartalom kis darabokban könnyen adaptálható különféle eszközökhöz
- **Megjelenés független tartalom:** nyers tartalom mindenféle formázás mellőzésével
- **Jelentéssel bíró metaadatok:** titkos vagy rejtett adatok, melyek egységesített formában írják le a tartalmat
- **Használható CMS:** a teljes rendszer, mely lehetővé teszi az előző négy pont megvalósítását

Lássuk részletesebben a fenti pontokat.

[![adaptive content diagram](https://blog.fps.hu/content/images/2015/12/circle.png)](http://www.slideshare.net/KMcGrane/adapting-ourselves-to-adaptive-content-12133365?ref=blog.fps.hu "Karen McGrane: Adaptive Content Slideshare")

### Újrafelhasználható tartalom

Az egy kontextusban készült tartalom nem mindig helyezhető át jól más kontextusba. Például egy részletgazdag kép nagy felbontásban tökéletesen élvezhető, míg egy pici kijelzőn elveszti ezt a tulajdonságát annak ellenére, hogy azon is megtekinthető. Ha a tartalom – ennél a példánál maradva a képünk – nem tudja közvetíteni az üzenetet, akkor módosításra szorul: vagy kicseréljük a képet, vagy kiegészítjük egy képaláírással, stb.. Tehát gondoljunk alternatív tartalomra is, hogy a felhasználói élmény ne csorbuljon.

Az oldalakon lévő címek általában többféle funkciót is ellátnak: egyrészt az oldal címe, másrészt horgonyszövegek is lehetnek, vagy linkek. Itt is egyértelműsíteni kell a funkciókat, hogy minden platformon azonos tartalommal és funkcióval bírjon.

Amikor tartalmat készítünk, hozzunk létre variációkat. Pl. egy webshopban a termékleírásról legyen egy rövid, egy közepes és egy hosszú verzió, hogy az adott kontextusnak megfelelő variáció tudjon megjelenni. Ugyanezt meg tudjuk csinálni címekkel és egyéb tartalmakkal is.

### Strukturált tartalom

A strukturáltság rugalmassághoz vezet. Ez az adaptív tartalom alapja. Minél kisebb egységekbe tároljuk a tartalmat, strukturáljuk megfelelően, így rugalmasan felhasználhatóvá válik. Nincs egységesen alkalmazható struktúra a tartalmakra. Függ az oldal kialakításától, a célközönségtől, és lehet, hogy szükséges lehet a tartalom modellezése.

#### Tartalom modellezés

A tartalom modellezés definiál különböző típusú tartalmakat, és azt is, hogyan kapcsolódnak ezek a tartalmak egymáshoz. A cél olyan diszkrét tartalmi egységeket létrehozni, melyeket külön-külön is lehet tárolni.

A tartalom modellezés az alábbiakat nyújtja:

- tartalom típus: a tartalom lehet cikk, képgaléria, videó, stb.
- attribútumok: milyen tartalmi objektumokra lehet szükség, pl. szöveg, csatolt fájl, stb.
- adatok limitálása: mennyi lehet az egy oldalon használt tartalom mennyisége
- kapcsolatok: hogyan kapcsolódnak a különböző típusú tartalmak egymáshoz

Az elsődleges tartalomtípus vezeti a designt. Ne oldalakban gondolkodjunk, hanem tartalmi egységekben. Ez egy rugalmas alap, amelyet könnyen lehet variálni és kombinálni a különböző típusú tartalmakkal.

### Megjelenés független tartalom

A tartalmat mindenféle formázás nélkül, „nyersen” tároljuk. Amikor elkezdünk mindenféle formázást hozzáadni a tartalomhoz, kezd rugalmatlanná válni. Pl. ennek a szövegnek mindig félkövérnek kell lennie? Piros vagy kék betűvel kell megjeleníteni?

A tartalom jelentése nem írható le az alapján, hogy is néz ki. Ha különbözőképpen kell adott tartalomtípust megjeleníteni, akkor válasszuk szét strukturális szinten. Tehát **nincs több rich text és WYSIWYG formázás**, a webdesignerek legnagyobb örömére.

Ha egy platformra tervezünk, könnyű meghatározni a szerkezetet és a megjelenést, de ez már rögtön nem működik, ha több platformra tervezünk, ahol más és más megjelenítést szeretnénk. Ilyenkor egy megoldás van: priorizáljuk a tartalmakat és a prioritásokhoz rendeljük a vizuális megjelenítéshez vonatkozó információkat.

### Jelentéssel bíró metaadatok

Célszerű előbb meghatározni a metaadatok struktúráját és a prioritását, majd a megjelenéssel ráérünk azután foglalkozni, miután letöltötte az adatbázisból. Le tudjuk kérni a speciális meta adatokat annak érdekében, hogy úgy jelenítsük meg a tartalmat, ahogy szeretnénk. Különböző platformokhoz lehet fejleszteni tartalom csomag alapú megjelenítést a különböző típusú metaadatokhoz.

A metaadatok segítenek szétválasztani a tartalmat és a megjelenést.

### Használható CMS

Ahhoz, hogy az előző négy pontban leírt dolgok megvalósíthatóak legyenek, szükség van egy olyan CMS-re, mellyel nemcsak nekünk, hanem az ügyfeleinknek is könnyen kezelhető lesz a tartalom. Szükség van egy olyan felületre, amelyen könnyű dolgozni, így a felhasználó kényelmesen tudja strukturálni a tartalmakat.

A mai tartalomkezelő rendszerek nem igazán elégítik ki ezeket az igényeket, ugyanis meglehetősen nehéz minden tartalom típust előre definiálni. Egy jó CMS könnyen testre szabható, platform független felületet biztosít:

- tartalom létrehozásához és szerkesztéséhez
- egy meghatározott adatmodell szerinti tartalom tároláshoz
- tartalom megjelenítéshez
- tartalom publikáláshoz és a felhasználókhoz való eljuttatásához

A jelenlegi CMS rendszerek egyelőre nem alkalmasak arra, hogy adaptív tartalmakat tudjanak megjeleníteni, de talán nem vagyunk túl messze a megoldástól.

### Hogyan tovább?

Ha nem foglalkozunk a tartalmakkal és egyszerre akarjuk különböző eszközökön megjeleníteni, tönkretesszük a felhasználói élményt, amely a legfontosabb. A fentiekből kitűnik, hogy a moduláris tartalmaké a jövő, csakúgy, mint akár a CSS-nél vagy a HTML-nél. Ahhoz, hogy jól tudjuk használni ezeket a moduláris tartalmakat, szükség van strukturálásra. Ez a struktúra ad lehetőséget arra, hogy különböző módokon kapcsolhassuk egymáshoz a tartalmakat, így bármilyen felületen tudjuk biztosítani a maximális felhasználói élményt.

A jövő az adaptív tartalomé, mert:

- intelligens
- strukturált
- rugalmas
- agilis
- atomizált
- gyorsan felfogható

**Nincs többé olyan, hogy print tartalom, web tartalom, mobil tartalom. Csak TARTALOM van.** És amikor ki tudod használni a tartalom teljes potenciálját, akkor beszélünk adaptív tartalomról.
### Egyszerű, letisztult
URL: https://blog.fps.hu/simplicity-letisztult/
Last updated: 2026-07-17T08:48:15.000Z
Majd minden megkeresésünk azzal indul, hogy egyszerű, letisztult oldalt, appot, alkalmazást szeretnének. Hmmm. Ez tök jól hangzik és maximálisan egyet is értek vele, de ez csak komoly ráfordítással, befektetéssel érhető el, ami sajnos nem egyértelmű mindenki számára.

A kedvenc példám (ami jól személteti a folyamatot) egy mondjuk 32\*32 pixeles ikon tervezése. No nem egy flat ikonról beszélek, hanem mondjuk az alábbi képen látható kidolgozott ikonról.

[![bakelit lemezlejátszót ábrázoló ikon](https://blog.fps.hu/content/images/2015/12/recorder-1.png)](http://dribbble.com/shots/446052-Record-Player-iOS-Icon?page=2&ref=blog.fps.hu "Record Player icon on dribble")

Hogyan készül egy ilyen? Nagyban! Azaz nagy méretben (pl. 1000\*1000px) részletgazdagon kidolgozzák az ikont, majd azt kicsinyítik le és addig finomítják kisebb méretben, hogy annak értelmezhetősége és szépsége megmaradjon. Az az út nem járható (vagyis igen, de nem lesz megfelelő eredménye), hogy egyből a 32x32pixeles ikont rajzolják. Valahogy így működik ez.

Erről mindig Coco Chanel híres mondása jut eszembe:

> Öltözz fel teljesen és mielőtt kilépsz az utcára, állj meg a tükör előtt és végy le magadról egy dolgot és addig ismételd ezt, amíg már nem lesz rajtad semmi felesleges.  
> – Coco Chanel

Nyilván nem ennyire egyszerű ez egy szolgáltatás esetében. Az alábbi ábra szemlélteti, hogy honnan kell(ene) elindulni – az alapoktól.

![Venn diagram: üzlet, felhasználó, technológia](https://blog.fps.hu/content/images/2015/12/circledia.png)

Mik az üzleti céljaid, mik a felhasználóid elvárásai, milyen technológiai lehetőségeid, korlátaid vannak? Ezek metszete adja majd meg, hogy mit is kell csinálnod, ez máris egy nagy lépés az egyszerűség, letisztultság irányába.
### Gyorsulj mobilon is!
URL: https://blog.fps.hu/mobil-seo-google-sebesseg/
Last updated: 2026-07-17T08:48:25.000Z
Az okostelefont használók a legdinamikusabban növekvő szegmense az internetezők táborának, éppen ezért a Google arra törekszik, hogy maximális felhasználói élményt kaphassanak ezek a látogatók is. Ezért most újabb változtatásokat léptet életbe a mobil SEO tekintetében.

A Google folyamatosan módosít a mobil keresési algoritmuson, hogy gyorsabb és pontosabb keresési eredményeket kaphassanak a mobilon kereső felhasználók. Matt Cutts, a Google Webspam csapat vezetője nemrég bejelentette, hogy hamarosan jön egy új frissítés a Google mobil kereső algoritmusához. Egyik lényeges változás, hogy a desktopos keresési algoritmushoz hasonlóan mobil esetén is rangsorolási faktorrá válik az oldalbetöltődés sebessége. A sebesség elég kényes és érzékeny pontja a mobil oldalaknak, éppen ezért összegyűjtöttük a leggyakoribb oldalbetöltődést lassító problémát.

### Hibás átirányítások

Jónéhány weboldal használ szeparált URL-eket a desktopos és a mobil felhasználók kiszolgálására. Viszont az URL-ek átirányítása nem mindig történik helyesen, és ez elég nagy bosszúságot okozhat a felhasználóknak. Általában két tipikus probléma szokott előfordulni: vagy nem irányít át a desktopról a mobil oldalra, vagy nem a megfelelő mobilos oldalra irányít át. Mindkét problémának ugyanaz lesz a vége: a felhasználó nem tud eligazodni az oldalon, így nem fogja használni azt. Ráadásul a sok átirányítás jelentősen lassíthatja az oldalbetöltődést, ami egy lassabb mobilnet esetében különösen kellemetlen. Ezek az apróságok jelentősen megváltoztathatják a keresőkben a rangsorolást, mivel a felhasználók nem találják meg a keresett tartalmakat, így a kereső nem fogja az amúgy értékes tartalmat relevánsnak tekinteni.

A megoldás egyszerű: a mobilra optimalizált oldal tartalmilag egyezzen meg a desktop oldallal, így elkerülhetőek a hibás átirányításból adódó problémák. A Google ad néhány tippet és tanácsot az [átirányításokhoz](https://developers.google.com/webmasters/smartphone-sites/redirects?ref=blog.fps.hu), illetve a [szeparált URL-ek](https://developers.google.com/webmasters/smartphone-sites/details?ref=blog.fps.hu#separateurls) használatához.

[![Comic: Orvosok műtét közben tanácstalanok. Az egyikük felteszi a kérdést: – Can someone Google for triple-dichotomyappendix?](https://blog.fps.hu/content/images/2015/12/dr-1.png)](http://www.webconfs.com/seo-tutorial/seo-and-keywords.php?ref=blog.fps.hu)

### Egyéb smartphone problémák

Vannak olyan oldalak, melyek a desktop felhasználók felé helyesen jelenítik meg a tartalmakat, míg a mobil eszközökön 404-es hibát adnak. Sok olyan helyzet adódik, amikor kizárólag csak az okostelefonon jelentkeznek a problémák.

#### Íme néhány gyakori:

- Ha egy látogató mobil eszközről érkezik az oldalra, és létezik mobil verzió is, automatikusan irányítsd át a mobil nézetre (és adj lehetőséget áttérni a desktop nézetre, ha mégis át szeretne térni a teljes nézetre a user)
- Győződj meg arról, hogy a mobil oldalon rendben megjelennek a tartalmak és nincs hiba. Ha a tartalom nem érhető el mobil verzióban, inkább a desktop verzióra irányítsd a felhasználót. Ez még mindig jobb, mint egy 404-es hibaüzenet.
- Helytelen Googlebot kezelés: a Google kétféle keresőrobotot használ az indexeléshez. A Googlebot feltérképezi a desktop felületekre készült tartalmakat, míg a Googlebot-Mobile a mobil tartalmak indexelését végzi. A Googlebot-Mobile keresőrobot kétféle lehet: az egyik a Feature Phone Googlebot-Mobile, a másik a Smartphone Googlebot-Mobile. Tipikus hiba, amikor ezeket a botokat nem a megfelelő oldalra irányítod, így könnyedén belefuthatsz egy végtelen átirányítási hurokba, melynek eredménye, hogy vagy nem töltődik be az oldal, vagy hibaüzenetet kapunk a megfelelő tartalom helyett.
- Amikor beágyazott videót használsz a desktop oldalon, győződj meg róla, hogy mobil eszközön is le lehet-e játszani a videót. Sokszor ugyanis nem érhetőek el videók okostelefonokról (pl. ha a lejátszáshoz szükséges Adobe Flash, akkor számos készüléken pl. iPhone, Android 4.1-es verzió felett nem érhetőek el a videók)

Az egész átirányítási problémára megoldás lehet a [responsive web design](https://blog.fps.hu/mobil-web-strategia-responsive-ress/) használata. Persze nem minden esetben járható út, hiszen ennek is, mint minden technológiának vannak hátulütői is. Ennek ellenére a Google is ezt a technológiát ajánlja elsősorban a mobil oldalak kialakításához.

### Optimalizálj a sebességre is!

Ha már van mobil oldalad, vagy a közeljövőben lesz, különösen oda kell figyelned minden apróságra, ami befolyásolhatja az oldalbetöltődési sebességet. A mobil keresési forgalom hónapról hónapra növekszik, tehát egyáltalán nem mindegy, hányadik pozícióba található a weboldalad a keresők találati listáján. Persze tudom, ez csak egyetlen rangsorolási faktor, de csak akkor lehetsz jó pozícióban a keresőkben, ha próbálsz minél jobban megfelelni az irányelveknek.
### Fejlődni jó dolog
URL: https://blog.fps.hu/kihivas-kuzdelem-motivacio/
Last updated: 2026-07-17T08:48:35.000Z
Sokat beszélgetünk az fps-ben arról, hogy folyamatos fejlődésre van szükség. Nem kérdés, hogy miért, ellenben az ügyfelek elvárják tőlünk a gyors és precíz munkát és ez a fejlődés ellen hat, de…

Amikor egy projekt kapcsán felmerül egy feladat, akkor a projekt menedzser nyomban vágja, ki a feladatra a legalkalmasabb ember, ki az, aki gyorsan és pontosan elvégzi azt és rá is osztja. Nyilván arra is ügyel, hogy minden feladattípusra legyen legalább két ember, ha az egyik lebetegedne, vagy szabadságon lenne.

Sokan azt gondolják, hogy ez így rendben is van. Szerintem meg nem. Minden munkahelyen alapkérdés, mik azok a dolgok, melyek motiválják az ott dolgozókat. A pénz? Nem. Minden csoda három napig tart és az örökkévalóságig sem lehet emelni a fizetést. Akkor? A kérdésre Dan Ariely adja meg a választ zseniális TED-es előadásában, melyet magyar felirattal is megnézhettek:

Nem fogom leírni, amit Dan elmond, inkább két gondolatot emelek ki belőle, amiért írom ezt a posztot. Egyrészt a visszajelzés fontossága. Tudom, hogy az a munka, amit végzek, hasznos más emberek számára. Másrészt és ennél le is ragadok, a kihívás!

### Kihívás

Igen, a kihívás (és még 100x). Azaz megugrani olyan feladatokat, melyekhez komoly erőfeszítésre van szükség. Másképpen mondva: folyamatosan fejlődni akarunk, ha nem is tudatosan. Az a munkatárs, aki napi nyolc órában ugyanazt a munkát végzi kicsi változatossággal fűszerezve, egy idő után befásul, motiváció vesztett lesz és távozik.

### Egy biztos: a változás

A [scrum módszertanában](https://blog.fps.hu/scrum-alapertekek/) pont azt szeretem, hogy csapat van és mindenkinek jut mindenféle feladat, ami elősegíti az edukációt is a rengeteg kommunikáció segítségével. Igen, sokszor ez fájdalommal jár az egyénnek, és mi emberek alapvetően lusták vagyunk (hiába mondasz mást), általában a könnyebb, kevesebb erőfeszítéssel járó utat választjuk. Amikor azt mondod, hogy ezt nem szeretem csinálni, annak egy oka van, nem próbáltad ki magad, nem küzdöttél meg a feladattal. Erről az edzés jut eszembe. Utálok hasizomra dolgozni. Miért? Mert az gyenge! De ha megerősítem, akkor szeretni fogom. Egyszerű a képlet, küzdeni kell, tágítani kell a határokat.

![ábra, ami mutatja, hogy a konfort zónától messze van a pont, ahol a csoda történik](https://blog.fps.hu/content/images/2015/12/komfort.png)

Ezt a képet biztos láttátok már az interneten, sokszor felbukkan. Zseniális. Elmond mindent. Ahhoz, hogy fejlődni tudj, ki kell lépni a komfort zónádból, ennyi. Miután nem vagyunk egyformák és sokan önmaguktól nem hajlandók elhagyni a komfort zónát, ezért a vezetők, középvezetők feladata, hogy elősegítsék azt. Nyilvánvalóan figyelembe kell venni az adott egyén képességeit, illetve az ügyfél ráfordítása is fontos tényező, de mint minden esetben rá kell találni az aranyközépútra.

**Te hogy csinálod? Ti hogy csináljátok? Mit gondolsz?** 
**Ne tartsd magadban!**
### Unatkozó fejlesztők ökörségei
URL: https://blog.fps.hu/idiota-fejlesztesek-unatkozo-fejlesztok/
Last updated: 2026-07-17T08:48:44.000Z
Az internet tele van unatkozó fejlesztők által készített, általában értelmetlen, hasztalan, ámde vicces kis fejlesztéseivel. Ezek sok esetben kis JS-ek, bookmarkletek, vagy akár komolyabb programok. Összegyűjtöttünk párat, hogy legyen egy hely, ahol megtalálhatjátok bármikor, ha esetleg hirtelen szükségetek lenne valamelyik baromságra.

#### FIGYELEM!

Bíztatunk mindenkit arra, hogy ha tud a posztba illeszkedő, hasonló őrületet, akkor kommentben ossza meg velünk, mert folyamatosan bővíteni szeretnénk a listát. Várjuk és köszi előre is!

*Update: 2013\. június 8\. 11:48*

### Hook.js

![Hook.js logó](https://blog.fps.hu/content/images/2015/12/hookjs.png)

A mobil, tablet appokban elterjedt pull-to refresh (húzd le a frissítéshez) feature webes megfelelője. Szimplán dobd be a JS-t az oldaladba és lám már ott is van. Mondjuk miután simán újratölti az oldalt, egyáltalán nincs értelme.

[Nézd meg az oldalt, használd Te is!](http://usehook.com/?ref=blog.fps.hu)

### Pure CSS3 Lightsaber Checkboxes

![fénykardok](https://blog.fps.hu/content/images/2015/12/starwars.png)

A személyes kedvencünk. A tiszta CSS3 használatával könnyedén át tudod alakítani az oldalad checkbox-szait lézerkardokká, melyeket ki-be lehet kapcsolgatni. Nagyon hasznos!

[Nézd meg az oldalt, használd Te is!](http://scotch.io/demos/pure-css3-star-wars-lightsaber-checkboxes?ref=blog.fps.hu)

### FESS - Fat Expanded Style Sheets

![FESS példa](https://blog.fps.hu/content/images/2015/12/css-fess.png)

Ha túl egyszerűnek, rövidnek találod a CSS kódod, esetleg a kódsorok száma után fizetnek neked, akkor számodra találták ki a FESS-t. A kép mindent elárul, nem kell magyarázni. Végezetül arra is alkalmas, hogy növeld a betöltési időt. Must have!

[Nézd meg az oldalt, használd Te is!](http://www.fess.me/?ref=blog.fps.hu)

### Comic-Sans it!

![Comic-Sans it felirat](https://blog.fps.hu/content/images/2015/12/comicsans.png)

Ez a gonosz bookmarklet segít abban, hogy a kedvenc fontodra alakítsd az éppen látogatott web site-ot. Mindenkinek jó, aki szereti.

[Nézd meg az oldalt, használd Te is!](http://comicsansit.com/?ref=blog.fps.hu)

### Harlem Shake for Website

![Harlem Shake for Website felirat](https://blog.fps.hu/content/images/2015/12/harlemshake.png)

Ugyan lecsengett már a Harlam Shake őrület (szerencsére), azért szórakoztató lehet, ha ráereszted egy web site-ra. Próbáld ki. Ha valamilyen oknál fogva szükséged lenne a JS-re, akkor [töltsd le](https://gist.github.com/GeissT/5012729?ref=blog.fps.hu).

[Nézd meg az oldalt, használd Te is!](http://hsmaker.com/?ref=blog.fps.hu)

### fartscroll.js

![fartscroll.js felirat](https://blog.fps.hu/content/images/2015/12/fartscroll.png)

Mind közül ez a legbugyutább. A JS-t beillesztve az oldalra, különböző szellentés hangokat hallasz minden egyes scrollozás (görgetés) során. Elképzeltük milyen lenne, ha egy beta oldalt az ügyfélnek ezzel küldenénk ki… ööö, nem jó ötlet.

[Nézd meg az oldalt, használd Te is!](http://theonion.github.io/fartscroll.js/?ref=blog.fps.hu)

### The Queen’s style sheet

![Queen's style példa](https://blog.fps.hu/content/images/2015/12/please.png)

Inkább a brit angolt preferálod szemben az amerikaival? Mostantól írhatod brit angolsággal a CSS kódod, a spiffingcss a háttérben átfordítja. Affektálj nyugodtan, az se probléma.

[Nézd meg az oldalt, használd Te is!](http://spiffingcss.com/?ref=blog.fps.hu)

### fool.js

![fool.js felirat](https://blog.fps.hu/content/images/2015/12/fooljs.png)

Lepd meg az oldaladra látogatókat. Áprilisi tréfának szánták a fejlesztők, de alkalmas lehet bármikor. Egyszer csak lezuhan a görgetősáv, megszólal Rick Astley slágere, ehhez hasonló nyalánkságokat alkalmazhatsz ezzel a jQuery pluginnel.

[Nézd meg az oldalt, használd Te is!](http://fooljs.com/?ref=blog.fps.hu)

### Raptorize

![raptorok illusztráció](https://blog.fps.hu/content/images/2015/12/raptorize.png)

Ezzel a jQuery pluginnel konkrétan a szívbajt hozhatod az oldalad látogatóira, már ha ez a célod. Belövöd, hogy mennyi idő teljen el és hirtelen üvöltve beugrik egy raptor. Ha nem lenne, ki kellene találni.

[Nézd meg az oldalt, használd Te is!](http://zurb.com/playground/jquery-raptorize?timed%5Flaunch=true&ref=blog.fps.hu)

### ClippyJS

![Clippy.JS felirat](https://blog.fps.hu/content/images/2015/12/clippy-2.png)

Emlékeztek még a Microsoft Office csomag ügynökeire? A kis figurák (gemkapocs, varázsló, kutya, cica), melyek megjelentek és folyamatosan idegesítettek az állandó tettrekészségükkel, kérdéseikkel, segítőkészségükkel? Most már te is kikészítheted látogatóid a ClippyJS, jQuery pluginnel. Illeszd be az oldaladba, különböző eseményekre kösd rá a megfelelő reakciót. Garantáltan lelépnek a felhasználók és biztos nem látod őket többé.

[Nézd meg az oldalt, használd Te is!](https://www.smore.com/clippy-js?ref=blog.fps.hu)
### 10 idézet, amit minden grafikusnak kívülről kell tudni
URL: https://blog.fps.hu/10-idezet-grafikusoknak-designereknek/
Last updated: 2026-07-17T08:48:55.000Z
A [web teacher blogon](http://www.webteacher.ws/2012/10/26/10-quotes-all-graphic-designers-should-know-by-heart/?ref=blog.fps.hu) találtuk ezt a nagyszerű, tíz pontba szedett idézethalmazt, melyek segítenek minden grafikusnak, designernek, hogy jobbak legyenek. Lefordítottuk Nektek és egy kellemes infografikát készítettünk belőle, amit akár vektorosan letölthettek és ki is nyomtathattok, hogy a nagy designerek, írók, mindig emlékeztessenek az alapokra, és hogy soha ne térj le a helyes útról.

A mi tanácsunk még mielőtt átfutod:  
SOHA NE HASZNÁLJ COMIC SANS FONTOT! ;)

### Tessék

![10 édizet, amit minden grafikusnak kívülről kell tudni infografika](https://blog.fps.hu/content/images/2015/12/10-idezet-grafikusoknak-fps-1.png)

Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak, vagy a grafikusodnak!

[Töltsd le a posztert (0 letöltés)](https://www.fps.hu/presentations/10-idezet-grafikusoknak-fps.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### Rólunk, bemutatkozás
URL: https://blog.fps.hu/bemutatkozas-about-us/
Last updated: 2026-07-17T08:49:04.000Z
Majd minden website rendelkezik egy rólunk, cégünkről, bemutatkozás, vagy hasonló oldallal. Sok esetben hívom fel a figyelmet arra, hogy kiemelten kell foglalkozni az ott található tartalommal, de sajnos erre általában már nem marad energia, türelem, pénz stb.

Örömmel vettem, mikor legutóbb egyik kedves ügyfelünk kifejezetten a bemutatkozó oldaluk rendbetételével keresett meg minket. Gondoltam megírom, hogy mire kell figyelned, hogyan érdemes „tálalnod” céged, magad, azaz mi legyen ezen az oldalon. Sok olyan oldalt látok, ahol egy-két mondat szerepel bemutatkozásként, ami azt láttatja, hogy nincs mit mondanod. Érdemes egy pillantást vetned az analitikádra, meg fogsz lepődni, hogy milyen látogatott ez az általánosan elhanyagolt oldal, különösen e-commerce site-oknál.

### Alapvetések

Ez az az oldal, ahol kapcsolatot tudsz kialakítani a látogatóiddal. Akik elnavigálnak ide, azok már kifejezetten érdeklődnek a céged, vagy te irántad, tehát nincs más hátra, mint érzelmi kötődést kialakítani. Itt a száraz, unalmas szöveg nem fog működni, valahogyan meg kell különböztetned céged, magad. Hogy ezt milyen eszközökkel tudod elérni?

### A csapat, a személyiség ereje

Minden csapat más, minden ember más, egyedi személyiséggel vagyunk megáldva. Tehát nincs más dolgod, mint „személyessé” tenni ezt az oldalt. Beszélj a cégedben dolgozókról, magadról! Persze azt tudnod kell, hogy ez megosztja majd a látogatókat, de az nem baj! Ha a látogatónak már ezen a ponton unszimpatikus a céged, vagy te, akkor jobb is, hogy nem keveredtek üzleti kapcsolatba. A kémia úgysem lenne meg, így a közös munka sem működne, akkor meg minek.

### Sztori, sztori, sztori

Írtam egy posztot a saját blogomon arról, hogy [miért fontos a történetmesélés](https://blog.kolboid.eu/tortenet-tortenetmeseles-storytelling/?ref=blog.fps.hu), ha nem olvastad, akkor ajánlom, mielőtt továbblépsz. Szóval: \*\*TÖRTÉNET! \*\*Meséld el a céged, a saját történeted. Ne száraz bullet pointokba szedett listát gyárts, hanem írd le azokat az eseményeket, melyek a céged, vagy a te életutadban fordulópontnak számítottak. Ne félj az érzelmektől, fűszerezd vele a szöveget. Beszélj úgy, mintha ember lennél és nem egy gép! Felejtsd el a B2B (business to business) gépies gondolkodást, inkább koncentrálj a P2P (people to people)-re. A történet része legyen a víziód is. A látogatóid, ügyfeleid téged, titeket akarnak megismerni, benned, bennetek akarnak megbízni és nem egy logóban.

![dr. Nyeste Gábor az fps ügyvezetője öltönyben ül egy süllyedő vitorláshajón](https://blog.fps.hu/content/images/2016/01/nyeste-gabor.jpg)

### Fotó

Ha cégről, ha magánemberről van szó, legyen fotó a mozgatórugónak számító emberekről, rólad (vagy a csapatról). Mosolyogj(atok)! Ki akar búval bélelt embereket bámulni? Pláne velük dolgozni? Az is jó, ha az irodáról, a munkahelyről is teszel ki fotót, de azon is legyen(ek) ember(ek)! Jó lehet, ha „beállított” fotót használsz, de sokkal jobb, ha az adott egyén személyiségét tükrözi vissza a kép, nem kell senkinek a stock photo feeling. A tuti, ha olyat csinálsz a képen, amit egyébként is szeretsz.

### Még mindig sztori

A fotók alatt legyen rövid, tömör történet az emberről, csapatról. Mit szeret(nek) csinálni, mivel foglalkoznak, foglalkozik, mióta csinálják, csinálja. A finom humor megengedett, de csak akkor, ha van.

### Mit mondanak mások

Ne feledd, a legjobb, ha mások mondják el, hogy milyen vagy, hogyan dolgozol. Az ügyfelek véleményei (fotóval, névvel, titulussal) építik legjobban a bizalmat irántad, a céged iránt. Remélem már mondani sem kell, hogy ez is egy mini történet legyen, ne abból álljon, hogy te vagy a legjobb és legmegbízhatóbb, bla-bla.

### Kontakt adatok

Végül ne feledd el a megadni a kapcsolati adatokat az oldal végén, különösen a social media linkeket tedd ki, ahol jó esetben további benyomásokat szerezhet a látogató. Lehet, hogy elsőre nem fog vásárolni, üzletet kötni veled, a cégeddel, de az biztos, hogy elraktároz téged az agyában és ha jól csináltad, később kapcsolatba fog lépni veled.

**Jó példák:**

- [http://mailchimp.com/about/](http://mailchimp.com/about/?ref=blog.fps.hu) \- mesteri kidolgozás
- [http://37signals.com/about](http://37signals.com/about?ref=blog.fps.hu) \- a basecampet fejlesztő cég timeline-t használ és a fent említett elemeket
- [http://www.lukew.com/about/](http://www.lukew.com/about/?ref=blog.fps.hu) \- a visszafogott megoldás
- [https://kolboid.eu/](https://kolboid.eu/?ref=blog.fps.hu) \- bocsánat, a saját oldalam nem tudtam kihagyni ;)

Keresgéltem magyar példákat, nem nagyon találtam. Az fps részéről, mi a social mediaban, blogon mutatjuk meg magunkat. Minden kollégának van fényképes bemutatkozója Facebookon a jegyzetek közt. A web site-unk egy kiinduló pontnak számít – pl. nincsenek menüpontjai sem :)
### Teljesítmény-optimalizálás, azaz cache stratégia LAMP környezetben
URL: https://blog.fps.hu/cache-strategia-teljesitmeny-optimalizalas-lamp/
Last updated: 2026-07-17T08:49:14.000Z
Nő a terhelés az oldalon, lassul az oldalletöltés, felhasználók türelmetlenek és továbbállnak, ha sokat kell várniuk. Ha csak kicsivel is lassul az oldal átlagos betöltési ideje már érezhetően csökken a látogatások száma. Google is szereti (SEO), ha gyorsan jön be az oldal.

Arról nem is beszélve, hogy sok erős hardver megvétele/fenntartása drága. Kézenfekvő a szerveroldali optimalizáció, azaz minél kisebb, gyengébb hardveren, minél jobb eredményt érj el teljesítmény tekintetében. Minél több felhasználót, egyszerre történő lekérést szolgálj ki, minél gyorsabban.

Aztán azt se szeretnéd, hogy ha hirtelen nő meg a terhelés, akkor elérhetetlen legyen az oldal.

Fontos még azt megjegyeznem, hogy itt a lassú oldalletöltés alatt most csak az oldalgenerálás idejének problémájával foglalkozom. Teljesen más téma, ha az oldal lejön gyorsan, de még betölt több tucat CSS és JavaScript fájlt és ezek miatt lassú a kliens oldalon.

### Megoldás?

Cache. Ez a sokszor hallott szó – amelyre nem tudnék magyar fordítást adni – kihúz téged a pácból. Persze csak akkor, ha a kódod már optimális más szemszögből. Bár ha nem hallottál a cache-ről, akkor nem hiszem, hogy így van.

### Mit takar a cache-elés?

A lényeg, hogy a nagy műveletigényes adatkinyeréseket valamilyen módon gyorsítod. Ha az adatokat csak lassan lehet kinyerni, akkor az eredményt célszerű eltárolni egy gyorsabban elérhető helyre és onnan kiszolgálni. (Azaz a kész kinyert/összeállított adatot – a végeredményt – kell elmenteni és csak azt újra felhasználni.) Időnként persze ezt frissíteni kell a frissebb adatokkal.

### Cache szintek

Maga a cache-elés több szinten is megvalósítható. Ebben a cikkben a cache három szintjével fogok foglalkozni:

- php opcode cache/mysql query cache
- reverse proxy
- php kód

Egy nagy terhelésű portálon mindegyiket célszerű alkalmazni. Ha mind a három szintet használod, akkor már sok meglepetés nem érhet. (Ez persze ebben a szakmában nem igaz ☺)

### Könnyen gyorsat

Kezdem is a legkönnyebb és leggyorsabb eredményt szolgáltató megoldással. Ehhez csak fel kell telepíteni egy opcode cache kiterjesztést PHP-hoz (ajánlom az apc nevűt) és hihetetlen jó eredményeket kapsz. Ez annyit tesz, hogy a php fájlból generált opcode-ot, azaz már értelmezett, bináris kódot eltárolja a cache, és ha újra ugyanazt a fájlt kell futtatni, nem kezdi el újra értelmezni (hacsak nem változott), hanem kiszolgálja az opcode cache-ből. Ezzel már nagymértékű, általános feldolgozási időt nyersz. Gyakorlatilag pár perc munkával látványos eredményt lehet elérni. Ez a legjobb befektetett energia/eredmény arányú megoldás.

Ehhez hasonló hatékonyságú a MySQL query cache. Ez pusztán annyit tesz, ha ugyanolyan mysql lekérés (select) érkezik a szerverhez, amiről már kapott eredményt egyszer, akkor egy ún. query cache-ből szolgálja ki. Így 200-300x gyorsabb a feldolgozás. Persze csak akkor, ha nem változik gyakran az adat, ugyanis ha bármely érintett táblában volt módosulás, akkor már újrafuttatja a lekérést.

Ehhez ellenőrizd le, hogy be van-e kapcsolva az opció a MySQL konfigurációs fájlban:

```sql

query_cache_size = X
query_cache_type = Y

```

ahol X, a cache mérete byte-okban (max. pár 10 MB elég) és Y = 1, ha alapértelmezetten be akarod kapcsolni és Y = 2, ha alapértelmezetten nem, de kérésre működjön (query-ben meg kell adni direktben, hogy ezt most cache-elje).

Ez a két egyszerű módszer sokat dobhat a teljesítményen, de elég korlátoltak és csodákra nem képesek, ha bonyolultabb a rendszer, az adott portál. Viszont legalább a fölösleges overheadet elveszik. Mindenképen nyersz vele, de annál kevesebbet, minél bonyolultabb megoldásról van szó. Mivel ilyen kevés befektetést igényelnek, ezért kezdd ezekkel!

### Reverse proxy megoldások

Sokan ettől várják a csodát. Aztán az vagy jön, vagy rosszul jön, vagy sehogy. Ehhez kicsit gondolkodni is kell. Ennek a lényege, hogy bizonyos url-eket cache-elsz, mégpedig úgy, hogy a reverse proxy szerver eltárolja magának az egyszer már lekért url-t. Nem kéri el újra az app szervertől, azaz nem kell a php-nek újra előállítania azt az oldalt az adott url-en, hanem villámgyorsan kiszolgálja a proxy szerver. Tipikusan használt reverse proxy szerverek: varnish, nginx. Bár utóbbi nem erre van dedikálva, de erre is jó és használják is sikerrel. Ezekkel hihetetlen gyorsan lehet statikus tartalmakat kiszolgálni, hisz nem is kell mindig eljutni a php-ig. Legkönnyebben http header paraméterekkel lehet szabályozni, hogy adott URL-t meddig cache-elje a proxy. Fontos, hogy be legyen állítva a következő http header:

```sql

Cache-Control: public, max-age=X

```

ahol X egy szám, mely megadja másodpercben meddig legyen cache-ben az url. Persze itt nem állnak meg a lehetőségek, például varnish-nak saját konfigurációs nyelve van, ahol aztán tényleg mindent testreszabhatsz. Ehhez persze elengedhetetlen, hogy a keretrendszered támogassa ezt a http headert és megfelelően kezelje.

#### Miért nem jön a csoda?

Hát például azért, mert rengeteg dinamikus tartalmad van. Ezzel az a baj, hogy ezt eltárolva elveszik a dinamizmus vagy pedig keveset tud cache-elni a reverse proxy. Aztán azért nem jön, mert nem jól használod. Például a hibásan működő keretrendszer mindig cookie-kat állítgat be fölöslegesen és a varnish ilyenkor alapértelmezetten nem cache-el. Ha cookie beállítást észlel, azaz a hozzátartozó http header jelen van. A jó hír, hogy van megoldás. Legalábbis részben, de itt már nagyon ügyeskedni kell. Ugyanis a Varnish tud olyat, hogy az oldal bizonyos elemeit a háttérszerverektől veszi (php-val le tudod generálni), míg a nagyobb részét a saját cache-éből.

Ezt nevezik Edge Side Includes, azaz röviden ESI-nek. Ilyenkor tényleg meg lehet azt tenni, hogy például az oldal login információkat megjelenítő része dinamikus, így teszem azt a megjött üzeneteket, és egyéb login információkat dinamikusan meg tudod jeleníteni, de az oldal többi részét a varnish villámgyorsan kiszolgálja. Ehhez csak picit kell módosítani a html kódot, amit generálsz:

```markup

<!–esi <esi:include src="[http://valami.valahol/?esi=esilogininfo](http://valami.valahol/?esi=esilogininfo)"> –>

```

Ebben a példában, ha működik az ESI funkció, akkor betölti a login információkat a [http://valami.valahol/?esi=esilogininfo](http://valami.valahol/?esi=esilogininfo&ref=blog.fps.hu) url-ről dinamikusan. Ha valamiért nem működne az ESI rendszer, akkor sima html comment lesz, így ha valamit elkonfigurálsz, vagy más gond van, akkor se rontja el az oldalt ez az <esi:include> tag.

Persze ehhez meg tényleg profi keretrendszer kell, hogy ezt lekezelje és ezeket automatikusan generálja az igényeidnek megfelelően. Így lehet maximalizálni a reverse proxy-k hatékonyságát a dinamizmust megőrizve, hisz az okos keretrendszer csak azt a pici részt generálja le, nem kell neki az egész oldalt.

Reverse proxynak van más előnye is, ilyen például a horizontális skálázás könnyű megvalósíthatósága. Azaz nagyon könnyen tudsz több szervert beállítani és a reverse proxy okosan kihasználja a több back-end szerver kapacitását, szétosztva a kéréseket köztük.

Ezekről még sokat lehetne beszélni, például be lehet állítani, hogy a reverse proxy miben tárolja a cache-t: fájlokban, memóriában, stb. Így ha sok a RAM, nagyon nagy sebességet érhetsz el egy memcached alapú tárolással.

![Load fokozatos csökkenése egy diagramon](https://blog.fps.hu/content/images/2015/12/load.png)

### PHP kód szintű cache

Ez a legtöbb munkát igénylő rész: amikor programozni kell a cache-elést, hiszen szeretnél dinamikus tartalmat kiszolgálni, okosan és gyorsan. Ha még használsz is reverse proxykat, akkor is a dinamizmus miatt (akár ESI kérés miatt) gyakran eljut a kérés a back-end app szerverig és akkor a PHP-nak kell előállítania valami tartalmat, lehetőleg gyorsan. Ha meg nincs reverse proxy, akkor itt kell nagyon ügyesnek lenni.

#### Miket kell leggyakrabban cache-elni?

- SQL lekéréseket
- Távoli lekéréseket (másik szervertől, másik hálózaton)
- bármit, ami lassan fut le

### A legtipikusabb megoldás

Egyszerűen annyit kell tenni, hogy az időigényes kérés eredményét lemented fájlba és ha a fájl létrehozási ideje X percnél régebbi, akkor újra lekéred és újra lemented. A köztes időben meg csak simán a fájlból szolgálod ki. Egyszerű, mint a pofon. Azért ennek is vannak buktatói. Például, ahogy a fájlt létrehozzuk. Itt figyelni kell arra, hogy jöhet több kérés egyszerre. Ha még nincs kész a fájl, de már jön a következő kérés, akkor még nem tud mit kiszolgálni. Ezért célszerű egy másik, átmeneti fájlba tárolni az eredményt, hogy amíg a fájl készül, addig se legyen gond a többi kéréssel és a végén, egy pillanat alatt átnevezni az átmeneti fájlt a végleges nevére. A többi lekérés meg ne kezdje el a cache fájl elkészítését, ha már létezik az átmeneti fájl – hisz akkor már készül –, addig szolgálja ki a régiből. Ha ezekre az alapszabályokra odafigyelsz, akkor nem lehet gond és nagyon sok esetben hatékony és jól működő fájl alapú cache-t kapsz. (Persze I/O terhelés nőhet, de ahhoz képest elenyésző mértékben, mint amit nyersz ezzel, ha jól van minden konfigurálva)

### Fejlettebb tipikus megoldás

Tovább finomíthatod a cache-elést, ha nem fájlba cache-elsz, hanem memóriába. Lehet akár memcached alapú a cache-ed, de akár redis is. Mindkettő memóriában tárolja az adatokat. A probléma az, hogy néha napján akármennyire nem akarod, de újra kell indítani a szervert, vagy bármi más probléma adódik és elveszik a memória tartalma, akkor hirtelen üresek a cache-ek. Így ezek a memória alapú cache rendszerek csak okosan használva működnek. Igaz, lehet lustán is okos az ember: a redis tud olyat, hogy kiírja a háttértárra is a tartalmát. Így azért lassabb lesz, de mégis perzisztens. Nem kell félni, hogy elveszik az adat és eltűnik a cache-ed tartalma. Sőt a redis-ben még könnyebb kulcs alapján elérni az adatokat, így még picit hatékonyabb is. De összességében a memcached gyorsabb, csak résen kell lenni, hogyan oldod meg a „nincs adat a cache-ben” szituációkat.

Pusztán, hogy memória alapú rendszert használsz, további nagy mértékű teljesítmény-növekedést érhetsz el és nem bonyolult a használatuk sem. Persze egy jó keretrendszer egy közös API felületen nyújtja az összes cache megoldást, sőt, tud köztük automatikusan is váltani, de ne szaladjunk ennyire előre.

### Maradj a háttérben

Másik megközelítés, hogy a nagyon időigényes lekéréseket és hosszú műveleteket a háttérben végzed el. Ha már van cron, akkor használd. Ezzel tudod időzíteni hogy mi, mikor fusson le. Így egyáltalán nem terheled a front-endet és sose futsz bele túlterhelésbe. Legalábbis ezen tekintetben. Persze ezért nagy árat fizetsz: a dinamizmus csorbát szenved. Hisz adott időben (időközönként) fut le és addig nincs új eredmény. Ez nyilván sokszor elfogadható, de van, amikor nem. Most az utóbbi esetről beszélek.

Lehetséges olyan megoldásokat alkalmazni, hogy a háttér végrehajtás vezérelhető. A legegyszerűbben ez úgy érhető el, hogy létrehozol egy percenként futó cront, ami nem csinál mást, csak megnézi, kell-e valamit csinálni. Így egy perc finomságú vezérelhető időzítőt kapsz. Persze lehet máshogy is megoldani, de ez a módszer működik szinte bárhol. Sőt, mivel a cron úgymond parancssorból indítja a PHP-t, ezért akár több szálon futó feldolgozást is csinálhatsz – párhuzamosítva a cache-eléseket.

Felmerül azonban egy icike-picike probléma: az oldalon lehetnek lapozások és keresések, vagy más paraméterfüggő lekérések, akkor ezt nehéz cache-elni. De nem lehetetlen: követni kell, mik a tipikus paraméterek, ezt egy okos rendszer tudja követni és azokat tartja cache-ben, illetve azokra készíti el. Lapozásra könnyű, tudja, hogy lapozhatnak 20 oldalt. Ki fog mondjuk ellapozni a 100\. oldalra? Nagyon kevesen. Így előre le lehet gyártani a cache-t 20 oldalig, a tipikus szűrésekre is. A legáltalánosabb felhasználás gyors és hatékony (úgyis ez az esetek fő része), a maradék meg marad előtérben, mert itt nem tudod cache-elni.

Összefoglalva: kapsz egy olyan háttér cache-elő rendszert, amely egy perces időközönként vezérelhető, már elég elfogadható és a dinamizmus terén sem a legrosszabb. Ellenben megadja azt a biztonság-érzést, hogy ezekkel az időigényes műveletekkel sosem fogják túlterhelni az oldalt, mivel semmi sem fut a lekéréskor közülük. Hátránya, hogy nem tudsz mindenre előre cache-t gyártani és nem elég dinamikus.

### Terhelés függő cache-ek

Az előző megoldás jól hangzik, de nem tudsz vele sok mindent megcsinálni. Ha ennél nagyobb dinamizmus kell, sokkal gyorsabban változnak az adatok, akkor más megoldást kell keresni.

Erre lehet jó módszer a terhelés függő cache-ek, ami egy felturbózott fájl vagy memória alapú cache. Arról van szó, hogy, ha kicsi a terhelés, akkor előállítja a tartalmat, ha nő, akkor átáll cache használatra. Érdemes beleprogramozni valamiféle prioritás kezelést, hogy mi az, amit elsőnek ki lehet lőni, ha gond van (átállítani cache-elésre) és mi az, amit a legtovább dinamikusan lehet hagyni. Amikor már nagyon nagy a terhelés a szerveren, akkor szinte minden cache-ből jön és ritkán frissíti a cache-t. Ennek a megoldásnak a titka a jó beállítás, mit mikortól, mennyi ideig cache-eljen. A finomhangolás időigényes és nehéz, viszont utána már a lehető legjobban megtartják az oldal dinamizmusát és nem lesz gond akkor se, ha hirtelen nagyobb lesz a terhelés az oldalon.

Gondolni kell még cache csoportokra is. Nem csak a terhelés függő cache-eknél, hanem általában is érdemes azzal foglalkoznod, hogy mi az, ami függ mástól. Pontosabban, melyek azok a cache-ek, amiket egyszerre kell más adatokkal újracache-elni. A keretrendszernek ezt le kell kezelnie.

Nagyon fontos a mai világban, hogy minél frissebb adatokkal szolgáljunk, minél inkább fent tudd tartani a frissítések gyakoriságát, ha olyan jellegű az oldal. A terhelés függő cache-elés ebben sokat segít.

### Ultimate megoldás – the best of both worlds

Összevonva a kettő megoldást – a háttérben cache-elést és a terhelésfüggő cache-t – egy rendszerbe. Ebben az esetben megtartod a dinamizmust, de ha nő a terhelés, akkor nem csak simán átállsz a cache használatra (mindig van kész cache, ha hirtelen kell átállni!), hanem átteszed a háttérbe a cache tartalmának az előállítását. Így megmarad a dinamizmus is, még extrém terhelésnél sem kell lemondani róla. Minden előnyét élvezed az összes technikának.

Egyedüli hátránya, hogy ilyen összetett cache rendszert összehozni nem könnyű. Az erre felkészített keretrendszerek már tényleg minden körülmény között megállják a helyüket és megérik az árukat, ami a nagy terheléses környezeteket illeti. Persze ehhez össze kell még házasítani egy reverse proxy rendszerrel is és jól kell kezelje az ESI beszúrásokat és minden más előnyét is amit adhat a reverse proxy.

### Végszó

Sok tapasztalatot szereztünk a saját keretrendszerünk (feracotta) fejlesztése és használata közben, a fentieket mind megvalósítottuk benne. Könnyen rá lehetett jönni, hogy egy rendszer teljesítményét mindig a leggyengébb eleme határozza meg, ezért nem elég csak egy dologra odafigyelni. Különösen nagy terheléses környezetekben bukik ki gyorsan, ha valami valahol hibádzik. A cache rendszer is csak egy eleme az egésznek. Kiélezett körülmények között mindennek tökéletesnek kell lennie. Például a cache nem oldja meg, ha sok adatot kell írni és nem oldja meg az extrém igényeket. Ilyen esetben sok minden mást is finomra kell hangolni (egymással is) és olyan megoldásokat bevetni, amely már túlmutat a cache-eken. Csak hogy CDN (content delivery network) megoldásokat emlegessem például, ahol földrajzilag közelebbi szerverről történik a statikus tartalom kiszolgálása. Vagy említhetném azt, ha sok adatot kell kezelni, írni, kiszolgálni, akkor a séma mentes adatbázisok használatát, vagy multi-master megoldásokat. Főleg, ahogy bejön a HA szócska is (high availability), azaz a nagy rendelkezésre állás. Ez nagyon sok mindent megváltoztat, de ez már egy másik cikk(sorozat) témája.

Ha nincs extrém körülmény, akkor pusztán a jó cache stratégia jelent megoldást a terheléses problémákra.

### +1 bónusz megoldás

Erre ugyan nem tértem ki, de muszáj megemlítenem, hogy a php session adatokat szintén célszerű memcached-ben tárolni. Nemcsak, hogy gyorsabb lesz a rendszer, hanem ha elosztott rendszerekről van szó, akkor a közös session kezelést nagyon könnyű így megoldani.
### Blog üzleti modell?
URL: https://blog.fps.hu/blog-uzleti-modell/
Last updated: 2026-07-17T08:49:25.000Z
Az idei [Media Hungary](https://www.mediahungary.hu/?ref=blog.fps.hu)\-n hívtak kerekasztal beszélgetésre és egy ötperces előadásra, ami a blog üzleti modelljéről szólt. Miért, minek, hogyan, milyen céllal írjuk a blogot. Érdekes volt a beszélgetés, de ami nagyon meglepett, hogy egyedül voltam színpadon a modellünkkel. Mindenki a hirdetéses megoldásról, tartalomnak álcázott reklámról beszélt, ami elég fura volt nekem így 2013-ban. :)

Ezért is gondoltam, hogy leírom ezt a modellt, ami nyilván egyáltalán nem újkeletű, sőt hazánkban is sokan alkalmazzák, ha nem is olyan formában, ahogyan mi. 

### fps blog

Az fps blogot kb. másfél éve indítottuk, tehát még fiatalnak mondható. Abszolút a PR és a Marketing stratégiánk egyik nélkülözhetetlen eleme. **Nem a direkt bevételről** szól, sokkal inkább az üzletünk növeléséről.

![What? Target? Why? How? Posztitek egy táblán](https://blog.fps.hu/content/images/2016/01/what-target-why-how-1.jpg)

#### Célközönség

Az fps alapvetően digitális ügynökségi tevékenységet folytat. A blogunk célközönsége a meglévő ügyfeleink, illetve olyan ügyfelek, akik a jövőben velünk fognak és akarnak dolgozni. Másodlagos célcsoportunk az iparágunkban dolgozók, érdeklődők és a belső munkatársaink. Azaz remélhetőleg TE! ;)

#### Miért?

Miért is ölünk időt és energiát a posztok írásába?  
Első és talán legfontosabb a **branding**, vagyis az fps brand, márka minél szélesebb körben való megismertetése. Nyilván ezt nem kell magyarázni, hogy miért.

A második kiemelkedő szempont a **SEO** kérdése. Szükség van arra, hogy a „népszerű” kifejezésekre megtaláljanak minket és erre nagyon jó módszer, a frissülő, változatos tartalmak írása. Írd be a Google-be például, hogy [responsive webdesign](https://www.google.hu/search?q=responsive+webdesign&aq=f&oq=responsive+webdesign&aqs=chrome.0.57j0l3j62l2.4132j0&sourceid=chrome&ie=UTF-8&ref=blog.fps.hu#hl=hu&gs%5Frn=12&gs%5Fri=psy-ab&tok=vSvtoLKRG0aGtQegOoSerA&pq=responsive%20webdesign&cp=15&gs%5Fid=4&xhr=t&q=responsive+web+design&es%5Fnrs=true&pf=p&sclient=psy-ab&oq=responsive+web+design&gs%5Fl=&pbx=1&bav=on.2,or.r%5Fqf.&bvm=bv.46471029,d.ZWU&fp=d89e7039530041af&biw=2560&bih=1345). A blogunk tumblr alatt fut. Két ok miatt választottuk ezt a microblogging rendszert. Egyrészt azért, mert a Google rendkívül szereti, gyorsan indexeli és „előnyben” részesíti, másrészt pedig itt könnyen elérjük a fiatal generációt, a későbbi leendő munkatársakat.

Az fps-nél a **szakértői marketingre** helyezzük a hangsúlyt, hiszünk benne, hogy nekünk ez az utunk. Többek között ezért is voltam a Media Hungary színpadán és ezért adunk elő számos konferencián, képzésen, meetupon. Kifejezett célunk, hogy szakértőket építsünk fel, ezért is láthatod a posztok alján a szerző fényképét és rövid bemutatkozóját. A blog által **arcot és hangot adunk a cégnek**, felépítjük a **hitelességét** és növeljük a **bizalmat** az fps iránt.

Mindemellett nem titkolt célunk, hogy az fps szexi és szerethető legyen. A posztokkal elégedettebbé kívánjuk tenni a meglévő ügyfeleket, általuk új ügyfeleket érünk el és ami még kifejezett célunk, hogy új munkatársakat toborozzunk, mely már számos esetben sikerült is.

Végül ha már a blog üzleti modelljéről van szó, akkor nem szabad megfeledkezni a **sales támogatásról** sem. Bevált módszer, hogy a szakértőink valamelyike ír egy témáról, utána a sales-es pár héttel később útjára indul és learatja a gyümölcsöket. Természetesen ennek a fordítottja is igaz, amikor van szabad kapacitásunk, akkor írunk egy olyan kisebb volumenű témáról, melyet a sales-es el tud adni.

**![Scarlett Johansson fps loógóval pózol és ki van írva: szexi és szerethető](https://blog.fps.hu/content/images/2015/12/fps-sexy.png)**

#### Mindezt hogyan, milyen módon?

Írunk **újdonságokról**, új **technológiákról**. Például az országban elsőként, vagy legalábbis az elsők között írtunk a responsive web designról, responsive emailről, vagy akár mobil SEO-ról. Bátran és büszkén állíthatom, hogy nekünk volt elsőként responsive web site-unk és mi küldtük ki hazánkban az első responsive hírlevelet is. Mindemelett nem elhanyagolhatóan írunk olyan témákról, melyekkel az **ügyfeleink számára fájdalmas kérdéseket** foglaljuk össze és remélhetőleg tesszük helyre a fejükben. **Megválaszoljuk a kérdéseiket**, **kielégítjük az információ éhségüket**.

#### Edukáció

Véleményünk szerint óriási jelentősége van. Elsősorban a meglévő, vagy leendő ügyfelek edukációja fontos. Nekik is, nekünk is jó, ha megfelelő információs alappal ülünk le az asztalhoz tárgyalni, vagy tervezni. Megjegyzem, sokszor küldjük el a posztjainkat emailben, ha olyan kérdés merül fel. Másodsorban hasznos a **belső képzés támogatása** miatt is. A kollégáknak kötelező a posztok olvasása, így gyakorlatilag egymásnak is írunk.

### Összefoglalva

Érdemes blogot írni, ajánljuk ügyfeleinknek is, mert kifejezett és jól látható üzleti sikereket hoz. Egyébként jómagam [írok egy saját blogot](https://blog.kolboid.eu/?ref=blog.fps.hu) is, aminek nincs üzleti célja, szimplán az önkifejezésem egyik formája, illetve a hitem abban, hogy a tudás mindenkié és attól, hogy azt megosztjuk másokkal, jobb lesz a világ.
### ASO az új SEO?
URL: https://blog.fps.hu/aso-app-store-optimization/
Last updated: 2026-07-17T08:49:32.000Z
Mi a legnehezebb dolog egy sikeres mobil alkalmazás elkészítésében? Ha a válaszod az, lefejleszteni az applikációt, akkor nagyon tévedsz. Egy alkalmazás attól lesz sikeres, ha sokan használják. De hogyan juttatod el a felhasználóknak?

Jelenleg több mint [800 000 iOS alkalmazás](http://www.apple.com/pr/library/2013/01/28Apple-Updates-iOS-to-6-1.html?ref=blog.fps.hu), közel [700 000 Android applikáció](http://www.appbrain.com/stats/number-of-android-apps?ref=blog.fps.hu) valamint mintegy [130 000 Windows Phone alkalmazás](http://blogs.windows.com/windows%5Fphone/b/wpdev/archive/2013/02/25/windows-phone-developer-updates-amp-offers-from-mobile-world-congress.aspx?ref=blog.fps.hu) érhető el az app store-okban. Ezen számok tükrében az igazi kihívás nem az, hogy készítsünk egy remek applikációt, hanem az, hogy az app store-ok keresési eredményeiben minél jobb pozícióba kerüljön, ezáltal minél több felhasználóhoz eljusson. És itt jön képbe az ASO, vagyis az App Store Optimization.

### Hogyan kezdjünk hozzá?

Az ASO lényegében egy egyszerűsített keresőoptimalizálás. Az applikációk adatlapjának tartalmát kell úgy megadni, hogy az alkalmazásra jellemző kulcsszavakra legyen optimalizálva, így könnyebben tudjuk eljuttatni a felhasználókhoz. Két kérdés szokott rögtön az elején felmerülni:

1. Hogyan fog feljutni az alkalmazás a találati lista élére?
2. Hogyan fog ott is maradni az élen?

Aki foglalkozott már SEO-val, pontosan tudja, milyen gyakran változnak a keresési algoritmusok. Az app store-ok keresői sem kivételek ez alól, bár itt azért ritkábban vannak változások, de a dinamikusan növekvő adatbázisok szükségessé teszik a keresési algoritmusok finomítását. Ezért itt is időről-időre ellenőrizni kell, hogy hogyan is áll az alkalmazásunk egy-egy kulcsszóra a találati listán. A keresési algoritmus itt is többféle szempontot vesz figyelembe különböző súlyozással, pl. van-e leírás, kulcssszavak, értékelések, vélemények, stb.. Érdemes figyelni, hogy alakul a találati pozíciónk az idő előre haladtával, így ki lehet tapasztalni, melyik tényező mennyire befolyásolja a pozíciót. (pl. egyre több értékelés érkezik, és ez változtat-e a pozíciónkon vagy sem.)

### Tartalom optimalizálás és kulcsszavak

Az alkalmazás leírásának optimalizálása semmivel sem nehezebb, mint egy weboldal tartalmáé. Sőt! Itt nem kell bajlódni a title, description, stb. szövegekkel sem. Van azonban néhány eszköz, mely segítheti a munkánkat:

#### App store kulcsszó forgalom becslő eszköz.

Ezen eszközök segítségével azt lehet megvizsgálni, hogy egyes kulcsszavakra mekkora a keresési arány. Webes keresési kulcsszavakhoz több ilyen eszköz is van, amely támpontot adhat egy-egy kulcsszó esetében, pl. [Google Trends](http://www.google.com/trends/?ref=blog.fps.hu), vagy a [Google Adwords kulcsszóválasztó eszköze](https://adwords.google.com/o/Targeting/Explorer?%5F%5Fc=1000000000&%5F%5Fu=1000000000&ideaRequestType=KEYWORD%5FIDEAS&defaultView=2&ref=blog.fps.hu). Van egy **[magyar fejlesztésű eszköz](http://appstoreseo.hu/post/49698827119/az-ios-keywords-projekt?ref=blog.fps.hu)** is, amellyel az Apple App Store kulcsszavainak keresési eredményeit tekinthetjük meg.

#### Analitika

Használjunk valamilyen analitikai rendszert az applikációhoz. Ez ugyan kevés adatot szolgáltat az app store optimalizáláshoz, viszont rengeteg hasznos információval szolgál az applikációt használó látogatókról, mely segítheti egyrészt az alkalmazás továbbfejlesztését, másrészt felhasználhatjuk az optimalizáláshoz is a kapott információkat.

#### Marketing

Az app store-okon kívül is tudjuk népszerűsíteni az applikációnkat, mellyel az ASO-t is tudjuk erősíteni. Ugyanis az egyik rangsorolási faktor, hogy hányan töltötték le az adott app-ot. Weboldalunkon is el tudjuk helyezni a store-ba vezető linkeket, de akár PPC kampányokat is futtathatunk úgy, hogy a hirdetésre kattintva (már ha mobil eszközről érkezik a felhasználó) rögtön a store letöltés oldalára irányíthatjuk a látogatót. QR kód segítségével akár print hirdetésekkel, plakátokkal is el tudjuk juttatni az érdeklődőket az applikációnk oldalára. Ezeken kívül még számtalan lehetőség van arra, hogy népszerűsítsük az alkalmazásunkat, itt csak a büdzsénk szabhat határt.

![letöltési statisztikát mutató grafikon](https://blog.fps.hu/content/images/2015/12/letoltes.png)

### Tippek és tanácsok

Íme néhány tipp és tanács, hogy minél népszerűbbé tegyük applikációnkat:

- **Válasszunk jó nevet:** egy jó név kiválasztása félig művészet és félig tudomány. Legyen hangzatos, de lehetőleg kulcsszót is tartalmazzon, és jó lenne, ha márkanevet is tartalmazna, tehát nem egyszerű feladat. Hosszú távon viszont nagyon is kifizetődő lehet. A legjobb név az, amely utal arra, mire használhatjuk és még hozzá kapcsolunk valamilyen másik szót, pl.: PhotoShare, TweetDeck, stb.. Törekedjünk arra is, hogy 12 karakternél ne legyen hosszabb a név, ugyanis a mobil eszközökön ennél hosszabb szöveg nem jelenik meg.
- **Legyen ütős a bevezető:** Átlagosan 120 karakterünk van arra, hogy meggyőzzük a felhasználót arról, hogy ezt az alkalmazást kereste és töltse le. Ennyi szöveg látszódik ugyanis a tovább gomb előtt. Ha ezzel a szöveggel sikerül további kattintásra ösztönözni a felhasználót, jó eséllyel le is fogja tölteni az appunkat. Tehát ne sajnáljuk az időt arra, hogy jól fogalmazzuk meg a bevezetőt. Természetesen a legfontosabb kulcsszavakat ne hagyjuk ki belőle. A kulcsszavakat se felejtsük el megadni, simán, vesszővel elválasztva, max. 100 karakter (négy-öt kulcsszó)
- **Attraktív képek és ikonok:** az első benyomás a legfontosabb, átlagosan két másodperc alatt eldöntjük, tetszik-e az adott alkalmazás vagy sem. Nagyon fontos, milyen screenshotokat töltünk fel az appról, legtöbbször már a képek alapján eldöntjük, tetszik-e nekünk, érdekel-e minket. Ha felkeltettük az érdeklődést, a szöveget csak ezután fogják elolvasni, tehát erre különösen figyeljünk. Az alkalmazás ikonjának kialakítására is fordítsunk figyelmet. Sok ember ugyanis csak azért tölt le egy-egy alkalmazást, mert nagyon tetszik neki az ikonja :)
- **Értékelés:** a népszerűség egy fontos rangsorolási faktor az app store-okban. Minél népszerűbb egy app, annál feljebb kerül a találati listán. A felhasználói értékelés központi eleme a népszerűségnek. A magas felhasználói értékelés ugyanis pozitívan befolyásolhatja az új felhasználókat, nagyobb eséllyel töltenek le egy olyan applikációt, melyet sokan és magas pontokkal értékeltek. És ez nem csak a letöltésre sarkallhatja őket, hanem arra is, hogy ők is értékeljék, valamint elmondják a véleményüket. A fejlesztőknek érdemes figyelni ezeket a véleményeket, egyrészt ha valamilyen hibát fedeznek fel a felhasználók, tudják javítani, másrészt hasznos információkat adhatnak új funkciókhoz, akár az app továbbfejlesztéséhez is stb.

Ugye, hogy nem is olyan egyszerű népszerűvé tenni egy alkalmazást? Maga az applikáció elkészítése csak az első lépés, majd jön az ASO, a marketing, és remélhetőleg a sok belefektetett munka meg is hozza gyümölcsét, azaz egy népszerű és kedvelt applikációt sikerült a piacra dobnunk.
### Hogyan válassz digitális ügynökséget?
URL: https://blog.fps.hu/digitalis-ugynokseg-valasztasa/
Last updated: 2026-07-17T08:49:42.000Z
Szükséged van egy web site-ra, mobil appra, vagy még azt sem tudod mire van szükséged pontosan? Azonnal jönnek a kérdések: mi alapján válasszak a sok cég közül, milyen szempontokat érdemes figyelembe vennem, milyen úton induljak el? Ezekre a kérdésekre adunk most választ.

Ahogy a címből is kiderül, csak akkor olvass tovább, ha nem low-cost megoldásra van szükséged. Olyan esetekre ott vannak az ingyenesen igénybe vehető szolgáltatások, mint a wix.com holnapépítője és sok más területen is találsz ingyenes, vagy nagyon olcsó és egyben jó szolgáltatást.

Először lássuk, hogy tapasztalataink szerint mit vársz el egy digitális ügynökségtől.

### Mit vársz el?

- Szakértelmet
- Megoldást
- Rugalmasságot
- Kreativitást
- Pontosságot
- Professzionalizmust
- Bizalmat
- Innovációt
- Minőségi szolgáltatást
- Ügyfélközpontúságot
- Reputációt

Nyilván kaptál ajánlást, kerestél az interneten és tudod, hogy kiket akarsz megkeresni a projekteddel. Most pedig 18 pontba szedve olvasd végig, szerintünk mire kell figyelmet fordítanod a választás során.

### 1\. Keress rá a cég nevére Google-ben

Sokat elárul, mit találsz róluk. Az ügyfelek sok esetben megosztják másokkal pozitív és negatív tapasztalataikat a közösségi oldalakon, blogok kommentjeiben, fórumokon. Ebből kiderül számodra az is, mennyire foglalkozik a cég az online megjelenésével is. Ha ismersz olyan céget, akinek a kiszemelt ügynökség dolgozik, érdemes náluk is érdeklődni, információt gyűjteni.

### 2\. Mennyire vannak jelen az online világban?

Van az ügynökségnek Facebook oldala, megtalálhatók LinkedInen, vagy más közösségi oldalakon? Ebből tudhatod, hogy törődik a brandjével és stratégiai gondolkodás áll a háttérben. Ha szimplán egy web sitejuk van, akkor feltételezheted, hogy nincsenek tisztában a digitális marketinggel.

### 3\. Mióta vannak jelen a piacon?

Habár nem mindig igaz, de minél régebb óta létezik egy ügynökség, annál biztosabb, hogy sokáig tudsz rájuk számítani. Ha például egy cég több, mint 5 éve folytatja tevékenységét az azt jelenti, hogy valószínűleg a cég mögött jó menedzsment és szervezet található és biztos alapokon áll.

### 4\. Mekkora a cég, elég nagy ahhoz, hogy velük dolgozz?

Fontos tudnod, hogy mekkora csapatból áll a cég. A legtöbb webes cég mögött egy grafikus és egy fejlesztő található, amivel természetesen nincs semmi probléma, de tudnod kell, hogy ma már ettől sokkal több kompetenciáira van szükség egy sikeres projekthez. Néhány ember nem érthet mindenhez, illetve egy kis csapat bármikor eltűnhet a piacról. Az is fontos, hogy milyen szinten dolgoznak alvállalkozókkal, külsős kollégákkal, mert ez a mindennapi kommunikációban, gyors reagálásban sokszor problémát jelenthet. Persze az is lehet probléma, ha a cég túl nagy! Ha nincs jól szervezve a cég, akkor nagy mammuttá válhat, ahol erős iparos munkát végeznek, ami a kreativitás rovására mehet.

### 5\. Milyen szolgáltatásokat nyújtanak?

Hiába van most csak egy szimpla web site-ra szükséged, holnap megjelenik majd az igényed más szolgáltatásokra is. Nyilván nem akarsz sok céggel külön dolgozni, ezért célszerű ilyen szempontból is megvizsgálni a választandó ügynökséget. Íme egy lista, milyen szolgáltatásokra van, vagy lehet szükséged a jövőben:

- Web fejlesztés
- Responsive design
- Web, mobil design
- Print design
- Keresőoptimalizálás (SEO)
- PPC Menedzsment
- Közösségi Média Marketing
- Email Marketing
- Banner kampány
- Médiatervezés
- Stratégiai tervezés
- Kreatív koncepció
- Arculattervezés
- PR kampány
- Tartalom fejlesztés
- Multimédia (audio, video)
- Mobil applikáció fejlesztés (Android, iOS, Windows Phone)
- User experience (Felhasználó kutatás, Felhasználói tesztelés, Felülettervezés, stb.)

### 6\. Nézd meg a porfóliót!

Sokat elárul egy cégről, mit raknak ki a polcra. Ha több száz referencia van, akkor az arra utalhat, hogy futószalagon gyártanak és nem fókuszálnak Rád, vagy a projektre. Nyilván ez nem minden esetben igaz, de figyelmeztető jel lehet. Keress olyan referenciát, ami hasonló a Te projektedhez. Ha a cég még nem vitt végig olyan jellegű projektet, amire szükséged van, az jelentős kockázatot rejt magában. Figyeld meg a designokat, azok mennyire esztétikusak, mennyire könnyen értelmezhetők, használhatók. Nem utolsó sorban hívd fel 2–3 ügyfelüket és kérdezz rá mennyire elégedettek a céggel és annak szolgáltatásaival.

### 7\. Mennyire követik a trendeket és alkalmazzák azokat?

Az online, digitális világ folyamatosan fejlődik, melyet követni kell, tehát szükséges, hogy foglalkozzanak ezzel. Leszűrheted a kommunikációjukból (social media tevékenység), illetve ha blogot írnak, érdemes beleolvasnod néhány írásukba. Azért fontos ez számodra, mert egy ilyen cég segíthet abban, hogy mindig egy lépéssel előrébb járj a konkurenciád előtt.

### 8\. Kommunikáció

Talán az egyik leglényegesebb elem. Minden sikeres projekthez feltétlen szükséges a sok és értékes kommunikáció. Ha már telefonon keresztül, vagy az első találkozó alkalmával is kétséged merül fel a kommunikációval kapcsolatban, ne válaszd azt a céget. A személyes kémiára szükség van! Az online, digitális világ jellemzője, hogy telis-tele van hárombetűs rövidítésekkel, szakkifejezésekkel. Az a cég, akik ezek mögé bújik és meg sem próbál az általad is ismert nyelven kommunikálni, valószínűleg nem jó alternatíva. Persze sokszor elkerülhetetlen a szakzsargon, de ha rákérdezel és segítséget kérsz, akkor nyugodtan elvárhatod, hogy röviden és egyértelműen megvilágítsák a mögöttes tartalmat.

### 9\. Tudnak nemet mondani, van saját véleményük?

Hidd el, az ügyfélnek nincs mindig igaza (bocsánat)! Az érdeked nem azt diktálja, hogy bólogató céget bízz meg, akik gondolkodás nélkül csinálják, amit mondasz nekik. Sokkal inkább egy partnerre van szükséged, akik értenek ahhoz, amit csinálnak, és határozott véleményük van arról, hogyan kell azt jól csinálni. Ebből a partnerségből születnek a nagy dolgok. Nézz körbe a cég tájékán, vannak-e ott olyan emberek, akik szakmai körökben is ismertek, elismertek, előadásokat tartanak.

### 10\. Megértik, vagy meg akarják érteni az üzleted?

Ahhoz, hogy a projekted elérje célját, kiemelkedően fontos, hogy az ügynökség teljesen tisztában legyen az üzleti céljaiddal. Tudniuk kell azt is, hogy ki a terméked, szolgáltatásod célközönsége. Ha nem tesznek fel ilyen jellegű kérdéseket, akkor máris kezdhetsz gyanakodni.

### 11\. Az online marketingre mekkora hangsúlyt helyeznek?

Azok a cégek, akikre szükséged van, pontosan tudják, hogy a projekted csak egy fázisa a termék elkészítése. Az online marketing központi jelentőséggel bír. A keresőoptimalizálás, az online, esetenként offline kampányok (PPC, SMO, video, stb.), az email marketing, a blogok írása, landoló oldalak (landing page) létrehozása, a közösségi média erejének kihasználása ma már mind szükséges ahhoz, hogy sikeres legyen a projekted.

### 12\. Felhasználó központúak, foglalkoznak a használhatósággal?

Kulcsfontosságú tudnod, hogy a termék, amit az ügynökség készít, végső soron nem Neked készül, hanem a célközönségednek. Ők lesznek a felhasználók. Ha őket elégedetté teszed, akkor Te is elégedett leszel, ami által az ügynökség is elégedett lesz. Ez mindenki számára előnyös. Foglalkoznak egyáltalán felhasználói kutatással, felhasználói teszteléssel, van olyan ember, aki megtervezi a terméket és/vagy annak felületét pszichológiai, ergonómiai, használhatósági szempontok alapján?

### 13\. Mennyire kötnek magukhoz?

Nem érdeked az, hogy az ügynökség magához kössön. A domainek legyenek a céged nevén, a tárhely szolgáltatást jobb, ha a céged veszi igénybe, a mobil applikációkat is a céged nevében tegyék ki a különböző Store-okba, az SSL tanúsítvány is a neveden legyen. Ezek mindegyikénél segítséget kell nyújtania az ügynökségnek. Ha nem így teszel, akkor ha később esetleg megromlik a kapcsolat és el akarsz válni, nehéz dolgod lesz. Ide tartozik még, hogy ha az ügynökség egyedi, saját fejlesztésű rendszerrel dolgozik, kérj fejlesztési dokumentációt és rendszertervet hozzá.

### 14\. Milyen a munkafolyamatuk?

Kérdezz rá, pontosan tisztában kell lenned, hogyan dolgoznak, mit és mikor várnak el cégedtől (anyagot, jelenlétet, döntést). Mérföldkövekhez kötik a munkát, van-e egyáltalán tesztelés, valamilyen agilis módszertant alkalmaznak, használnak ticketing systemet? Ezek mind fontosak a választásod szempontjából, olyat válassz, ami a Te elvárásaidnak is megfelel, akkor lesz sikeres a projekted.

### 15\. Jó ár/érték arány

Az ár tipikusan az a tényező, ami könnyen eldöntheti a választást. Érdemes megfontolnod az árat aszerint is, hogy pontosan mit kapsz érte, mekkora lesz a ROI (Return of Investment). Ha olyan terülten indítasz projektet (pl. ecommerce, mcommerce), ahol egyértelmű, jól mérhető bevétel származik a fejlesztésből, akkor mindenképpen befektetésként kell tekintened a projektre és annak árára is. Megjegyzendő, hogy azok a cégek, akik a ROI-val nem számolnak, vagy nem határozzák meg a mérésnek szükségességét és formáját, problémások lehetnek. Ha sokallod az árat, nyugodtan kérdezz rá, hogy miért kerül annyiba, miért drágább, mint a többieké. A megnyugtatóan drága nem biztos, hogy a legjobb is egyben!

### 16\. Milyen technológiát alkalmaznak?

Saját fejlesztésű rendszert használnak, vagy open-source alapokon (WordPress, Joomla, Drupal, Magento stb.) fejlesztenek? Mindegyik alkalmazott technológiának megvan a maga előnye és hátránya, tehát nincs jó vagy rossz választás, igazából a projekted határozza meg, melyik úton érdemes elindulni. Kérd ki a tanácsukat, addig kérdezz, míg laikusként is világossá válik a választás.

### 17\. Ajánlanak oktatást, amikor a rendszered elindult?

Elengedhetetlen számodra, hogy a cég oktatás keretein belül megmutassa, elmagyarázza, hogyan kell használnod a CMS-t (tartalomkezelő rendszert). Mire figyelj oda, mit ne, és mit hogyan csinálj. Ha ilyet nem ajánl, kérd!

### 18\. Support és garancia

Mikor útjára indult a projekted, biztosan tudod, ez csak a kezdet. Tudd, hogy milyen óradíjakon és milyen feltételekkel áll rendelkezésedre a cég. Kiemelkedően fontos, hogy nincs tökéletes program, szinte biztos, hogy lesznek hibák a rendszerben, melyek előbb-utóbb a felszínre kerülnek, ezért a komolyabb cégek garanciát is vállalnak munkájukra. Ha nincs garancia, vagy az kevesebb, mint 3 hónapra terjed ki, akkor érdemes átgondolnod, akarsz-e ilyen feltételekkel együtt dolgozni a céggel. A másik izgalmas pont a rendelkezésre állás. Ha komoly probléma történik a rendszereddel (feltörik, megsérül az adatbázis stb.) a legfontosabb időszakban (szinte biztos, hogy akkor következik be), vajon azonnal reagálni fog-e a cég és segít a bajban? Erre szolgál az SLA szerződés (Service-level agreement), melyet érdemes megkötnöd, ha ilyet nem ajánlanak, akkor nem érezheted biztonságban magad.

Ha ezek után is úgy érzed, hogy a megfelelő ügynökséget választottad, akkor a munka csak most kezdődik. Ha valamelyik rész nem volt ismerős, akkor javasoljuk, kezd elölről a keresést!

Nyomtasd ki a cikket és vidd magaddal! Várunk szeretettel :)
### Mi az a tartalom stratégia?
URL: https://blog.fps.hu/tartalom-strategia-content-strategy/
Last updated: 2026-07-17T08:49:51.000Z
Te tudod, mit takar a tartalom stratégia kifejezés? Sokan úgy gondolják, valami szövegírással kapcsolatos dologról van szó. Ez nem teljesen hamis, de elég félrevezető.

Mi, akik weboldalakat tervezünk és készítünk, már jó pár éve beszélünk olyan fogalmakról, mint felhasználói élmény, információs architektúra, tartalomkezelő rendszerek, fejlesztés, metaadatok, webdesign, felhasználói kutatások, és még sorolhatnánk. Ezek megkönnyíti és segíti a felhasználóknak a tartalom fogyasztást.

Ha szöveges tartalomról van szó, mindig csöndben vagyunk. Azt gondoljuk, ez nem a mi feladatunk, hanem az ügyfélé. Azok, akik a weboldalakat készítik, nem aggódnak azon, hogy milyen tartalom kerül az oldalra.

Mit gondolsz, véletlen egybeesés, hogy ezek a tartalmak az esetek többségében rosszak? A tartalom kezelése rendezetlen. A rendbetétele viszont bonyolult, fájdalmas és drága. És mégis fontos. A tartalom a lényeg. Megérdemli az időt és a figyelmet. És ez az a pont, amikor tartalom stratégiára van szükség.

### Mit értünk tartalom alatt?

Minden tartalom. A weboldal szövege, a struktúrája, a designja, a metaadatai, mind-mind tartalom. Ezek alkotják együttesen A tartalmat. És akkor lesz ez a tartalom a felhasználók számára is értékes, ha megfelelően van strukturálva.

### Mi a tartalom stratégia?

Tartalom stratégia lényege, hogy olyan tartalmat hozunk létre, mely hasznos és használható a felhasználók számára. Egy tartalom stratégának nemcsak azon kell dolgoznia, hogy mely tartalmakat hogyan publikáljunk, hanem azon is, hogy az minden részletében a felhasználó érdekeit szolgálja. Ellenkező esetben a tartalom stratégia nem stratégia, csak egy gépies tartalom előállítás, amire senkinek sincs szüksége. A tartalom stratégia megvalósításáért a tartalom stratéga a felelős.

Amikor egy weboldal készítési folyamat elkezdődik, még a tervezés megkezdését meg kell előznie egy részletes elemzésnek, melynek során megvizsgáljuk a már meglévő szöveges tartalmat. Ez egy rendkívül fontos feladat, amely gyakran kimarad a projekt folyamatokból.

#### A tartalom stratégia meghatározza:

- a fő témát és üzenetet
- a célokat
- a metaadatokat és a kapcsolódó tartalmi attribútumokat
- a keresőoptimalizálást
- a további tartalom stratégiai és publikálási javaslatokat

![szöveg, kép, videó, struktúra, meta ikonok](https://blog.fps.hu/content/images/2015/12/object.png)

### De ez nem minden!

Rachel Lovinger, a [Content Strategy: the Philosophy of Data](http://boxesandarrows.com/content-strategy-the-philosophy-of-data/?ref=blog.fps.hu) cikkében ezt írja: a tartalom stratégia fő célja, hogy úgy alakítsuk ki a tartalmat, hogy az egyértelmű, jelentőségteljes legyen, és interaktív élményt nyújtson a felhasználóknak. A kommunikációnak minden szempontból hatékonynak kell lennie.

És ez egy komoly feladat. Valójában túl sokféle kommunikációs szempontot kell figyelembe venni, amelyhez igencsak komoly és alapos tudásra van szükség.

### Van olyan, hogy tartalmi stratéga?

Röviden: van. De a legtöbb esetben nem egyetlen személyről van szó, hanem egy csapatról, melyben megtalálhatóak a szükséges kompetenciák.

Nagyon sokan összetévesztik a tartalom stratégát a szerkesztővel. A tartalom stratégia többről szól, mint az írott szöveg. A tartalom stratégáknak törekedniük kell arra, hogy a tartalom olvasható, érthető, kereshető és megosztható legyen.

A tartalom stratégia célja, hogy maximalizálja a tartalom hatását az üzleti célok elérése érdekében. Tekintsük az üzleti tartalmat, mint egy közeget, melyet stratégiailag célzott elhelyezéssel juttatunk el a felhasználókhoz úgy, hogy az egyértelműen közvetítse az üzenetünket és konverzióra inspirálja őket. Egy tartalom stratégának értenie kell a szövegíráshoz, a keresőoptimalizáláshoz, a taxonómiához (rendszertan), hogy maximálisan támogatni tudja a konverziót. Ez kiegészül web tervezési stratégiával, irányelvekkel és egyéb eszközökkel.

### Mi minden szükséges ehhez?

Számos szakterület kapcsolódik a tartalom stratégiához, lássuk, melyek ezek.

#### Szerkesztési stratégia

Meghatározza az irányelveket, melyek az összes online tartalmat szabályozza, úgymint jogi szabályozás, felhasználók által létrehozott tartalmak, stb.. Ezek a gyakorlatban meghatározzák a szerkesztőség munkáját, beleértve a tartalom életciklusát is.

#### Szövegírási stratégia

Hasznos és használható tartalmat kell készíteni a publikáláshoz. Ez a feladat sokkal több, mint okos szövegírás. Egy jó szövegírónak tudni kell értelmezni az információs architektúrát, ismernie kell a keresőoptimalizálás alapjait, stb.

#### Metaadat stratégia

Azonosítja és strukturálja a metaadatokat. A jól strukturált adatok segítségével rendszerezett, használható tartalmat lehet nyújtani a felhasználóknak (és természetesen a keresőknek is).

#### Keresőoptimalizálás

Az a folyamat, amikor úgy rendezzük és szerkesztjük a tartalmat az oldalon, hogy a keresők számára minél értékesebb legyen, ezzel is segítve a látogatókat a tartalom fogyasztásában.

#### Tartalom menedzsment stratégia

Meghatározza a szükséges technológiákat, hogy megfelelően szolgálja ki a rendszerezett tartalmat. A tartalom életciklusa és a munkafolyamatok a legfontosabb részei ennek a stratégiának.

#### Tartalmi elosztó csatorna stratégia

Meghatározza, hogy hol és hogyan lesz elérhető az adott tartalom a felhasználók számára. (például az email marketing egy módja a tartalom eljuttatására a felhasználók felé)

Ezek a legfontosabb területek, ezeken kívül természetesen van még számos dolog, melyet figyelembe kell venni tervezéskor.

### DE!

Ha egy weboldal tervezésénél nem fordítunk időt és energiát a tartalmi stratégiára, könnyen alábecsülhetjük a projektre szánt időt és költségeket. Csináljuk meg jól, mert mi, az ügyfelünk és a felhasználók is megérdemlik, hogy minden szempontból használható terméket állítsunk elő!

Már az első pillanattól kezdve mindig tartsuk szem előtt a célt és ne érjük be kevesebbel! Amíg nem vállaljuk fel azt, hogy a stratégiai tervezésnél figyelmet fordítsunk a tartalom stratégiára, továbbra is silány tartalmakat fogunk előállítani. Mindig az üzleti cél lebegjen a szemünk előtt. Ha az ügyfeleink nem tudják, mit is szeretnének, segítsük rávezetni őket a jó útra, hogy elégedett felhasználói legyenek, melytől az ügyfelünk is elégedett lesz, így mi is.

Sose mondjuk azt, hogy a tartalom más dolga. Igenis a Mi dolgunk! Beszéljünk az ügyféllel, tudjuk meg, mi a cél és cselekedjünk! A tartalom igenis számít!

*([Fejléckép hátterének forrása](http://www.thisiscolossal.com/2012/08/a-giant-labyrinth-constructed-from-250000-books/?ref=blog.fps.hu))*
### Csali hatás
URL: https://blog.fps.hu/decoy-effekt-csali-hatas/
Last updated: 2026-07-17T08:50:01.000Z
Nagy sikert aratott a [horgonyzásról írt korábbi poszt](https://blog.fps.hu/horgonyzas-anchoring-ecommerce/), ezért úgy döntöttem írok még a témában. Ezúttal a csali, csalétek hatásról (decoy effect), vagy más nevén az asszimetrikus dominanciáról lesz szó.

### Mi a csali hatás?

A [decoy effect](http://en.wikipedia.org/wiki/Decoy%5Feffect?ref=blog.fps.hu) lényege röviden: Van két választási lehetőség és ha egy harmadik opciót beiktatunk, akkor befolyásolhatjuk a választást, mindezt úgy, hogy a csalinak elhelyezett opciót senki sem fogja választani.

Íme egy szemléletes kutatás, melyet Dan Ariely és csapata végzett el, majd később zseniális [Predictably Irrational](http://www.amazon.com/dp/0061353248?ref=blog.fps.hu) című könyvében írt le. (ajánlott irodalom)

Egy internetes újságelőfizetést vett alapul és két csoporton külön vizsgálta a választásokat:

![A és B ajánlat kép formájában](https://blog.fps.hu/content/images/2015/12/ajanlat.png)

Az eredmények magukért beszélnek. A „B” ajánlatnál beraktak csalinak egy csak print előfizetést, de ugyanazzal az árral, mint a nagyobb Internetes és Print előfizetés csomagé. Ezáltal sokkal többen választották a „nagyobb” csomagot, úgy hogy az agyunk által előnytelennek minősített csalit egyáltalán nem választották.

### A kényelmes agyunk

[fMRI technológiával](http://en.wikipedia.org/wiki/Functional%5Fmagnetic%5Fresonance%5Fimaging?ref=blog.fps.hu) 1990-es évek eleje óta vizsgálják az agyunkat, melynek eredményeit, illetve magát a techonlógiát a 2000-es évek óta használja fel a neuropszichológia és a neuromarketing. Akshay Rao, marketing professzor [végzett kutatást a decoy effekttel kapcsolatban](http://www.thisisreallyinteresting.com/inside-consumer-mind-brain-scans-reveal-choice-mechanism/?ref=blog.fps.hu).

A kutatás megmutatta, hogy két választás esetén az agyunk nagyon komoly erőfeszítéseket végez, hogy végső döntésre jusson. Az elhelyezett csali megkönnyítette és kényelmesebbé tette a dolgát. 

### Hogyan alkalmazható még?

Másik alkalmazása a csalinak, amikor egy termék eladását szeretnék növelni. Szimplán mellé kell tenni egy ugyanolyan terméket, aminek egyetlen tulajdonságát megváltoztatod és legalább 50%-kal megnöveled az árát az eredetihez képest. A csaliból eladsz párat, míg az eredeti termék eladása megduplázódik.

### Védekezés

Ha kicsit is tudatosak vagyunk és feltesszük magunknak a kérdést mielőtt megnyomjuk a gombot: „Biztos, hogy erre van szükségem?”, akkor képesek vagyunk felülbírálni a hatást. Persze, ha impulzus vásárlásról van szó, illetve egyéb módszerekkel hatnak a döntéshozó ősagyunkra, akkor esélyünk sincs. :)
### Horgonyzás
URL: https://blog.fps.hu/horgonyzas-anchoring-ecommerce/
Last updated: 2026-07-17T08:50:13.000Z
Besétálsz egy üzletbe, ahol az első óriás táblán egy cipőt hirdetnek 400 000 Forintos áron. Jót nevetsz magadban, ezek nem normálisak, ennyiért adni egy cipőt?! Továbbsétálsz, majd meglátsz egy szuper nadrágot 30 000 Forintért, megtetszik, megveszed. Nyilván nem tudod, hogy ugyanaz a nadrág egy másik boltban csak 20 000 Forint.

Hobbipszicho vagyok, sokat foglalkozom a témával, különösen az érdekel, hogyan használhatjuk fel az agykutatás és a pszichológia eredményeit a webes, mobilos tervezéseknél. A leadben leírt történet tipikus példája az ún. [anchoring](http://en.wikipedia.org/wiki/Anchoring?ref=blog.fps.hu) (horgonyzás) kognitív torzításnak.

### Mi az a horgonyzás?

Pongyolán fogalmazva: a horgonyzás egy olyan kognitív torzítás, amikor túlságosan megbízunk az elsőként meglátott információmorzsában, azt standardnak, referenciapontnak veszi az agyunk, és ami jelentős hatással van a döntéshozatalra.

Visszakanyarodva a fenti történethez. A vásárló agya lehorgonyzott a 400 000 Forintos árnál és onnantól kezdve mindent ahhoz viszonyított. így a 30 000 Forintos nadrág már nem is volt számára olyan drága.

#### Hogyan tudod ezt hasznosítani a webshopodban?

**A nyitóoldaladra a legdrágább terméket tedd ki!** Az Apple is jól tudja ezt, ha megnézed az Apple Store-t, akkor láthatod, hogy a 27“-os iMac-kel indít. Az autószalonok is jól tudják ezt, a kirakatba a luxus autót teszik ki.

![Apple Store nyitó oldala képernyőkép](https://blog.fps.hu/content/images/2015/12/imac.png)

Ha a webshopod kategória-, listaoldalára érkezik a felhasználó (SEO-ból, Social-ből stb.), **legyen a terméklista ár szerint csökkenő sorrendben**, azaz a legdrágább termékkel indítsd. Ugyanez igaz egy többtermékes hírlevélre, vagy landoló oldalra (landing page).

A horgonyzás kihasználása jó a kereskedőnek, de nem túl jó a vásárlónak. Az a helyzet, hogy vásárlóként ennek [tudatos kivédése rendkívül nehéz](http://scienceblogs.com/cortex/2010/05/26/anchoring/?ref=blog.fps.hu). Az egyetlen megoldás, ha tudsz erről (ha eddig nem, most már igen) és rendszeresen eszedbe juttatod, felismered, ezáltal tréningezed az agyad.
### SEO vs. PPC vagy SEO és PPC?
URL: https://blog.fps.hu/seo-vs-ppc-adwords/
Last updated: 2026-07-17T08:50:22.000Z
„Keresőoptimalizáltassam az oldalam, vagy inkább PPC kampányra költsek?” – teszik fel nekem a kérdést gyakran az ügyfelek. Legtöbbjüknek van halvány sejtése ezekről a fogalmakról, de arról már kevésbé tudnak, hogyan is kapcsolódnak egymáshoz. Itt az idő, hogy tisztázzuk: mire jó a SEO és mire a PPC.

### Keresőoptimalizálás (SEO)

A keresőoptimalizálás az online marketing eszköztárának egyik eleme. A SEO (Search Engine Optimization) a weboldalak optimalizálása a keresőkben való megjelenésekre az organikus találati listában. Minél jobb pozícióban jelenik meg egy oldal a keresőben, annál több látogatást eredményez. A SEO sok paramétert vesz figyelembe és próbálja a legoptimálisabban összehangolni ezeket:

- a keresőmotorok működését,
- az emberek keresési szokásait,
- a keresőszavakat vagy kulcsszavakat,
- az oldalra mutató linkeket, stb.

Egy weblap optimalizálása során alapvető a tartalomoptimalizálás és a forráskód szintű keresőoptimalizálás a kulcsszó relevancia növelése és az indexelés megkönnyítése érdekében. Ezeken kívül szükséges még belső linkhierarchia kialakítása, valamint a linképítés a jobb találati pozíciók eléréséhez.

A keresőoptimalizálás hosszabb folyamat, első lépésként tartalomoptimalizálást és forráskód szintű keresőoptimalizálást kell végezni a kulcsszó- és keresési trend elemzés eredményeinek, valamint a weboldal üzemeltetők céljainak megfelelően. Az oldal betöltődési sebessége is fontos keresőoptimalizálási szempont, ami szintén a forráskód szintű optimalizálás része. (Ha érdekelnek a részletek, olvasd el erre vonatkozó [posztunkat](https://blog.fps.hu/sebesseg-optimalizalas-gyors-honlap/ "Sebesség optimalizálás")) Ezután jön a belső linkstruktúra kialakítása. Ha ezek mind megvannak, akkor jöhet a következő lépésként a linképítés és a folyamatos monitorozás. Átlagosan legalább két-három hónap szükséges ahhoz, hogy kézzelfogható eredményeket lehessen felmutatni, de a későbbiekben is fontos a kulcsszavak monitorozása és a linképítés.

Költségek szempontjából van egy kezdeti nagyobb befektetés, amíg az oldal optimalizálása zajlik, majd havi szinten jelentkezik egy kisebb üzemeltetési költség. Normál esetben a befektetett költségek gyorsan megtérülnek, hosszú távon mindenképp költséghatékony módszer. Az eredmények pontosan mérhetőek különféle analitikai rendszerekkel (pl. Google Analytics).

A SEO elegendő profitot generálhat. Az alapvető kereső funkciók ingyenesek, a részben titkos kereső algoritmusok viszont változhatnak, így nincs előre kalkulálható biztos eredmény. ( A [Google Panda és Pingvin](https://blog.fps.hu/post/24944047905/google-pingvin-panda-seo "Google Panda és Pingvin") algoritmusokrók is írtam korábban) A bizonytalan jövőbeli működés miatt a csak keresőoptimalizálásra építő weboldalak esetén fennáll a veszély a váratlan veszteségre egy esetleges jövőbeli negatív hatás miatt.

### PPC kampány

A PPC (Pay per Click) alapú hirdetések abban mások a „hagyományos” hirdetésekhez képest, hogy kulcsszavakra és kifejezésekre célzottan jelennek meg a hirdetések. A hirdetők ezekre a kulcsszavakra licitálnak, majd ezen szavakra releváns környezetben jelennek meg (részben a keresőkben, részben a hirdetéseket értékesítő weboldalakon).

A kattintások ára kulcsszavanként nagyon eltérő lehet. Ritkán használt, vagy alacsony keresési arányú kulcsszavakra pár forintért is hirdethetünk, viszont a sokat keresett, népszerű kulcsszavakért akár több száz forintot is fizethetünk kattintásonként. Egy kattintás ára, illetve egy kulcsszó pozícióját a minőségi mutató (QS, quality score) határozza meg, mely több összetevőből adódik össze:

- kulcsszó relevancia: mennyire releváns a hirdetési kulcsszó a weboldalra nézve
- landing page minősége: fontos, hogy a céloldal a rá mutató hirdetésekre és kulcsszavakra releváns legyen, valamint sokat számít, ha az oldal keresőoptimalizált
- átkattintási arány (CTR): minél több az átkattintás, annál olcsóbbá válhat egy-egy kulcsszó
- hirdetési szöveg relevancia: a hirdetés szövege releváns legyen a landing page-re és lehetőleg tartalmazzon kulcsszót is
- egyéb faktorok: a fenti szempontokat a rendszer különböző súlyozással veszi figyelembe, illetve használ néhány nem publikus szempontot is a quality score meghatározásához

Egy kampány felállítása gyorsan zajlik, mindössze néhány óra ráfordítás is elegendő ahhoz, hogy elindulhasson. A hirdetések a kampány elindítását követően szinte azonnal megjelennek, így gyors eredményt lehet vele elérni. Előnye, hogy pontosan célozható, a hirdetéseket csak a számunkra releváns látogatóknak jeleníthetjük meg, ezzel is növelve a konverziós arányt. A költségek a napi és a havi költségkerettel könnyen kézben tarthatóak, nincsenek váratlan meglepetések.

Hátránya, hogy csak addig jelennek meg a hirdetések, amíg fut a kampány, ha lemerül az egyenleg, azonnal eltűnnek a rendszerből a hirdetések. Az eredmények itt is pontosan mérhetőek különféle analitikai rendszerekkel (pl. Google Analytics).

### SEO vs. PPC

Az alábbi táblázatban azonos szempontok alapján vizsgáltuk meg a két eszközt:

![SEO vs. PPC előnyei és hátrányai táblázat formátumban](https://blog.fps.hu/content/images/2015/12/seovsppc_abra.png)

A táblázat alapján jól látszik, hogy sok ponton különbözik a két eszköz, viszont pont ezek miatt a különbözőségek miatt tudják egymást nagyon jól kiegészíteni.

### SEO és PPC

Ha a lehető legjobb eredményt szeretnénk elérni az online marketinggel, akkor praktikus mindkét eszközt bevetni a siker érdekében. Ki kell dolgozni egy stratégiát arra vonatkozóan, mely pontokon tudják egymást a leginkább erősíteni egy adott projekt keretében. Pl. vannak olyan kulcsszavak, amelyekre organikusan valamilyen oknál fogva nem tudunk bekerülni az első oldali találati listára. Ezeket a kulcsszavakat használhatjuk a PPC kampányban, így máris ott lehetünk az első találati oldal élén.

Újonnan induló weboldal esetén nagyon jól lehet PPC-vel támogatni a SEO-t. Egyrészt a hirdetések segítségével máris forgalmat tudunk terelni az oldalra, másrészt segíti beindexelni a keresőknek az oldalt.

Ha még több konverziót, és ezáltal még több bevételt szeretnénk elérni az oldallal, akkor is célszerű párhuzamosan dolgozni mindkét vonalon. Ha jók vagyunk SEO-ban, akkor is hirdessük a legjobb terméket/szolgáltatást PPC-ben a maximális bevétel eléréséhez, így még inkább megtérülnek a befektetések.

Néhány esetben a PPC költséghatékonyabb eszköz, mint a keresőoptimalizálás. Például egy egyoldalas microsite esetében hosszabb távon kifizetődőbb PPC kampánnyal dolgozni, mint keresőoptimalizálni.

### Összefoglalva

A SEO és a PPC olyan online marketing eszközök, melyek külön-külön, de együtt is nagyon hatékonyak forgalomterelésre és konverziónövelésre egyaránt. Célszerű marketing stratégiát készíteni és meghatározni a célokat, amit a kampánnyal el szeretnénk érni, valamint kijelölni az az idősíkot, ami a megvalósításhoz rendelkezésre áll. Ha ezek megvannak, akkor tudjuk eldönteni, hogy a cél és az idő tükrében mely eszközt/eszközöket szükséges használni a kitűzött eredmények
### Bárány- és viharfelhők
URL: https://blog.fps.hu/cloud-felho-szolgaltatsok/
Last updated: 2026-07-17T08:50:31.000Z
Mindenhol hallani, hogy a felhő alapú számítástechnika korszakát éljük. A kérdés viszont az, hogy ez érint-e minket, szükségünk van-e erre, egyáltalán mi fán terem ez az egész, ha nem az időjárásról szól. Ha nem is tudunk róla, de mindennapi életünket is áthatják a felhők. Elég csak bejelentkezni bármelyik online Google szolgáltatásba (pl.: Gmail) és máris egy remek példát látunk a felhő alapú alkalmazásokra.

### Mitől lesz valami „felhő” alapú?

Gyakorlatilag csak arról van szó, hogy nem egy, hanem sok eszközön fut. Itt a sok alatt lehet akár érteni néhány, de akár több ezer eszközt is. Ezért itt a háttér-rendszer a kulcs, annak működése, felépítése. Sokszor erre a háttér-rendszerre, ami sok eszközből áll rugalmasan gondolnak mind darab szám, mind egymás közötti távolság szintjén. Folyamatosan bővíthető, csökkenthető az elemek száma és lehet, hogy az eszközök egy része más szerver központban található, ezért a „felhő” mérete és helye nem fix, sok-sok összetett elemből állhat, ezért is lehet diagramokon felhő szimbólummal ábrázolni, nem kell pontosan definiálni az eszközök számát és helyét, inkább azt kell definiálni, milyen szolgáltatást, hol, milyen időbeli tűréshatáron belül kell nyújtson. Utána erőforrás felhasználás függvényében lehet már változtatni, mikor mennyi eszköz szükséges. (Általában növekszik.) Leegyszerűsítve a felhőt: sok számítógép egy vagy több helyen összedolgozik valamiféle közös szolgáltatást nyújtva.

### Mire lehet felhasználni egy ilyen felhőt?

Négy felhasználási területet szoktak definiálni, ebből én háromra térnék ki.

Az egyik eset, amikor a felhőnk specifikus alkalmazásokat futtat. Ezek általában webes alkalmazások (vagy komplex weboldalak). Ilyenek a már említett Google-féle szolgáltatások, például Google Docs. Ezért mondják erre az esetre, hogy maga a szoftver a szolgáltatás, amit a felhő biztosít. Ezeket az alkalmazásokat úgy tervezik, hogy képesek legyenek párhuzamosan futni, részfeladataikat párhuzamosan kezelni.

Az előző eset szüli az igényt a második esetre. Azzal az volt a baj, hogy túl specifikus. Azt a szoftvert futtatja, amire tervezték. Ennél nagyobb rugalmasságot szeretnénk, akkor inkább szolgáltassunk a felhőnkkel egy olyan platformot, amely képes az erre megírt alkalmazásokat futtatni. Ekkor egy általános szoftver végrehajtó szolgáltatásról beszélünk, amely az olyan alkalmazásokat, amelyeket kifejezetten erre írtak, képes a felhőben futtatni, automatikus skálázni, több gépen párhuzamosan megosztani a feladataikat, kihasználva ezzel a felhőben meglevő előnyöket. Erre példa többek között a Windows Azure.

A harmadik eset, amikor a felhőnkkel csak infrastruktúrát szolgáltatunk. Azaz még tovább általánosítjuk a felhasználását. Nem adunk közös platformot, csak virtuális környezeteket vagy erőforrásokat, amelyeket tetszőlegesen fel lehet használni. (Gondoljunk itt akár tárhely szolgáltatásokra, virtuális szerver szolgáltatásokra, stb.) Például weboldal üzemeltetőként ezzel találkozunk leginkább. Amikor előjön a virtuális szerver, mint lehetséges környezet, sokszor van mögötte felhő. Ez a legtipikusabb felhasználása is. Adjunk kisebb erőforrásokkal rendelkező szervereket a nagy felhő rendszerünkben. Ezzel elérjük, hogy olcsón tudjunk egész jó kapacitást adni (kapni) és ötvözzük a felhő előnyeit a hagyományos szerver alapú rendszerekkel.

### Mik is konkrétan ezek az előnyök a szolgáltatást bérlők szemszögéből bármilyen felhőnél?

![Nap és felhő illusztráció](https://blog.fps.hu/content/images/2015/12/felho_nap.png)

- könnyű skálázhatóság: ha szükség van nagyobb erőforrásra, könnyen kiosztható, akár pillanatok alatt is.
- hardver hiba tolerancia: ha elromlik egy-egy eszköz, akkor nem okoz igazi problémát egy jól tervezett felhőben, mert percek alatt át tudja venni egy másik eszköz ugyanazon feladatokat.
- költségkímélő: annyi erőforrásért kell fizetni, amennyit használunk, nem kell hardverrel bajlódni
- nagyon nagy számítási és háttértár kapacitások érhetőek el a megfelelő környezettel

### Kik férhetnek hozzá a felhő szolgáltatásaihoz?

Publikus felhőknél bárki az interneten, aki feliratkozik, előfizet, elfogadja, stb. a szolgáltatást (na meg megtalálja). A privát felhőkkel más a helyzet. Ekkor eleve le van szűkítve a lehetséges felhasználók köre. Lehetnek azok például egy cég alkalmazottai is. Az is lehet, hogy eleve csak intraneten érhető el. Ezeket a felhőket akár az adott cég/szervezet is üzemeltetheti, de lehet az egy külsős szolgáltató, aki garantálja, hogy ez a felhő csak az adott körnek lesz elérhető (esetleg a felhőben izolál egy részt számukra). Nagyvállalatoknál kézenfekvő megoldás kiköltöztetni felhőre a vállalati szolgáltatásokat (ennek maximum a rugalmasság, felmerülő önkorlátozó szabályok és adatvédelmi kérdések szabnak gátat), mert hosszabb távon olcsóbb lesz az informatikai rendszer fenntartása. Hamarosan eljutunk odáig, hogy középvállalatoknak is megéri, amilyen ütemben fejlesztik az erre specializálódott cégek a felhő rendszereiket.

### Ellenérvek?

![Viharfelhő illusztráció](https://blog.fps.hu/content/images/2015/12/viharfelho.png)

Akadnak szép számmal. Kezdjük rögtön az adatbiztonsággal. Joggal merül fel a kérdés, hogy az adataink nem kerülnek-e illetéktelen kezében például egy felhő alapú virtuális szerver szolgáltatást nyújtó cégnél. Hiszen hogy működik általában ez? Először is a virtuális szerverek fájlrendszere általában egy nagy közös tároló helyen van, amelyet az összes futtató szerver elér. (Sokszor SAN vagy hasonló megoldás.) Így bármelyik fizikai hardveren el tud futni bármelyik virtuális gép.

Felmerülnek az aggályok, hogy a háttértár elég megbízható-e és hozzá a hozzáférés se kompromittálódhat-e. Ha valamelyik szolgáltatásbérlő rosszindulatú, eléggé védve vannak-e a virtuális szerveren tárolt adataink.

Ez csak pár kérdés, de nem hiába nehéz találni olyan szolgáltatót (de nem lehetetlen!) ami megfelel a legszigorúbb elvárásoknak is, mint a PCI DSS. (Ezt a bankkártya társaságok támasztják azon rendszerekkel szemben, amelyek szeretnének bankkártya adatokat tárolni. Egy felhőben sokkal nehezebb leszűkíteni a scope-ot, amely érintett a bankkártyás adatok tárolásában, így nagyon sok eszköz, szoftver érintett lesz, ezáltal megnehezítve a megfelelést a szigorú elvárásoknak.)

Adatintegritás problémája is előjön. Szintén vegyük az előző szolgáltatásokat, amikor virtuális szervereket adnak szolgáltatásként a felhőben. A kezdeti időszakokban rengeteg probléma volt, mint adatvesztés (nem elkészülő ígért biztonsági másolatok, elveszett virtuális szerver image fájlok, stb.) valamint rendelkezésre állás sokszor siralmas statisztikája. Idővel azért javult a helyzet, lassan kiforrja magát a technika, kialakulnak a bevált módszerek, de aki már megjárta ezzel, nem jó szívvel vág bele újra.

Aztán itt vannak a költség miatti aggályok, hiába az elméleti olcsóság a fentiek alapján. Sok neves felhő szolgáltató irreálisan drága. Nagyok sokaknak megfizethetetlen és annyira nem is jók, mint amennyire gondolnánk és az ára sejtetné. Ez szerencsére változni fog, ahogy egyre többen lépnek be erre a piacra.

Sok minden más pro-kontrát lehetne sorolni, de nem célom az írásomban részletekbe bonyolódni. Akármilyen érveket is sorolunk ellene – mellette, kétségtelenül ez a jelen és jövő az informatikában. Hamarosan mindenkinek számolnia kell a felhőkkel. A kezdeti nehézségek lassan eltűnnek, egyre több helyen érhető el, Magyarországon is a nagy telekommunikációs cégek sorra indítják el a felhő alapú rendszereiket, szolgáltatásaikat. Minden aggályaink ellenére véleményem szerint elkerülhetetlen lesz, hogy saját életünk után – lásd Facebook – üzletünk is előbb-utóbb része lesz a felhőknek.
### Email marketing – mit, miért, hogyan?
URL: https://blog.fps.hu/email-marketing-edm/
Last updated: 2026-07-17T08:50:42.000Z
A kampányod jól megtervezett, az email adatbázisod megtisztított, a tartalmad jól szerkesztett, a hírlevél sablonod lélegzetelállító. Kiküldés után mégsem jön a konverzió. Ismerős a történet?

Számos oka lehet annak, hogy nem működik az email kampányod. Összegyűjtöttük a leggyakoribb okokat, melyek az email kampányok sikertelenségéhez vezetnek.

### Hova tűnnek a leveleim?

Az egyik leggyakoribb probléma, hogy a címzettekhez nem jut el a hírleveled. Mi lehet ilyenkor a probléma?

- spambe érkeznek a hírlevelek: ellenőrizd, hogy nem-e magas a levél spam score-ja. Vannak olyan hírlevél küldő szoftverek, melyekkel még kiküldés előtt le tudod ellenőrizni (pl. [oempro](http://octeth.com/oempro?ref=blog.fps.hu)), de vannak ingyenesen elérhető online eszközök is erre (pl. [spamscorechecker.com](http://spamscorechecker.com/?ref=blog.fps.hu)), amellyel ellenőrizheted. Ha túl magas, akkor mindenképp csökkenteni kell (általában ezek a programok megmutatják, mely területen van a hiba, pl. tartalomban, a hírlevél kódjában, stb.). A legjobb, ha a spam score 3 alatt van, ugyanis a legtöbb levelező szerveren 3-ra vagy 5-re állítják be a szűrőt.
- meg sem érkeznek a hírlevelek: előfordulhat, hogy a kiküldő domain vagy IP kerül feketelistára, és ezért nem kézbesülnek a levelek. Ehhez is vannak olyan elérhető ingyenes eszközök, melyekkel ellenőrizhető a domain vagy az IP. (A rendszergazdád vagy a szolgáltatód is tud ebben segíteni)
- soft bounce-ba kerülnek az email címek: ha például megtelik a címzett postafiókja, vagy autoreply van beállítva, a levelező soft bounce-nak tekintheti az email címet. Ezekkel a címekkel újra próbálkozik a későbbiekben, amíg nem sikerül kézbesíteni a levelet vagy át nem kerül hard bounce-ba az email cím.

Ezen a problémán alapvetően már az is segít, ha egy jól működő, profi hírlevélküldő rendszert használsz (pl. [mailchimp](http://mailchimp.com/?ref=blog.fps.hu)) Nem mindegyik kerül ám sokba, pl. a mailchimp esetében, ha 2000 cím alatt van az adatbázisod, és 12 000 emailnél nem küldesz többet egy hónapban, akkor ingyenesen használhatod.

### Nem nyitják meg a hírleveleim

Sikeresen célba érkeznek a leveleid, mégis nagyon alacsony a megnyitási arány? Ennek is több oka lehet, a leggyakoribbak:

- rossz a kiküldési időzítés: például a célcsoportod a cégvezetők, akiknek a hírleveled segítségével szeretnéd eladni a szolgáltatásod. A hírlevelet hétfő délelőtt 10-kor küldöd ki. A cégvezetők szempontjából ez a hét legzsúfoltabb időszaka, amikor hét eleji meetingeket és hétindító megbeszéléseket tartanak. Ráadásul a hétvégén érkezett levelek is ott sorakoznak még a postafiókjukban, így a Te leveled egy lesz csak a sok közül, amit rosszabb esetben olvasatlanul fognak törölni. Próbálj ki több napot és időpontot, így kiderítheted, mikor működik legjobban a hírleveled. (Egy [friss tanulmány szerint](http://www.marketingcharts.com/wp/direct/most-emails-deployed-in-the-morning-but-best-results-seen-in-the-evening-27742/?ref=blog.fps.hu) a megnyitási arány az esti órákban a legmagasabb, érdemes megnézned ezt a [nagyszerű infografikát](http://blog.kissmetrics.com/science-of-social-timing-2/?wide=1&ref=blog.fps.hu) is.)
- nem elég figyelemfelkeltő a levél tárgya: az olvasók a hírlevél ezen részével találkoznak legelőször. Ha nem ragadja meg a tekintetet, vagy nem elég figyelemfelkeltő, jóval kisebb az esélye, hogy megnyissa a hírlevelet. Próbálj figyelemfelkeltő, cselekvésre ösztönző tárgyat adni a levelednek, így nagyobb az esély, hogy meg is nyitják.
- nem mobilra optimalizált a hírlevél: az emailek közel egyharmadát ma már mobilon olvassák a felhasználók (itt elsősorban most okostelefont értek mobil alatt), így nagyon is fontos, hogyan jelenik meg a hírlevél az eszközön. Ha például a hírleveled mindössze egyetlen beágyazott fotó, akkor máris vert helyzetben vagy, ugyanis mobilon nem jelennek meg automatikusan a képek. Figyelj arra, hogy mobilon is jól olvasható és kattintható legyen a hírlevél.

[![Megnyitási arányok 24 órában grafikon, a csúcs kora reggel van](https://blog.fps.hu/content/images/2015/12/early-morning.png)](http://blog.kissmetrics.com/science-of-social-timing-2/?wide=1&ref=blog.fps.hu "Infografika")

### Nincs konverzió

Az első két akadályt sikerrel vetted, megérkeztek a megfelelő címzettekhez a hírleveleid, meg is nyitották, még sincs konverziód. Lássuk a leggyakoribb okokat:

- rosszul jelenik meg a hírlevél a levelező programban: a hírlevél sablon elkészítésekor célszerű többféle levelező programmal letesztelni a hírlevelet, ugyanis kliensenként is különbözőképpen jelenítheti meg (mivel nem biztos, hogy minden formázást le tud kezelni az adott levelező kliens). Erre a problémára egy másik jó megoldás, ha készül egy html verzió is, ami egy linkre kattintva elérhető a felhasználók számára.
- túl sok az információ: például egy webshopot üzemeltetsz, és a hírlevélben termékeket akarsz eladni. A hírleveled viszont nemcsak termékeket tartalmaz, hanem híreket, praktikus tanácsokat, stb. Az érdekes tartalom miatt ugyan átkattintanak az oldaladra, de nem fognak vásárolni. Ilyen esetben célszerű többféle típusú hírlevelet készíteni, amiben el tudod különíteni a tartalmakat.
- nem a konkrét termékre/szolgáltatásra linkelsz: az előző webshopos példánál maradva a hírlevélbe elhelyezett termékek esetében nem a termék adatlapra, hanem egy kategória oldalra jutnak a látogatók. Megint csak elvesztik a fókuszt, elkezdenek bolyongani az oldalon, és ismét nincs konverzió. Mindig konkrét termékre/szolgáltatásra linkelj, ha el is szeretnéd adni ezeket. Persze a legjobb, ha külön erre a célra létrehozott landing page-re linkelsz.
- nem szegmentálod az adatbázisodat: ha mindig ugyanannak a vevőkörnek akarod eladni ugyanazt a terméket/szolgáltatást, akik korábban vásároltak, nem biztos, hogy a következő alkalommal is fognak. Őket célszerű külön listára tenni és más ajánlatokkal megkeresni. A konverziót hozó látogatóknál érdemes logolni a tevékenységet, és ehhez kapcsolódóan küldeni neki a következő ajánlatot, pl. árkategória alapján küldeni neki hasonló árkategóriájú ajánlatot, megvásárolt termékhez kapcsolódó másik termékkel/szolgáltatás nyújtó ajánlatot, stb..

![Amennyiben nem jelenik meg a hírlevelünk, kattint ide! felirat](https://blog.fps.hu/content/images/2015/12/hirlevel.png)

### Mérj!

Ugye, mennyi buktatója lehet egy email kampánynak? És ezek csak a leggyakoribb problémák, számtalan oka lehet annak, hogy nem sikeres egy hírlevél kampány. Fontos, hogy valamilyen analitikai eszközzel mérd a hatékonyságot. A profi hírlevélküldő rendszerek általában szolgáltatnak különféle statisztikai adatokat a hírlevélre vonatkozóan, pl. megnyitások száma, megnyitási arány, soft bounce, hard bounce, leiratkozók, stb.. Ezek mellé célszerű még külső analitikai rendszert is használni (pl. [Google Analytics](http://www.google.com/analytics/?ref=blog.fps.hu)), amivel tudod mérni a kampány hatékonyságát. Egy-egy hírlevél kiküldése után pár nappal elemezd az adatokat, vizsgáld meg, elérte-e a kampány azt a célt, amit te szerettél volna (pl. mennyien olvasták, hány konverzió érkezett, stb.). Ha folyamatosan mérsz, az egyes kampányokat is össze tudod hasonlítani, így könnyebb dolgod lesz a továbbiakban.

### Összefoglalva

Ha sikeres email kampányt szeretnél lebonyolítani, az alábbi szempontokat mindenképp vedd figyelembe:

- használj professzionális hírlevélküldő rendszert
- tartsd karban a levelező listáid
- a hírlevél készítésekor gondolj a mobil felhasználókra is
- a tartalmak kialakításánál fókuszálj a célra, és csak annak megfelelő tartalmakat használj
- adj figyelemfelkeltő tárgyat
- időzítsd a megfelelő időpontra
- mérd a hatékonyságot

És még egy kis segítség: van egy jó kis weboldal, amely nagyon sok segítséget ad a hírlevél html elkészítéséhez, csak ajánlani tudom: [emailology.org](http://www.emailology.org/?ref=blog.fps.hu)
### NFRs WTF?
URL: https://blog.fps.hu/nfrs-furps-nem-funkcionalis-kovetelmenyek/
Last updated: 2026-07-17T08:50:50.000Z
Figyelem egy ideje a fejlesztőket, élvezem a munkát, órákig el tudom nézni, ahogy mások dolgoznak. Viccet félretéve. Próbálok olyan pontokat találni, amivel segítségükre lehetek a fejlesztésben. Minden erőfeszítéssel küzd egy csapat a Technical Debt kiküszöbölésére, mégis jelenség, hogy sok új feladat születik a fejlesztés vélt befejezését követően, amelyek nagy része az ügyfél jelentései alapján inkább a BUG kategóriába sorolódnak, pedig a funkciók a helyükön vannak.

Például: az időzített tárolt eljárások kiválóan működnek a teszt környezetben teszt adatokkal, mégis élesben elszállnak, mert nagyságrendekkel több adatra már más időzítést kell használni vagy akár más eljárást. Említhetném akár a konkurens USER kezelést is.

Az NFRs (Nonfunctional Requirements) megfelelő figyelembevétele és használata azonban megoldást adhat az ilyen jellegű problémák kiküszöbölésére.

### Nonfunctional Requirements

Bizonyára sokan találkoztatok már a FURPS mozaikszóval, aminek elméletét – így rendszerezve – a HP dolgozta ki és használta először.

A FURPS (Functionality Usability Reliability Performance Supportability) első F betűje takarja a funkcionalitást, ami rendszerint a storyk-ban meg is jelenik, azonban a Nagyon Fontos URPS nem mindig jelenik meg megfelelő hangsúllyal, előidézve ezzel a fenti jelenséget, miszerint – „azt hisszük, kész, aztán mégsem”.

Ha csak a szavakból indulunk ki, az éles eszű olvasó azonnal felkiált „HÉ! mi az hogyasziszed? MI VAN A DOD-ban? Olvasd el és egyből kiderül, hogy kész van-e!”. Igen, igaza van kedves olvasó, és ha a DOD-ban (definition of DONE – a kész definíciója) csak annyi van, hogy „NRFs – OK?”, akkor itt az ideje kibontani újból ezeket a nem funkcionális követelményeket. Újra, hiszen ezeket már tanultuk az egyetemen… már aki…

#### Functionality – funkcionális

Funkciók, mire képes, mennyire általános, mennyire biztonságos.

#### Usability – használhatóság

Emberi tényezők, esztétika, következetesség, dokumentáció.

#### Reliability – megbízhatóság

Hibák súlyossága és gyakorisága, mennyire hasznosítható, mennyire kiszámítható, mennyire pontos.

#### Performance – teljesítmény

Gyorsaság, a hatékonyság, az erőforrás-felhasználás, teherbírás, válaszidő.

#### Supportability – támogathatóság

Tesztelhetőség, bővíthetőség, alkalmazkodóképesség, fenntarthatóság, kompatibilitás, konfigurálhatóság, szervizelhetőség, instabilitás, lokalizálhatósága, hordozhatóság.

Szóval az URPS foglalja magában a nem funkcionális követelményeket. Ha nem elég részletes a DOD-unk, vagy nagyon speciális projektről van szó, akkor javasolt az NFRs külön megjelenítése a SCRUM táblán. Nem kizárt, hogy KRITIKUS nem funkcionális követelmények, mint Story-k megjelenjenek a Backlogban, de ez a PO (Product Owner) felvetése alapján a csapat döntése.

![Egy pizzáról készült közeli kép](https://blog.fps.hu/content/images/2015/12/pizza.png)

### Konkluzió

Ha nem szentelünk megfelelő és folyamatos figyelmet a nem funkcionális követelményeknek, akkor könnyen generálhatunk extra munkát magunknak – amit rendszerint az ügyfél már nem fizet meg – ezért célszerű ezeket a Product Planning és a Sprint Planningek alkalmával alaposan megvizsgálni és a Story-kat ezek ismeretében becsülni.

Nem felejtődhet el ezek vizsgálata, ha betartjuk az egyszerű „meghatároz/tervez – elkészít – tesztel” hármas szabályt. Tervezéskor figyelembe vesszük, teszteléskor megbizonyosodunk róla. Én meg menjek a picsába :)
### Szükséged van website-ra?
URL: https://blog.fps.hu/web-site-tervezes-celkozonseg-kerdesek/
Last updated: 2026-07-17T08:51:01.000Z
Sokan gondolják azt, hogy „nekem szükségem van egy web site-ra” és belevágnak eszetlenül. Akkor még nem tudják, hogy mekkora problémákba ütköznek majd és hogy a befektetett pénz talán sosem fog megtérülni.

**Ha nincs terved, nem ismered a célközönséged, akkor ne kezdj web site fejlesztésbe!**

Az alábbi képen összegyűjtöttünk jónéhány kérdést, amelyek nagy részét megválaszolva érdemes belevágnod egy új projektbe.

![Kérdéslista](https://blog.fps.hu/content/images/2015/12/szukseged-van-web-site-ra-kerdesek-fps.png)

[Töltsd le a posztert (0 letöltés)](https://www.fps.hu/presentations/szukseged-van-web-site-ra-kerdesek-fps.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### Kritikus hiba történt
URL: https://blog.fps.hu/hibauzenetek-hibakezeles/
Last updated: 2026-07-17T08:51:11.000Z
Mindannyian rendszeresen töltünk ki űrlapokat és sokszor megtörténik, hogy elfelejtjük, elgépeljük a jelszavunkat, kihagyunk egy mezőt, nem megfelelő formátumot adunk meg, vagy nem jelöljük meg, hogy elfogadjuk az adatvédelmi szabályzatot. Azaz megtörténik a hiba.

Most érkezett el a pillanat, amikor eldöntöttem, hogy összefoglalom egy posztban a hibaüzenetekkel kapcsolatos tudnivalókat. Gyakorlatilag minden usability átvizsgálásról készült dokumentumom legalább 30%-a a hibaüzenetek nem megfelelő kezeléséről szól.

Személy szerint nem ismerek és valószínűleg nem is létezik olyan ember, aki szeret kitölteni űrlapokat. Éppen ezért nagyon fontos, hogy ezeknek a formoknak a kitöltése a lehető legkevesebb „fájdalommal” járjon. A legzseniálisabban megtervezett űrlapnál is előfordul, hogy a felhasználó valamilyen hibát vét, amiről szeretne visszajelzést kapni, hogy gyorsan javíthassa és túl legyen a feladatán. Arról már nem is beszélve, hogy a rendszerrel is történhet bármi, ami feltartóztathatja a userünket.

Tisztában vagyok azzal, hogy egy jól használható űrlap lefejlesztése sok munkát követel meg (többet, mint ha csak odadobnánk egy alertet), de a felhasználóink elégedettsége nagyban függ ettől, ezért érdemes odafigyelni.

### Legyen!

Sajnálom, hogy ezt egyáltalán le kell írnom, de nem egyszer futottam olyan példákba, amikor egész egyszerűen semmilyen visszajelzést nem kaptam. Megnyomtam az „elküld” gombot, az oldal újratöltődött és visszakaptam ugyanazt az oldalt. WTF?

### Megkülönböztetés

A hibaüzenet grafikai stílusát meg kell különböztetni az űrlap elemeinek stílusától. A cél az, hogy a felhasználó azonnal érzékelje, hogy hiba történt. Ezt elérheted más színnel (mondjuk piros), más betűmérettel, figyelemfelkeltő ikonnal stb.

![piros színnel van kiírva a pontos hibaüzenet, ami a hibás mezőre mutat](https://blog.fps.hu/content/images/2015/12/fizetesmod.png)

### Pozicionálás

Az sem mindegy, hol helyezzük el a hibaüzenetet. Nem jó a rendkívül gyakori megoldás, miszerint az űrlap felett felsoroljuk, hogy melyik mezővel mi volt a probléma. Sietek, nem akarok gondolkozni, ne várja el senki, hogy összepárosítsam, melyik üzenet pontosan mire vonatkozik, pláne ha egy hosszú űrlapról van szó. Görgetni fogok fel-le? NEM.

Az a legjobb, ha közvetlenül minden mezőhöz kiteszed az azzal kapcsolatos hibát. Ne intézd el annyival, hogy minden mező kitöltése kötelező. Melyiket nem töltöttem ki?

![a hibás mezőre mutató hibaüzenet](https://blog.fps.hu/content/images/2015/12/telefon.png)

Ha hosszú az űrlap, akkor scrollozd az első hibához az oldalt, ne dobj a tetejére, hogy nekem kelljen megkeresni azt az átkozott hibát.

### Nyelvezet

Az üzenet legyen rövid, lényegre törő és pontosan mondja el, mit kell tennem, hogy javítani tudjak.  
Ne használj olyan szavakat, kifejezéseket, melyeket biztos nem fogok megérteni. Ne legyen olyan az üzenet, mintha egy robot üzenne egy robotnak, egyszerűen úgy kell gondolkoznod, mintha egy párbeszédet folytatnál a felhasználóval. (csendben jegyzem meg, hogy a helyesírásra is érdemes odafigyelni)

### Hangvétel

Az üzenetek legyenek barátságosak. Emberek vagyunk, így sokat hibázunk, egyáltalán nem hiányzik, hogy egy computer arrogánsan emlékeztessen erre a tényre. Ne írd úgy, hogy: „*Nem töltötted ki az email címed!”*, inkább legyen ez: „*Kérlek, add meg az email címed.”*

A hibaüzenetek stílusa is egyforma kell legyen mindenhol. Tudom, sok esetben több fejlesztő dolgozik egy adott projekten és általában mindenki más beszédstílust használ. Rendkívül gyakori, hogy egyszer tegez a rendszer, máskor pedig magáz. Ennek elkerüléséhez nagyszerű eszköz a design persona alkalmazása, mely gyakorlatilag egy személyiséget kölcsönöz az alkalmazásnak. Ebben a dokumentumban példákkal együtt szerepel az alkalmazandó hangvétel is. Mindenki, aki a projektben részt vesz elolvassa, kirakja magának és alkalmazza az abban foglaltakat. (a design personáról később írni fogok)

![Köszöntésre, sikeres és hiba üzenetekre példák](https://blog.fps.hu/content/images/2015/12/peldak.png)

### Következetesség

Az egyik leggyakoribb probléma. Ha egy oldalon több űrlap van, akkor mindegyik űrlap és azok hibaüzenetei ugyanúgy jelenjenek meg. Frusztrációt okozol a felhasználónak, ha az űrlapok különbözőképpen működnek. Ne akard és pláne ne kényszeríts arra, hogy több különböző folyamatot tanuljak meg az oldaladon.

### Valósidejű ellenőrzés, hibaüzenet

Ahol csak lehet érdemes alkalmazni a valós idejű ellenőrzést, sokat gyorsít egy űrlap kitöltésén. Arra gondolok, hogy miközben gépelek egy mezőbe a háttérben (AJAX, vagy sima JS), már megy is az ellenőrzés, és ha például a beírt email címmel már regisztráltam, akkor erre azonnal figyelmeztet a rendszer.

![Kérem, számot írjon a fogyasztáshoz szöveg jelenik meg, mikor nem számot ír be a felhasználó a mezőbe](https://blog.fps.hu/content/images/2015/12/ujfogyasztas.png)

### Rendszer probléma

Ha bármilyen rendszerszintű hiba (pl. 404-es oldal) történik, amiről a felhasználó nem tehet, az a minimum, hogy elnézést kérsz és biztosítasz arról, hogy már dolgoztok a problémán.

### Összefoglalva

**A hibaüzenetek**

- grafikai stílusa az űrlap elemeitől eltérő, figyelemfelkeltő
- barátságosak, rövidek, lényegre törőek, pontosan elmondják, mit kell tenni a javításhoz
- a megfelelő mezőhöz kötötten jelennek meg
- konzisztensek, mindenhol ugyanúgy, ugyanazzal a stílussal jelennek meg

Sok munka jó űrlapokat készíteni, de biztosan megtérül a befektetett energia. Kevesebb felhasználó fog „lemorzsolódni” és boldogabbá teheted őket, ezáltal szívesen vissza is térnek majd. Egy ideális világban nincsenek hibaüzenetek, de ez egyelőre a Föld nevű bolygó, tökéletlen eszközökkel és emberekkel, ami jól is van így.
### Scrum – tolongás?
URL: https://blog.fps.hu/scrum-alapertekek/
Last updated: 2026-07-17T08:51:22.000Z
Sok irányból lehet közelíteni a SCRUM megértését. Mindegyik irány helyénvaló, hiszen egyáltalán nem mindegy, hogy az ügyfélnek, a menedzsereknek vagy épp a fejlesztőknek próbáljuk bevezetni a gondolkodás módjukba az agilitást!

Az öt agilis érték – elkötelezettség, fókusz, nyitottság, tisztelet, bátorság – mentén megpróbálom megmutatni a különbséget.

#### 

Fejlesztőknek

![Fjlesztőknek felirat](https://blog.fps.hu/content/images/2015/12/fejlesztoknek.png)

Alapvető szemléletváltásra van szükség. Sajnos kénytelenek lesznek az ügyfél fejével gondolkozni, még ha az ügyfélről tudjuk „azt sem tudja mit akar”. Meg kell tudni hallani és érteni azt, amit az ügyfél szeretne, AZT és nem többet, nem mást! Megszűnik a jó világ, miszerint a TASKban leírtakat szó szerint megcsinálom, akkor baj nem lehet…

Majd elfelejtettem. A tábla előtt egyenlő lesz junior, senior, nagyszájú és csendes, hisz a feladatokért lehet tolongani, de a prioritás határozza meg, hogy ki mit csinál, nem a szokásjog. Azaz a feladatok közül nem lehet válogatni, a prioritás szerint kell hozzálátni, a sorrend nem sérthető meg!

#### Tisztelet

Egymás és az ügyfél felé, hisz lássuk be, a fizetésünk mégis csak tőle jön, tehát az ügyfél nem UFÓ, nem hülyeségeket akar – épp csak nem programozó.

#### Nyitottság

Arra, hogy megértsük az ügyfelet, a szándékát. Nyitottság az új megoldásokra, az extrém kérésekre. Ja és a gyakornoknak is VANNAK jó ötletei!

#### Bátorság

Elmondani, ha valamit NEM lehet megcsinálni, vagy MI NEM TUDJUK megcsinálni! NE mondjunk kettőt, ha valójában négyet gondolunk. NE ENGEDJÜNK a PM és az ÜGYFÉL nyomásának, úgyis rajtunk csattan, és ráadásul tényleg 4 vagy 5 lesz! HIDD EL!

#### Elkötelezettség

Ha azt mondjuk 4, akkor legyen 4, vagy inkább 3!

#### Fókusz

Nincs más dolgunk csak amire kötelezettséget vállaltunk! Minden egyéb MÁS kötelezettsége! 

Próbáljunk meg csak a sajátjainkkal foglalkozni, azokat fogják rajtunk számon kérni! 

### Ügyfeleknek

![Ügyfeleknek felirat](http://)

Hiszünk az ügyében, hiszünk a technológiában, hiszünk magunkban! Tudjuk, hogy az ő csengő Forintjaiból van a miénk is!

Mi kell ehhez? „Működő szoftver, mintsem kiterjedt dokumentáció”, de hogyan? Szoros, rendszeres együttműködés(!) és reakció a változásokra! – ismerősek?

#### Elkötelezettség

Ha ő nem hisz a projektjében, nekünk nehéz lesz hinni benne! Elkötelezettség Irántunk, azaz a fejlesztő iránt! Nem azt mondom, hogy ami ragad, tapad, de nem baj, ha a fejlesztő érzi a bizalmat, ami a számlák rendszeres teljesítésében is megnyilvánul ;)

#### Fókusz

Csak annyi, amennyit kér a fejlesztő, azaz ha infó kell, tesztelni kell, review van, akkor kérjük, hogy csak „velünk” foglalkozzon! Egyrészt gyorsabban szabadul, másrészt nem szívatja magát feleslegesen elkészített funkciókkal – amit bizony ki kell fizetni, még ha közben kiderül, hogy feleslegessé is válik!

#### Nyitottság

Biztos, hogy a saját üzleti modelljét ő ismeri leginkább, de a kockáknak is lehetnek jó meglátásai.

A fejlesztő fejében ugyanis már benne van a „maximize work not done” szemlélet.

#### Tisztelet

A vállalkozó is profitorientált! A programozó is ember! Más megrendelő is ugráltatja a vállalkozót! A nap 24 órából áll, amiből 8 óra telik munkával… Este én is moziba megyek a „csajommal”.

#### Bátorság

Belevágni és hagyni, hogy ha fizetek érte, akkor a vállalkozó végezze a dolgát. Bátorság elhinni, hogy nem nekem kell, hogy tessen az oldal, hanem az ügyfeleimnek! Miért kérdezzem meg a pincért, hogy friss-e a libamáj? – azt remélem, tud valamit, amit én nem!

### Projekt managereknek

![Projekt managereknek felirat](https://blog.fps.hu/content/images/2015/12/projektmanegereknek.png)

Egyedül kevés vagy! Be kell látni, hogy A SCRUM nem véletlenül veszi ketté a teendőket: PO – product owner, vagy „gyártásvezető” és SM – scrum master. Szükség van mindkettőre! A PM és az account össze van gyúrva és újra szétválasztva! Csak épp néhány feladat cserélődik :)

Nem a legügyesebb programozó fogja a projekted sikerre vinni, hanem a legjobb csapat!

#### Elkötelezettség

A csapat iránt, a SCRUM iránt, mert a SCRUM mindenre ad megfelelő választ, viszont vannak pillanatok, amikor egyszerűbbnek tűnik a régi rutint alkalmazni, – Ne tedd!

#### Fókusz

A termékre, csapatra, határidőkre.

#### Nyitottság

Az új storykra.

#### Tisztelet

A módszert tisztelni annyira, hogy betartsuk a szabályait! A Csapat döntéseit tiszteletben tartani és elfogadni nem könnyű!

#### Bátorság

Felvállalni a konfliktust az ügyfél felé a csapat érdekében, bátorság az új storykat tényleg ÚJ STORY-nak értékelni, bátorság jelezni az ügyfél felé, ha valami nem úgy halad, mint ahogy terveztük!!!

### Magam egy ügyféltől tanultam:

> „nem baj, ha nincs karácsony, csak ne december 23-án tudjuk meg!”
### Ügynökségi Mantrák
URL: https://blog.fps.hu/agency-mantras/
Last updated: 2026-07-17T08:51:33.000Z
Neked vannak saját mantráid? Mormolgatod magadban nap mint nap? Képzeld nekünk is vannak sajátjaink. Ebből jött az ötlet, hogy összefoglaljuk egy ügynökség tipikus szereplőinek mantráit. Ha van jó ötleted még, esetleg megosztanád velünk a Te mantrádat, ne habozz és írd meg kommentben, biztos sokak hasznára válik.

### Tessék

![Agency Mantras by fps](https://blog.fps.hu/content/images/2016/01/agency-mantras-1.png)
### Kell vagy sem a mobil SEO?
URL: https://blog.fps.hu/mobil-seo-kell-vagy-nem/
Last updated: 2026-07-17T08:51:45.000Z
Az online világában másról sem hallani mostanság, mint mobil verzió, mobil applikációk, responsive web design, smartmobil penetráció, és még sorolhatnám. Sokunkban felmerülhet a kérdés: jó-jó, ez a jövő, de megérett már a magyar piac erre? Összegyűjtöttünk néhány kérdést, melyekre a válaszok segítenek eldönteni, hogy kell-e foglalkozni a mobilos felhasználókkal. Egy biztos, az általunk kezelt oldalak mindegyikénél minimum 6%-os a mobilos forgalom, de akad köztük 45%-os is.

### Miért fontos a mobil SEO?

A weboldalakat sokáig csak egyféle platformra, desktoptra készítettük. A keresőoptimalizálási feladatokat is ennek megfelelően építettük fel, a Google egyféle algoritmus alapján indexelte az oldalakat, csak erre kellett figyelni. Azonban a mobil eszközök rohamos terjedésével megjelentek új technológiák, másféle oldal készül a desktopos felhasználóknak, mint a mobilosoknak. A Google is lépett ez ügyben, már egy ideje külön algoritmus szerint rangsorolja a találatokat a desktopos és a mobilos felhasználóknak. (erről részletesebben [egy korábbi posztban](https://blog.fps.hu/desktop-vs-mobil-kereses/ "Desktop vs. Mobile keresés") már írtam)

A különböző algoritmus jelenléte ugyan az alapvető SEO beállításokat nem befolyásolja, de a tartalom optimalizálásnál már érdemes odafigyelni a megfelelő kulcsszavak használatára, mivel a keresési szokások is némileg különböznek.

### Mobil SEO audit checklist

Ahhoz, hogy pontos képet kapjunk arról, hogyan teljesít mobilon az oldalunk, bele kell mélyebben ásnunk magunkat az analitikába. (A listát a Google Analytics alapján állítottuk össze, de más webanalitikai rendszerekben is megtalálhatóak ezek az információk.) Határozzuk meg a mobil felhasználók viselkedését az organikus keresési eredményekből, nézzük meg az organikus forgalmat is, és válaszoljunk az alábbi kérdésekre:

#### 1\. Milyen volumenű a mobil eszközökről érkező forgalom a teljes forgalom tükrében?

Az Analyticsben a közönség menüpont áttekintés oldalán a speciális szegmensekben lehet leszűrni a mobil és a táblagépes forgalmat. Nézzük meg, a teljes forgalom hány százaléka érkezett mobil eszközökről. (külön-külön is érdemes megtekinteni a mobilos és a tabletes adatokat is a teljes organikus forgalom tükrében).

Vizsgáljunk meg egy nagyobb időintervallumot (pl. elmúlt hat hónap) és nézzük meg, hogyan növekedett a mobil eszközös forgalom, illetve itt is érdemes külön is megnézni a mobilok és a tabletek arányát.

![Google Analytics közönség szegmentálás képernyőkép](https://blog.fps.hu/content/images/2015/12/k-z-ns-g.png)

#### 2\. Milyen típusú mobil eszközöket használnak a látogatók?

A [Google Analytics](http://www.google.com/analytics/?ref=blog.fps.hu "Google Analytics") a legtöbb mobil eszközt be tudja azonosítani. Megmondja az eszköz gyártóját, típusát, képernyő felbontását, operációs rendszerét, stb. A későbbiekben a mobil eszközökre való optimalizáláshoz ezek a legfontosabb információk.

Azt is ellenőrizzük, van-e különbség a desktopról illetve a mobil eszközről érkező látogatók keresési szokásaiban (milyen arányban érkeznek a keresőkből, megtalálják-e a számukra szükséges és releváns információkat stb.)

#### 3\. Milyen kulcsszavakat és oldalakat használnak a mobil felhasználók?

A Forgalmi források > Minden forgalmi forrás > Keresés > Organikus almenüpontban tudjuk megtekinteni, mely kulcsszavakra érkeztek a látogatók az oldalunkra. Ha a másodlagos dimenziónál beállítjuk az állomásnevet, azt is megtudhatjuk, az adott kulcsszóval mely oldalakat tekintették meg a látogatók. Itt is meg kell vizsgálni az alábbiakat:

- Mennyire különböznek a kulcsszavak a teljes forgalmat és a mobil forgalmat összehasonlítva?
- Vannak-e olyan kulcsszavak, melyeket csak a mobilosok használnak?
- Azonosak-e a céloldalak az egyes kulcsszavak esetében?

![Google Analytics látogatás desktopon, mobilon képernyőkép](https://blog.fps.hu/content/images/2015/12/statisztika.png)

#### 4\. Hogyan jelenik meg az oldalunk az egyes eszközökön?

Vannak olyan oldalak, melyeken megnézhetjük, melyik eszközön hogyan jelenik meg az oldal. Ilyen például a [Mobile Phone Emulator](http://www.mobilephoneemulator.com/?ref=blog.fps.hu "Mobile Phone Emulator") vagy az [Opera Mobile Emulator](http://www.opera.com/developer/tools/mobile/?ref=blog.fps.hu "Opera Mobile Emulator"). Ezen eszközök segítségével megtudhatjuk, hogy minden tartalom, menüpont, kép, stb. hogyan jelenik meg az adott eszközön, illetve azt is megtudhatjuk, van-e esetleg olyan tartalmunk, ami esetleg egyáltalán nem jelenik meg.

#### 5\. Mely kulcsszavakra és mely oldalak jelennek meg a mobilos kereséseknél a keresőkben?

A [Google Webmestereszközök](https://www.google.com/webmasters/tools/home?hl=hu&ref=blog.fps.hu "Google WebMasters Tools") segítségével ellenőrizhetjük a lekérdezéseket és a mobil keresési eredményeket. A Forgalom > Keresési lekérdezések menüpontban tudjuk lekérdezni a teljes forgalmat és mobilos adatokat is. Ezen kívül lehet még tovább finomítani a lekérdezéseket, például hely vagy forgalom alapján. Az Analytics-szel ellentétben itt minden kulcsszót megtalálunk. Felül, ha fület váltunk, itt találhatóak a legnépszerűbb oldalak is, melyeket szintén tudunk mobilos felhasználókra is szegmentálni.

#### 6\. Hogyan térképezi fel és indexeli a webhelyet a mobil keresőrobot?

A Webmaster Toolsban az Egészség > Feltérképezési hibák almenüjében találunk erre vonatkozó információkat. A webhelyhibákon kívül az URL feltérképezési problémákat is láthatjuk, illetve érdemes még a menüpont többi almenüjét is átfutni.

### Dokumentáljunk!

Készítsünk magunknak egy dokumentációt, amibe rögzítjük a fenti adatokat. Így egyrészt könnyebben át tudjuk tekinteni az eredményeket, másrészt, ha a későbbiekben újra megismételnénk az auditot, könnyedén összehasonlíthatjuk az adatokat. Nem szükséges részletekbe menő több tíz diás prezentációt készíteni (hacsak nem a cégvezetőt szeretnénk meggyőzni), elég néhány táblázatba összefoglalni az adatokat, a lényeg, hogy könnyedén eligazodjunk rajta.

### Kell-e mobil SEO vagy sem?

Ha áttekintettük a fenti szempontokat, látni fogjuk, weboldalunk forgalmának mekkora részét teszi ki a mobilos forgalom, és azt is, milyen tevékenységeket végeznek ezek a látogatók. Nyilván nehéz egy olyan számot meghatározni, hogy mikortól kell ezzel foglalkozni, ezt mindenki a saját szakterülete, célcsoportja, weboldal forgalma, és még jónéhány szempont figyelembe vételével tudja mérlegelni. Egy biztos: a mobil eszközök térnyerése rohamosan növekszik, előbb-utóbb foglalkoznunk kell velük. Célszerű inkább előbb, mert könnyebb a konkurencia előtt járni, mint loholni utána.

### Vágjunk bele!

Ha az eredmények alapján úgy döntünk, belevágunk a mobilos kalandba, mindenképp érdemes a technológiai lehetőségekről is tájékozódni. Erről is írtunk egy [korábbi posztunkban.](https://blog.fps.hu/mobil-web-strategia-responsive-ress/ "mobil web stratégia")
### Hírlevél leiratkozás vagy leÍratkozás
URL: https://blog.fps.hu/hirlevel-leiratkozas/
Last updated: 2026-07-17T08:51:54.000Z
Nekem is, mint mindenkinek számtalan hírlevél ömlik a postafiókjába. Némelyik spam, de a nagyja céges email címre érkező reklám, ami mint tudjuk, teljes mértékben legális. Lehet arról vitatkozni, hogy ez rendben van így, vagy sem, de ez a rövid poszt most nem ezzel foglalkozik, hanem a leiratkozással.

### Legutolsó rövid leiratkozási történetem zanzásítva

Jó ideje kapom az egyik nagy magyar oldal hírlevelét, gondoltam most már leiratkozom. Bogarászom a mailt, végül nagy nehezen megtalálom a megfelelő linket, amiről szándékosan le van véve a kék aláhúzás, pont úgy néz ki, mint a többi szöveg, hogy még véletlenül se találjam meg, de ez még nem elég.  
A szövegből („a leiratkozáshoz kattintson ide”) csak az „ide” van linkelve, ami aranyos, mert a tabletemen próbálkozom 724523-szor, mire rájövök hova tappoljak. :@  
Megnyílik a böngésző, bejön az oldal, ami közli velem: ahhoz, hogy leiratkozzam, be kell jelentkeznem! :o  
Be is jelentkezem (csoda, hogy emlékszem a jelszóra). Megjelenik egy oldal, ahol van kb. 15 hírlevél lista, melyek mindegyikét ki-be lehet kapcsolni. MIND KI VAN KAPCSOLVA! Hmmm. Közben nyilván leiratkoztattak a kérdéses listáról, csak épp elfelejtették ezt közölni velem.

![Vasarolt_adatbazis_belfoldre1 listáról leiratkozás képernyőkép](https://blog.fps.hu/content/images/2015/12/contact.png)

Napi szinten legalább 4-5 hírlevélről iratkozom le, már ott tartok, hogy beütemeztem magamnak naponta 10 percet erre a tevékenységre, így bő tapasztalatom van a leiratkozás folyamatával kapcsolatban, ezért összegyűjtöttem pár jó tanácsot az oldalak üzemeltetőinek, fejlesztőknek.

### Miért akarod megnehezíteni a leiratkozást?

Tudom, kézzel-lábbal ragaszkodsz hozzá, nehogy elmenjen, kell a látogatószám, kell a konverzió. Hidd el, az üzletedet, avagy az ügyfeled üzletét a legkevésbé szolgálja, ha megnehezíted a felhasználó dolgát. Ha nem találja, vagy többször meg kell erősítenie, vagy emailt kell külön küldenie, csak felidegesíted szegényt. Ha eddig nem, akkor most már megjegyzi a branded nevét és jól elraktározza agyában egy jókora negatív előjellel egyetemben. Rosszabb esetben még el is meséli, megosztja tapasztalatait valamelyik közösségi csatornán, ami mind rossz hatással van, lesz a branded megítélésére. Tényleg ezt szeretnéd?

### Mit NE csinálj?

- eszedbe se jusson, hogy elhagyod a leiratkozási linket a hírlevélből!
- NE rejtsd el a leiratkozás linket! (pl. apró betűvel írva, csak egy „ide” felirat maga a link, illetve ugyanolyan színnel írod, mint a többi szöveg és még el is rejted, hogy az link)
- NE kérd a felhasználót, hogy küldjön egy ilyen-olyan tárgyú emailt (pl. UNSUBSCRIBE)!
- NE akard, hogy a felhasználó kitöltsön egy űrlapot és csak úgy iratkozhasson le! Az se jó, ha előre kitöltöd az űrlapot és azt várod tőle, hogy kattintson az Elküld gombra.
- pláne NE kérd, hogy bejelentkezzen az oldaladon és úgy állítsa be, miről akar leiratkozni!
- NE küldj emailt arról, hogy sikeresen leiratkozott!  
![Ön azért kapta ezt az e-mail, mert oldalunkon leiratkozott a hírlevélről. üzenet](https://blog.fps.hu/content/images/2015/12/leiratkozas.png)
- és végül NE zsarold a felhasználót érzelmileg!  
![Nem kérek több díjmentes szakmai információt](https://blog.fps.hu/content/images/2020/07/erzelmi-zsarolas.gif)

### Akkor hogyan csináld?

Ez nagyon egyszerű. Legyen egy jól látható link a hírlevélben, amire kattintva az oldaladra viszed a felhasználót és ott kiírod, hogy sikeresen leiratkozott a hírlevélről. Ennyi. Ha nagyon sok listád van, akkor ugyanezzel a metódussal leiratkoztatod arról a listáról, amiből érkezett és felhívod a figyelmét, hogy még van olyan lista, amin szerepel. Nem bonyolult.
### A felhasználót NEM érdekli, hogy…
URL: https://blog.fps.hu/felhasznalot-nem-erdekli/
Last updated: 2026-07-17T08:52:05.000Z
[Pete Warden blogján](http://petewarden.typepad.com/searchbrowser/2013/01/things-users-dont-care-about.html?ref=blog.fps.hu) találkoztunk ezzel a rövid, ámde velős és egyben vicces, de mégis nagyon komolyan veendő, pontokba szedett listával. Lefordítottuk és kép formájában megosztjuk veletek. Ajánlott mindenkinek az elolvasása és folyamatos fejben tartása.

Íme a kép, melyet a kép alatti gombbal letölthetsz vektoros PDF formátumban is, ha esetleg kinyomtatnád és kitennéd a faladra, vagy a fejlesztők, grafikusok, tervezők falára. **Mi biztos kitesszük ;)**

![a felhasználót nem érdekli, hogy…](https://blog.fps.hu/content/images/2015/12/afelhasznalotnemerdekli.png) 

[Töltsd le a posztert (0 letöltés)](https://www.fps.hu/presentations/felhasznalot-nem-erdekli-fps.pdf?ref=blog.fps.hu "Töltsd le vektoros PDF formátumban és nyomtasd ki magadnak!")
### fps blog 2012 összefoglaló
URL: https://blog.fps.hu/2012-osszefoglalo/
Last updated: 2026-07-17T08:52:16.000Z
Mielőtt belevágunk a 2013-as esztendőbe, visszatekintettünk picit az elmúlt évre, megnéztük, milyen témákról írtunk Nektek, és azt is, hogyan fogadtátok szakmai írásainkat.

### Ez történt 2012-ben

Az elmúlt évben **31 poszt** került ki szakértőink tollából, melyeket **átlag 768-an olvastatok**. **Átlagosan 131 megosztást** kaptak a bejegyzések, tehát majd minden hatodik olvasónk megosztotta posztjainkat valamely social media csatornán vagy emailen.

### Legolvasottabb írások

- [Konverziónövelés – acer shop tanulmány](https://blog.fps.hu/konverzionoveles-ux-acer/)
- [Miért kell az esztétikus design?](https://blog.fps.hu/miert-kell-az-esztetikus-design/)
- [Lokális hirdetés – egy lépéssel a konkurencia előtt](https://blog.fps.hu/lokalis-hirdetes-targetalas/)
- [Mobil SEO és a pitty-putty](https://blog.fps.hu/mobil-seo/)
- [Mit nekem social media?](https://blog.fps.hu/social-media-haszna-neked/)

### Legtöbbet megosztott posztok

- [Teljes nézet, normál, desktop verzió?](https://blog.fps.hu/mobil-desktop-nezetvaltas/)
- [Infografika, egy év vizualizálva](https://blog.fps.hu/fps-infografika-2012/)
- [Scrum és az ügyfél](https://blog.fps.hu/scrum-ugyfel/)
- [50%-os konverzió, mégis hogyan?](https://blog.fps.hu/mobil-lokalis-kereses-konverzio/)
- [Responsive email design](https://blog.fps.hu/responsive-email-design/)

### A leg-leg posztok

Két olyan írásunk is van, amely mind olvasottság, mind megosztás tekintetében magasan kiemelkedik a többi közül:

- [Magyar Responsive Web Design](https://blog.fps.hu/magyar-responsive-web-design/)
- [Mese a felhasználó központú tervezőről](https://blog.fps.hu/felhasznalo-kozpontu-tervezo-user-centred-designer/)

Ezúton is **köszönjük** az érdeklődéseteket, lájkjaitokat, megosztásaitokat, reméljük, sok hasznos információval szolgálhattunk Nektek. Ígérjük, 2013-ban sem maradtok olvasnivaló nélkül, az fps csapata továbbra is szállítja majd a friss és ropogós szakmai írásokat.
### Infografika, egy év vizualizálva 2012
URL: https://blog.fps.hu/fps-infografika-2012/
Last updated: 2026-07-17T08:52:25.000Z
Ismét eltelt egy év. Mindenkinek Boldog és Sikeres Új Évet kíván az fps csapata. Ennek apropóján készítettük el a 2012-es év fps vonatkozású adataiból az alábbi infografikát, mely reméljük, megnyeri tetszésetek. BÚÉK!

![fps infografika 2012](https://blog.fps.hu/content/images/2016/01/fps-infografika-2012.jpg)
### Mese a Felhasználó Központú Tervezőről
URL: https://blog.fps.hu/felhasznalo-kozpontu-tervezo-user-centred-designer/
Last updated: 2026-07-17T08:52:35.000Z
„A legtöbb cég ügyfélközpontúnak tartja magát, azonban az ügyfeleik közül csak kevesen tartják őket annak. Valószínűleg azt hiszik, ismerik a felhasználóikat, mert tervező csapatuk egyik tagja korábban már dolgozott ügyfelekkel. Ha az adatok csupán egy vagy két ember megfigyelésein alapulnak, az nem igazán mérvadó. Egy rendszer megtervezésénél több változat közül rendszerint a HIPPO dönt, azaz a legjobban fizetett ember véleménye (Highest Paid Person’s Opinion).”

David Travis: The fable of the User-Centred Designer című 2009-ben megjelent ebookjában közérthető és olvasmányos formában magyarázza el a Felhasználó Központú Tervezés (User-Centred Design) alapjait. Úgy gondoltuk, hogy közkinccsé tesszük magyar nyelven **MINDENKI** számára. A fordítást a [Favorit Fordító Iroda](http://www.bnyc.hu/?ref=blog.fps.hu "Favorit Fordító Iroda Miskolc") végezte, külön köszönjük az együttműködésüket.

Kérünk Benneteket, hogy **osszátok meg mindenkivel** a Felhasználó Központú Tervezés alapjairól szóló kis könyvet, hogy terjedjen az ige.  
**Jó olvasást!**

[Töltsd le a könyvet (0 letöltés)](https://www.fps.hu/presentations/mese-a-felhasznalo-kozpontu-tervezorol.pdf?ref=blog.fps.hu "Töltsd le a mese a Felhasználó Központú Tervezőről könyvet PDF formátumban!") 

*Ebook frissítve: 2012\. december 21\. 14:35*
### Scrum és az ügyfél
URL: https://blog.fps.hu/scrum-ugyfel/
Last updated: 2026-07-17T08:52:47.000Z
Az ügyfelek rendszerint azért keresnek fel egy fejlesztő céget, mert van egy ötletük/megérzésük, vagy mert nincs. Mindkét esetben elvárják, hogy a fejlesztő cég, mint szakértő lépjen fel. Segítsen boldogulni a nagy internetes katyvaszban, azzal meg, hogy ez a mobil dolog is képbe került, még inkább.

Van egy ötlete, vagy egy jól működő üzleti modellje és hát mindenhonnan ez az „e”, vagy „i” folyik… e-kereskedelem, iPhone, email – ja ezt már ismerjük. Lényeg, hogy működjön ugye! Mármint hogy pénzt hozzon!

**PÉNZT HOZZON!**

Kedves Szakértő, mondd meg, mitől fog ez működni az interneten, hogy lesz ez mobil?

### És akkor jön az első harc!

Kérem, nekem van sejtésem, de ugye Jézus koporsóját sem őrizték ingyen, szóval hát szívesen megmondom, hogy mitől lesz ez működőképes, viszont ez szakértői kompetenciát igényel.

> Ó, az nekünk nem kell, nem kell kutatás, nem kell szakértői tanulmány, csak mondjátok meg, mitől fog ez működni.

Kisebb-nagyobb tárgyalási bravúr árán végül lenyeli a békát és elfogadja, hogy pont ugyanazt szeretné, amit mi csinálunk. Ő szolgáltatást szeretne értékesíteni, mi meg már csináljuk, szóval ha azt várja, hogy majd neki fizessenek, akkor jobb, ha ő is fizet, már a tanácsért is.

### Jöhet a következő béka

![béka néz egy replüő legyet illusztráció](https://blog.fps.hu/content/images/2015/12/beka.png)

Még rútabb és göröngyösebb a háta, jöhet a tervezés! Ááá, hát az már több a soknál! Mikor lesz nekem weboldalam? Most tényleg még heteket a tervezéssel fogunk tölteni? Ez komoly?

> Nem. Kérem, mi agilisek vagyunk!

Ebben a pillanatban az ügyfél elbizonytalanodik és hátradől! Túl sok a bizonytalansági tényező! Nem tudom mit fogtok csinálni! Nem tudom hogyan - ha tudnám, tuti az unokaöcsém már megcsinálta volna, vagy éppen megcsinálta már és pont ezért vagyok itt. No, de hogy azt se tudjam, milyen “módszerrel”? Az már egy picit sok.

Akkor nekiesünk az ügyfélnek, mint tót az anyjának, hogy ugye van ez a Scrum, ami agilis és vannak benne sprintek, meg product backlog és akkor majd a review-n megmutatjuk és lehet nézni, hogy mennyi business value-t égetünk el, mert mi Story Pointban becslünk ám, de ha ez nem volna elég, akkor majd a daily standupon akár bele is hallgathat! Nyugodjon meg, az acceptance criteria az Ön igényei szerint alakul, és hát a prioritást is Ön határozza meg.

Ügyfelük arcán sápadtság és emlékképek jelennek meg első egyetemista vodka partijáról – utoljára akkor szédült ennyire. Csak ne hányjon, gondolhatjuk, és bizony jogos a félelmünk! Sajnos minden igyekezetünk ellenére az ügyfél vagy hányni fog, vagy pityókásan feláll és megfogadja, „soha többé nem iszik vodkát”.

### Elmegy?

Elmegy egy kevésbé profi céghez, ahol egyszerűen csak feladatok vannak, meg határidők és három-hat hónap keserves fejlesztés végén meglátja azt az oldalt amiről álmodott… **a fejlesztő!**

De ez nem az! – kiált, feláll, földhöz vágja a telefonját, belerúg a monitorba, letépi a fejlesztő kockás ingét és esze ágában sincs kifizetni azt a sommás kis összeget, amit egy kézzel kiállított számlán az orra alá tolnak 8 napos fizetési határidővel!

### Akkor mi a baj?

Az a baj, hogy én is elbizonytalanodom, amikor a hentes megkérdezi, hogy felsál vagy lapocka? …hát én csak a barátaimat várom vacsira és egy jó kis fokhagymás husit szeretnék eléjük tolni, hogy jól érezzék magukat és csússzon a kadarka!

### Mit vár tőlünk a megrendelő?

Azt hiszem működő szoftvert, a lehető leggyorsabban! Ezért vonzó a sok „dobozos” termék. Azok készen vannak – hiszi mindenki!

Az sem baj, ha olyan, ami maximálisan támogatja az üzleti modelljét. Az sem baj, ha már a fejlesztés alatt el tudja kezdeni használni, arról nem is beszélve, hogy a fejlesztés ideje alatt már pénzt is hoz. Neki, a megrendelőnek. Ne kattints, van ilyen! – no nem dobozban!

![Instant Portál feliratú doboz, mellette SALE felirat illusztráció](https://blog.fps.hu/content/images/2015/12/instantsale.png)

Sokan szoktak panaszkodni, hogy jó ez a SCRUM, de az ügyfeleknek olyan nehéz elmagyarázni, hogy mi is ez, meg hogy is működik. Ez igaz, már én is óvatosabb vagyok amikor eljutunk arra a pontra, hogy akkor mi is lesz és hogyan!

### Értsük meg az ügyfelet

Az első beszélgetések folyamán, próbáljunk meg ne a konkrét fejlesztés részleteire kitérni. Kérdezzük, értsük meg az üzleti modelljét és próbáljuk megérteni a gondolkodását. Kérjük meg, hogy mesélje el miért választják őt az ügyfelei, meséljen konkrét esetekről, hagyjuk és figyeljünk. Pont, mint az első randin. Meséljen magáról, mit szeret, mit nem szeret, ő hogyan választ terméket vagy szolgáltatást.

Nincs más dolgunk, mint biztosítani arról, hogy egy olyan módszertan szerint próbálunk dolgozni, ami az ő érdekeit tartja szem előtt, mert mi abban hiszünk, hogy ha az ügyfelünk megrendelői elégedettek a termékkel, szolgáltatással, akkor Ő is elégedett lesz velünk.

![egy ló két paraszt sakkbábút néz illusztráció](https://blog.fps.hu/content/images/2015/12/sakk.png)

Ekkor jön a legnehezebb pillanat. Ajánlatot kell adni a megismert feladatokra. Agilitástól függetlenül javaslom, hogy az ajánlatunkat személyesen vezessük elő, mutassuk be a részleteket. Kiváló alkalom arra is, hogy még beljebb menjünk a módszertan erdejébe. Mi már talán ismerjük az Ő gondolkodását, itt az alkalom, hogy Ő is megismerje a miénket. Ezzel kell, hogy záruljon az ajánlatadási szakasz. Ha minden rendben ment, akkor egy olyan ponton állunk, amikor tudjuk, kinek akarunk eladni és mit, ő pedig tudja, hogy mit kaphat tőlünk és hogyan.

Kérjünk egy külön időpontot a SCRUM bemutatására. Ezzel lehetőséget adunk az ügyfélnek arra, hogy a projektben résztvevő kollégáit összehívja, és közösen beszéljük át a módszertant. Ha még nem döntött mellettünk, akkor is megéri azt az egy órát rászánni, mert kiderül, hogy nyitottak-e a módszereinkre azok, akiken végül a projekt sikere múlik.

**Ne felejtsük, hogy a sikertelen projektnél még az is jobb, ha nincs projekt!**
### Mikroformátumok és SEO
URL: https://blog.fps.hu/mikroformatumok-seo/
Last updated: 2026-07-17T08:52:56.000Z
Mik azok a mikroformátumok és hogyan segíthetik a keresőoptimalizálást? Használatával tényleg jobb pozícióba kerülhet egy weboldal a keresőkben?

Kezdjük az elején. Mi is az a mikroformátum (angolul microformats, rich snippets) Olyan adatforma, melyekkel különböző adattípusok egységesítésére használnak. A mikroformátum a keresőrobotok és az emberek számára is értelmezhető és olvasható adat. Funkciója, hogy az egységes forma révén kereshetővé válnak az adatok, ezáltal más alkalmazásokba is egyszerűen beilleszthetőekké válnak, továbbá a szemantikus web egyik fontos alappillére.

A mikroformátumokat arra találták ki, hogy a két-három soros keresési eredményt hasznos és releváns tartalommal egészítse ki, ezzel is segítve a felhasználókat abban, hogy minél relevánsabb információkhoz juthassanak. Ha mikroformátumokat használunk, a keresőknek is segítünk abban, hogy jobban fel tudja térképezni az oldal tartalmát, mivel egy gazdag tartalmi kivonatot „nyújtunk át”. Például egy receptekkel foglalkozó weboldalnál mikroformátumban megadjuk az adott recept felhasználók általi értékelését, az elkészítésének idejét, a kalóriatartalmat, stb., ezekkel az információkkal is segítve a látogatót, hogy a találati listában ennek a weboldalnak a linkjére kattintson. Íme egy jó kis összefoglaló [infografika a mikroformátumokról](http://www.seomoz.org/blog/a-visual-guide-to-rich-snippets?ref=blog.fps.hu).

![Google találati lista mikroformátumokkal képernyőkép](https://blog.fps.hu/content/images/2016/01/emilio.png)

Néhány nagyon hasznos előnye:

- felkelti a látogató érdeklődését a találati lista oldalon
- biztosítja az azonnali információhoz jutást
- növeli az átkattintási arányt és csökkenti a visszafordulást

### Hogyan használjuk őket?

#### Válassz formátumot!

A Google támogatja a mikroformátumok használatát, és az alábbi formátumokat javasolja:

- [microdata](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=176035&ref=blog.fps.hu): HTML5 alapú formátum, segítségével a tartalmat olyan címkékkel lehet ellátni, hogy bizonyos típusú információkat – például ismertetőket, személyes adatokat vagy eseményeket – írjanak le.
- [microformats](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=146897&ref=blog.fps.hu): egy egyszerű formátum, mellyel bizonyos típusú információkat lehet leírni. Minden egységének megvannak a saját tulajdonságai.
- [RDFa](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=146898&ref=blog.fps.hu): szintén egy egyszerű leíró formátum, mellyel specifikus adatokat tudunk megadni a tartalomra vonatkozóan.

#### Jelöld ki a tartalmat!

A Google az alábbi tartalmi típusokhoz javasol mikroformátum használatot:

- személyekhez kapcsolható adatok (pl. név, születési idő, lakcím stb.)
- termékekhez kapcsolható adatok (pl. könyvek esetében szerző neve, könyv címe, kiadás éve stb.)
- cégekhez, üzletekhez kapcsolható adatok (pl. cég székhelye, fióktelep címe, nyitva tartás stb.)
- receptek (pl. elkészítési idő. értékelés, kalóriatartalom stb.)
- események (pl. egy esemény helyszíne, időpontja stb.)
- zene (pl. egy zenei album zeneszámai, lejátszási idő, előadók stb.)
- breadcrumbs (azonosítja az útvonalat és megjeleníti a találati lista szövegében)

![Vcard mikroformátum használata forráskódban példa](https://blog.fps.hu/content/images/2016/01/vcard.png)

#### Teszteld az adatokat!

Használd az [adat teszt alkalmazást](http://www.google.com/webmasters/tools/richsnippets?ref=blog.fps.hu), hogy megbizonyosodj arról, hogy a Google tudja olvasni a megadott információkat.

Ezek után nincs más teendőd, mint figyelni, hogy a Google hogyan indexeli be az oldalt és hogyan változik az oldal pozíciója a keresőkben.

Ezekre érdemes azonban odafigyelni:

- nem kell megijedni, ha kezdeti időkben nem jelennek meg a mikroformátumok a találati listában, ugyanis van valamennyi átfutási idő
- Ha egy-két hónap múlva sem jelennének meg, ki kell deríteni a [lehetséges okokat](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=1093493&ref=blog.fps.hu)
- **FONTOS: A mikroformátumok használata nem befolyásolja a keresőoptimalizálást.** Tehát attól, hogy meg vannak adva az oldalon ezek az adatok, még nem jelenti azt, hogy előrébb sorolódik a weboldalad a találati listában. Viszont hasznos információkat juttathatsz el a látogatóidnak, akik a találati listát böngészve nagyobb eséllyel kattintanak a Te oldalad linkjére.

Magyarországon még nem minden típusú mikroformátumot jelenít meg a Google (pl. céges adatokat, termékek adatait, recepteket, zenei tartalmak mikroformátumainak megjelenését már láttam), de ettől függetlenül érdemes használni, mert lehet, hogy akár holnaptól ezek az adatok is megjelennek a keresőkben.
### Teljes nézet, normál, desktop verzió?
URL: https://blog.fps.hu/mobil-desktop-nezetvaltas/
Last updated: 2026-07-17T08:53:06.000Z
Sok projektem van mostanság, melyek mobil (és tablet) webes megjelenésről szólnak. Nyilván egyedileg döntjük el az ügyféllel, hogy melyik úton indulunk el, viszont az alábbi problémába már nem először futok bele, melyre kellene egy szép megoldás. Segíts Te is, kommenteld a posztot, hátha. Thx.

Számomra nem kérdés, hogy a jövő egyértelműen a tartalom tervezésről (content design) fog szólni. El kell felejtenünk a pixel alapú gondolkodást, el kell szakadnunk a WYSIWYG paradigmától. A jól megtervezett tartalom minden csatornán használható és könnyedén megjeleníthető. A mobil web tekintetében a RESS (Responsive Design + Server Side Components) megoldás a jövőbe mutató, a kis kijelzőjű okostelefonoktól kezdve a nagy méretű okostévékig. Csak azért írom, mert az alábbi probléma ezzel a felfogással kicsit szembe megy.

### Fél Responsive Design (inkább fél RESS)

Több ecommerce (lesz belőle mcommerce :) oldalnál a gyors sebesség miatt és mert a desktopos oldal nagyon jól konvertál, azt javasoltam, hogy fél RESS irányba induljunk, vagyis a desktop mellett legyen egy RESS oldal, ami kiszolgálja a mobilokat, tableteket.

### Nincs lebutított mobil web!

Eszköztől függetlenül ugyanazokat az információkat, szolgáltatásokat kell nyújtani a felhasználók számára, ezért nagyon fáj, hogy szükséges kitenni egy, az asztali, desktopos nézetváltásra szolgáló gombot, linket. Hogy miért?

[Google kutatásban](http://blog.hubspot.com/blog/tabid/6307/bid/33631/The-20-Things-Users-Want-Most-From-Your-Mobile-Site-New-Google-Data.aspx?ref=blog.fps.hu) hangzik el az alábbi mondat:

> **74% of users** also cited they want the option to go to a full, non-mobile site version.

### A probléma

A problémám **a gomb, link elnevezése**. Szükségeltetik egy rövid, tömör, mindenki számára érhető magyar kifejezés. Mit csinál ilyenkor az ember elsőként? Megnézi, hogy mások milyen kifejezéseket használnak erre a célra. Rövid kutakodás után az alábbiakat találtam:

- Teljes (pl. index.hu, origo.hu)
- Teljes verzió (pl. nol.hu, nso.hu)
- Normál nézet (pl. hvg.hu)
- Normál verzió (pl. hwsw.hu)
- Eredeti weboldal :) (booking.com)

Ezekkel mind bajom van. A teljes verzió félrevezető, mert azt sugallja, hogy amit nézek az valami lebutított félmegoldás és érdemes a teljes változatra váltanom, mert ott több információt, szolgáltatást érek el. A normál verzió pedig mitől normál? A mobilos akkor nem normális? :) Tehát adott a kérdés: mi a jó megoldás?

Teszem hozzá angol nyelven sem jobb a helyzet: Classic site, Full site, Desktop version. Ez utóbbi talán a legszerencsésebb. Na, de mi magyarok vagyunk, kanyarodjunk vissza.

Gondolkodtam, gondolkodtunk, megkérdeztem twitteren, itt-ott, sok jó ötlet nem érkezett: Klasszikus, Monitor nézet, „Régimódi web” és hasonlók.

Ha nem megy szöveggel, akkor szimbolizáljunk gondoltam és készítettem két gomb variációt, amit alább láthattok. 

![képernyőket (mobil és monitor), illetve layoutokat mutató ikonok](https://blog.fps.hu/content/images/2015/12/mobil_desktop.png)

**Mi a véleményetek, van jobb elképzelésetek?** 
**Csináltok Ti is jó, jobb ikonokat?**

**Update**  
Bővíz László felvetése alapján a fenti két ikon kombinált változata:

![layoutokat mutató ikonok, csak erősebb kontraszttal](https://blog.fps.hu/content/images/2015/12/switch_mobile.png)

**Update**  
*2013\. január 12.* 

Szigetvári József hívta fel a figyelmem a tumblr megoldására, ami indirekt módon közelíti meg a problémát, vagyis a mobil nézetet lehet kikapcsolni és nem a „teljes” nézetre lehet váltani ;) íme lehetséges ikonok formájában:

![mobile felirat egy checkboxxal, ami be van pipálva és egyben egy gomb formáját ölti](https://blog.fps.hu/content/images/2015/12/mobilecheck.png)

ez a tuti ;)
### Mobilhirdetések optimalizálása
URL: https://blog.fps.hu/mobilhirdetes-mobil-ad/
Last updated: 2026-07-17T08:53:15.000Z
A mobil hirdetések egyre nagyobb teret nyernek a mobil eszközök terjedésével. Milyen hirdetési felületek, lehetőségek, megjelenési formák vannak a mobil eszközökön? Hogyan tudunk magas konverziós arányt elérni?

A 2012-es [Internet Hungary-n tartott előadásomban](https://www.internethungary.com/?ref=blog.fps.hu) ezekre a kérdésekre (is) kerestem a választ.

2012-ben a világ népességével megegyező számú eszköz csatlakozik az internethez, az előrejelzések szerint három éven belül ezen eszközök közel fele valamilyen mobil eszköz lesz. Az okostelefont használók átlagosan napi fél órát interneteznek mobiljukról, ez már most akkora tömeg, hogy igenis fontos nemcsak a mobil oldalak kialakításával, hanem a mobil hirdetésekkel is foglalkozni. Az elmúlt két évben számtalan tanulmány erősítette meg a mobil létjogosultságát, sőt mi több, a mobil és a desktop hirdetések közül a mobil hirdetések ma már sokkal jobban teljesítenek. A mobil hirdetések rendkívül hatékonyak, hiszen egészen pontos célzást tesznek lehetővé, így nagyobb konverziót lehet elérni egy-egy hirdetési kampánnyal. Hogyan kezdjünk hozzá? Milyen hirdetési felületek, lehetőségek, megjelenési formák vannak a mobil eszközökön? Hogyan tudunk magas konverziós arányt elérni? Mit jelent pontosan a lokális célzás? Kezdjük az elején.

### Mit értünk mobil alatt?

> „Mobile is a behavior, not a technology. It’s about accessing content wherever you are… It’s really the use that is mobile, not the device.”  
> – Anna Bager

A mobil egy viselkedésforma, nem egy technológiai megoldás. Ugyanúgy mobil eszköznek számít egy telefon, egy tablet, de akár egy notebook is, amelyekkel útközben információhoz tudunk jutni. Magyarországon idén, 2012-ben átlagosan 207 percet internetezünk – ebbe beletartozik a munkánk során a neten töltött idő is – és ebből a több, mint három órából napi 14 percet valamilyen mobil eszközről böngészünk. (Összehasonlításképp 2011-ben ez az idő még csak 3 perc volt!) A globális keresések 20%-a történik mobil eszközről, míg hazánkban az összkeresések 6%-a.

![Globálisan 20%, Magyarországon 6% a mobilos keresések aránya Desktophoz viszonyítva diagram](https://blog.fps.hu/content/images/2016/01/statisztika.png)

### Mire használjuk a mobil eszközöket?

Ma már egyre többen használják emailezésre az okostelefonjukat, egy [amerikai kutatás](http://www.dmnews.com/report-mobile-email-will-overtake-webmail-and-desktop-email-by-june/article/239192/?ref=blog.fps.hu) is ezt támasztja alá, miszerint a céges elektronikus levelezés jelentős része mobilon vagy tableten zajlik. A közösségi oldalakat is előszeretettel látogatjuk mobil eszköz segítségével. Egyre több keresést is innen indítunk, de szívesen olvasunk híreket, időjárás jelentést, vagy nézünk meg egy-egy videót. Ezek mind-mind olyan felületek, melyeken több időt töltünk el, tehát hirdetés szempontjából ideálisak. Nézzük meg picit mélyebben a kereséseket. A desktopról indított keresések 20, a mobilról indított keresések 40 százaléka lokális keresés. Akkor beszélünk lokális keresésről, amikor egy felhasználó valamilyen földrajzi területre vonatkozóan keres információt. Pl. egy olasz éttermet keres Budapesten, vagy egy fodrászt Baján. A mobil keresések fele valamilyen applikáción keresztül történik, pl. Google Maps. Ami viszont igazán értékessé teszi a mobil kereséseket az az, hogy a keresésre adott válaszidő mindössze egy óra!, szemben a desktoppal, ahol ez átlagosan egy hét. A lokális keresések 37 százalékában történik valamilyen konverzió, amely szintén nem elhanyagolható. ([A lokális keresésekről már egy korábbi posztban írtam](https://blog.fps.hu/lokalis-kereses-seo-mobil/))

### Hogyan hirdessünk mobilon?

Három csoportra oszthatóak a hirdetések, kettő már a desktopról jól ismert, a harmadik kifejezetten mobil specifikus.

#### Keresőkben történő hirdetés

Ez gyakorlatilag itt is a Google Adwords hálózatán keresztül történik. Nemcsak desktop és mobil eszköz közül tudunk választani, hanem többféle speciális beállításra is lehetőség van:

- operációs rendszer szerinti célzás (Android, BlackBerry, iOS)
- eszközmodellek szerinti célzás (pl. Samsung)
- szolgáltató szerinti célzás (Telenor, T-mobile, Vodafone)

A Google kulcsszó választó eszközében lehetőség van mobil keresési trendeket is nézni egy-egy kulcsszóra, így még pontosabban lehet célozni a hirdetést.

![Google hirdetés mobilon példa képernyőkép](https://blog.fps.hu/content/images/2016/01/hasznaltauto.png)

#### Display hirdetés

Ez is történhet a Google Adwords hálózatán keresztül, de vásárolhatunk display felületeket egy-egy mobilra optimalizált weboldalon, mobil applikációban is. Az [IAB mobil ajánlása](http://adverticum.hu/hirek/osszes/111/?ref=blog.fps.hu) kétféle hirdetési formátumot javasol, melyekkel standard méreteket szeretne kialakítani a mobil hirdetési piacon: ezek a 480x120 és 320x50 pixel méretűek.

![Bannerek mobilon képernyőképek](https://blog.fps.hu/content/images/2016/01/mobilhirdetes.png)

#### Push üzenetek vagy SMS/MMS üzenetek

Ez egy kifejezetten mobil formátum, mellyel költséghatékonyan és jól szegmentálhatóan lehet egy-egy üzenetet eljuttatni a felhasználókhoz. Push üzeneteket egy mobil alkalmazás segítségével is küldhetünk a célközönségnek.

![Push üzenet iOS alatt példa képernyőkép](https://blog.fps.hu/content/images/2016/01/pushuzenetek.png)

### Miért válasszuk a mobil hirdetéseket?

- kisebb a verseny: ha külön desktopra és külön mobilra célzott keresési hirdetéseket futtatunk ugyanazokkal a kulcsszavakkal, a mobilon jelenleg még jóval kisebb a verseny, így olyan kulcsszavakra is jó pozícióban tudunk lenni mobilon, amelyre desktopon nem, ezzel értékes látogatókat érhetünk el
- alacsony CPC, magasabb CTR: a kisebb versenynek köszönhetően alacsonyan tudjuk tartani a CPC-t, a keresésnél említett okok miatt viszont magasabb CTR-t tudunk elérni
- magasabb konverzió: mivel sokkal jobban célozhatóak a mobil hirdetések, lényegesen magasabb a konverziós ráta is a desktop hirdetésekhez képest
- közvetlen kapcsolat teremthető a termékkel: pl. a hirdetéshez telefonszámot rendelünk hozzá, és egy mozdulattal már tárcsázhatjuk is a hirdetőt
- eszköz specifikusan is célozható hirdetések: pl. iPadre készült alkalmazásunkat feleslegesen nem kell minden mobil eszközön hirdetni

### Miért szükséges a mobilra optimalizált site a mobil hirdetésekhez?

- a mobil hirdetések 42%-a jut el a felhasználókhoz
- 35%-uknak felkeltik az érdeklődését ezek a hirdetések, akik bővebb információt keresnek a termékről vagy szolgáltatásról
- 27%-uk valamilyen csatornán keresztül felveszik a kapcsolatot a hirdetővel
- és mindezt **MOBIL FELÜLETEN teszik**

### Néhány jó tanács, mielőtt mobil hirdetésbe kezdenénk:

- legyen mobilra optimalizált legalább a landing page
- itt is nagyon fontos a call-to-action
- bátran kísérletezzünk többféle formátummal, ami desktopon nem működött, lehet, hogy itt fog
- mivel mobilon általánosabb kulcsszavakkal keresünk, a kereső hirdetéseknél használjuk ezeket a kulcsszavakat is

A poszt a 2012\. október 16-i Internet Hungary-n elhangzott előadásom alapján íródott.
### Mobil web stratégia
URL: https://blog.fps.hu/mobil-web-strategia-responsive-ress/
Last updated: 2026-07-17T08:53:25.000Z
Sokszor felmerül a kérdés, hogy milyen stratégiát érdemes választanod, melyik útra lépj rá elsőként, ha a mobil eszközök felhasználóit is ki szeretnéd szolgálni. Mobil app, mobil web, responsive web design, RESS, szeparált mobil- és tabletoldalak a desktop mellett, mobil SEO, responsive e-mail design stb.

Az Internet Hungary 2012 m-commerce szekcióban tartott előadásomban ezekről a fogalmakról beszéltem, különös tekintettel a mobil web lehetőségeire, az egyes megoldások előnyeiről, hátrányairól, melyek segítenek meghoznod a megfelelő döntést. Nem az a kérdés, hogy szükséged van mobil webes jelenlétre vagy sem, hanem az: hogyan?

### Mobil web ~~vs~~ és natív applikáció?

![Mobil web és natív app felirat](https://blog.fps.hu/content/images/2016/01/mobilvsnative.jpg)

Ezt a kérdést számos blogon, cikkben, infografikán tették már fel, viszont sosem értettem a vs (versus), vagylagos kapcsolatot. Szerintem a mobil webes jelenlét az első és szükséges lépés, majd ezután következhet az egyes mobil operációs rendszerekre egyedileg fejlesztett native applikáció (ha egyáltalán szükség van rá).

Nyilvánvalóan vannak kifejezetten mobil eszközhöz kötődő szolgáltatások (native appok), melyekhez nem feltétlen szükséges a webes, mobil webes jelenlét, de ilyen esetekben is javallott a web használata, ha másért nem, akkor marketing célzattal (pl. [flipboard](http://flipboard.com/?ref=blog.fps.hu), [weather dial](http://www.wthr.co/?ref=blog.fps.hu) stb.).

Más a helyzet azonban a natív appokkal. Egyáltalán nem biztos, hogy szükség van rá. Biztos, hogy minden web shopnak, terméknek, szolgáltatásnak legyen külön appja?

Csak, hogy ne legyen olyan egyértelmű a dolog, a [Google kutatásában](http://blog.hubspot.com/blog/tabid/6307/bid/33631/The-20-Things-Users-Want-Most-From-Your-Mobile-Site-New-Google-Data.aspx?ref=blog.fps.hu) elhangzik egy fontos mondat, mely az „és” kapcsolatot erősíti a közcímben szereplő kérdésben:

> „A felhasználók 53%-a egy üzleti oldalon le szeretné tölteni a vonatkozó appot!”

### Miért mobil web?

A legkézenfekvőbb válasz: A linkek böngészőben, web viewban (appon belül jó esetben) nyitnak tartalmat! Azaz a felhasználó mobil eszközét használva a legkülönbözőbb helyeken találkozik az oldalunkra mutató linkekkel, melyekre tappolva a webes felületünkre jut.

![Mobil webre érkező forgalom források diagram](https://blog.fps.hu/content/images/2016/01/mobileweb.jpg)

Az ábrához meg kell jegyeznem, hogy a [QR kód használata terjedőben van](http://www.squarecode.biz/mobile-commerce/what-the-recent-explosion-in-qr-code-usage-mean-for-business-infographic/?ref=blog.fps.hu). A QR kódot bescannelő felhasználók 73%-a termék információt keres, 32%-a kupont tölt le és rendel, 25%-a esemény információt keres. Fizikai üzlettel rendelkező e-commerce oldalaknál például nagyon hasznos a polcokra, a termékekhez kihelyezett QR kód, amivel a vásárlók bővebben informálódhatnak a termékről. Személy szerint kicsit [szkeptikus vagyok a QR kódokkal szemben](http://www.thatwebguyblog.com/post/qr-codes-are-destined-for-failure/?ref=blog.fps.hu), habár a konferencián számos előadás számolt be sikerekről és a QR kód rohamos terjedéséről.

Visszakanyarodva az ábrához, a felhasználó tappolt, bescannelte a QR kódot stb. és az oldalunkra lépett. Miért baj az, ha ott nem mobilra optimalizált tartalommal találkozik? A fentebb már említett google kutatásból kiemelek fontos mondatokat, melyek egyértelműen megválaszolják ezt a kérdést:

> „A felhasználók 48%-a bosszankodik, ha nem mobilra optimalizált oldalra lép és 36%-uk úgy érzi, ez elpocsékolt idő.”

> „A felhasználók 48%-a szerint a cég nem törődik az üzletével, ha annak web site-ja nem jól használható okostelefonján.”

> „A márkahű felhasználók 50%-a se szívesen használja az oldalt, ha az nem mobilra optimalizált.”

> „A felhasználók 67%-a szívesebben vásárol terméket, szolgáltatást egy mobil-barát oldalon”

### Mobil webes böngészés

Ez mind szép és jó, de mégis mennyien böngésznek ma mobil eszközeikkel?

![Világtérképen a mobilos böngészés százalékos arányai. Magyarországon 5,13%](https://blog.fps.hu/content/images/2016/01/map.jpg)

A [pingdom viszonylag friss adatai](http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/?ref=blog.fps.hu) Európára 5.13%-ot mutatnak. Ez a teljes webes böngészésből a mobil eszközökön való böngészés által kihasított szeletet jelenti.

Ok, de mi a helyzet Magyarországon, mert ugyebár minket elsődlegesen ez izgat. A Sanoma által készített nagyszerű [MobilizeMe! infovideója](http://vimeo.com/49371901?ref=blog.fps.hu) szerint, saját portfóliójában jelenleg 4% körüli mobilos böngészést mutat, míg tavaly ez csak 1,5% volt, ami jelentős és gyors bővülést mutat. Az fps által fejlesztett és kezelt oldalakon 5% az átlag. Hmmm.

Kevésnek tűnhet ez az 4–5%, de figyelembe kell venned, hogy jelenleg a nagy corporate oldalak majd 70%-a, a [kisebb üzleti web site-ok 98%-a](http://news.yahoo.com/98-small-business-websites-not-mobile-optimized-according-090113766.html?ref=blog.fps.hu) még nincs optimalizálva mobil eszközökre! Egyből adódik a kérdés: hogyan változik az arány, ha bevezetjük mobilos oldalunkat? Egy aktuális példával tudom megválaszolni a kérdést:

A Nyugat Virginiai Egyetem oldalát nemrégen átalakították responsive-ra, ahol kevesebb, mint **[1 hónapon belül megduplázódott a mobilos forgalom](http://www.slideshare.net/dmolsenwvu/everything-you-know-is-not-quite-right-anymore-rethinking-best-practices-to-respond-to-the-future?ref=blog.fps.hu)**. (11%-ról 22%-ra nőtt).

Egyébként a jóslatok szerint 2014 lesz az az év, amikor megelőzi a mobilos böngészés a desktopost. Személy szerint biztos vagyok abban, hogy ez hamarabb be fog következni, ugyanis a mobil eszközök térnyerésével kapcsolatos jóslatok zöme tévesnek bizonyul, minden sokkal gyorsabban zajlik, mint azt bárki gondolná.

### Multi-screen activity

Ha a mobil webes jelenlétedet tervezed, rendkívül fontos figyelembe venned a felhasználói szokások folyamatos változását. Egyre több felhasználó rendelkezik több eszközzel úgy, mint okostelefon, tablet, notebook, PC, internetezésre alkalmas TV, melyeket szekvenciálisan és/vagy szimultán használnak. Ezt hívják multi-screen activity-nek, azaz többképernyős tevékenységnek. Ülünk a PC-nk előtt és mellette nyomkodjuk a mobilunkat, tabletünket, vagy a TV előtt ülve tesszük ugyanezt. Ezek jó példák a szimultán használatra, de az e-commerce oldalakat üzemeltető számára kiemelten fontos információ a szekvenciális (egymást követő) használat.

[![Google ábra, miszerint a felhasználók 67%-a multiscreent használ](https://blog.fps.hu/content/images/2016/01/shop-1.jpg)](http://blog.hubspot.com/blog/tabid/6307/bid/33565/34-Enlightening-Statistics-Marketers-Should-Know-About-Multi-Screen-Usage-Google-Data.aspx?ref=blog.fps.hu)

Bizonyított tény, hogy az okostelefon, tablet használók körében nagyobb arányú az online vásárlás, illetve az online fizetési módok használata. Szimplán a spontanaitásból fakad. A boltban, plakáton meglátunk vagy a barátunk felhívja figyelmünket egy termékre, szolgáltatásra és máris előkapjuk mobil eszközünket, rákeresünk, informálódunk, viszont 67%-ban a megrendelés, online fizetés, vagy az online hivatalos ügyintézés már inkább egy fix eszközön történik. Vagyis a nekünk tetsző termék oldalát elmentjük, elküldjük magunknak, stb., majd a tabletünkön, notebookunkon, vagy PC-nken megnyitjuk és jó esetben megvásároljuk azt. Mindezt a [Madhouse és a Gfk 2012\. szeptemberi magyar kutatása](http://madhouse.hu/Madhouse%5FGfK%5FHungaria%5FDCC%5Fkutatas%5F2012.pdf?ref=blog.fps.hu) is alátámasztja.

### Mobil webes tervezés

![ülő, fekvő, álló mobilozó ember figura illusztráció](https://blog.fps.hu/content/images/2016/01/poziciok.jpg)

Amikor nekiállsz, hogy megtervezd, megterveztesd a mobil webes oldalaid, érdemes a következőkkel tisztában lenned.

### Azonos tartalmú és funkcionalitású mobil, tablet és desktop változat

Konrétan idegrángást kapok, amikor arról beszélnek, arról olvasok, hogy a mobilra tervezett tartalom a desktop web site lebutított változata legyen. NEM! Nincs olyan, hogy mobil felhasználó, tablet felhasználó, desktop felhasználó. FELHASZNÁLÓK = EMBEREK vannak, akik minden szolgáltatást és tartalmat szeretnének elérni függetlenül a használt eszköztől.

### Felhasználó központúság

A User-Centered Design-nak (felhasználó központú tervezésnek) alapvetőnek kellene lennie minden termék esetében, mégis kiemelem ennek fontosságát, mert a kis képernyős mobil eszközök esetében hatványozottan fontos, hogy így tervezz, terveztess. Ha a jelenlegi web site-od nem funkcionális és nem úgy lett tervezve, hogy segítse a felhasználót feladatainak végrehajtásában, ideje újragondolnod, újratervezned azt. Így már most készülj fel arra, hogy valószínűleg ki kell dobnod a desktop oldalad és a nulláról kell indulnod.

### Sebesség

Érdekes, hogy mobil webes böngészésnél nagyságrendekkel türelmetlenebbek vagyunk, mint desktopon. Maximum 4–5 másodpercet vagyunk hajlandóak várni egy mobil oldal betöltésére, míg ez desktop esetében 7–8 másodperc. Ráadásul tudjuk, hogy a mobil adathálózatok sebessége finoman szólva sem a leggyorsabb. A lényeg, hogy sokat kell foglalkozni a mobil oldalak betöltési sebesség optimalizálásával.

### Érintőképernyő

Regényt lehet erről írni, most nem teszem :) Tudd, hogy a mobil webednek a lehető legjobban ki kell használnia a [gesture-ök](http://www.lukew.com/ff/entry.asp?1071&ref=blog.fps.hu) (érintőképernyős vezérlések) adta lehetőségeket, foglalkoznod kell a szövegek, gombok, linkek megfelelő méretével, az űrlapok optimalizálásával (HTML5 input elemek stb.).

### Mobil web stratégiai útvonalak

Milyen techonlógiai értelemben vett lehetőségek állnak előtted mobil web tekintetében? Ezeket veszem sorra, felsorolom azok előnyeit, hátrányait.

- Responsive Web Design
- RESS (Responsive Design + Server-Side Components)
- Szeparált oldalak
- Fél Responsive Design (fél RESS)

#### Responsive Web Design

Az RWD-ről már több ízben írtunk a blogunkban, javaslom olvasd el e[zt a rövid összefoglalót](https://blog.fps.hu/magyar-responsive-web-design/), ha nem vagy képben.

![kolboid feje monitor, tablet és mobil képernyőbe beletuszkolva illusztráció](https://blog.fps.hu/content/images/2016/01/reszponziv.jpg)

Röviden: adott a tartalom, melyhez külön stíluslapokat, stílus bejegyzéseket rendelve különböző felbontásokhoz igazodó elrendezéseket (layoutokat) hoz létre a fejlesztő csapat (CSS3 media queries). Jellemzően fluid (nyúlós) elrendezést alkalmaz (különösen a kisebb felbontások esetén pl. a mobil eszközöknél) és többnyire flexibilis képekkel operál (különböző méretek és a méret határokon belül méreteződnek) A lényege, hogy nem kell különálló web site-okat fejlesztened a különböző méretű kijelzővel és felbontással rendelkező eszközökre.

**Előnyei:**

- egy kódbázis – egy CMS
- bővíthető, eszközök sokaságára optimalizálható  
ne feledd, hogy folyamatosan jelennek meg új eszközök, különböző felbontásokkal, méretekkel.
- mobil SEO  
(a Google és a Bing az egy URL-es megoldást támogatja, írtunk kifejezetten [mobil SEO-ról blog posztot](https://blog.fps.hu/mobil-seo/), olvasd el)

**Hátrányai:**

- általában nagy méret (sebesség)  
ha ki akarod használni az érintképernyő adta lehetőségeket, akkor számos JavaScript libre, pluginre van szükség, továbbá rengeteg az olyan helyzet, amikor tartalmakat CSS-sel jelenítesz meg, rejtesz el a felhasználó elől és nem utolsó sorban a képek különböző méret változatait kell tárolnod, hogy minden eszközön optimálisak és jó minőségűek legyenek. Sajnos ezeket az elemeket a felhasználók letöltik eszközeikre, mely a betöltési sebességre nincs jó hatással.
- tervezés során kompromisszumokat kell kötni
- kvalifikált fejlesztők  
ide nem elég a dreamweaver guruk és jQuery plugin hasznosítók hada, komoly mobil webes tapasztalattal rendelkező fejlesztőkre van szükség, hogy minden a helyén legyen

**Milyen típusú oldalaknál érdemes alkalmazni:**

*Tudom, hogy ilyet kijelenteni kissé merész, mert nyilván ez „az attól függ” kategóriába tartozik, mégis úgy gondolom, hogy kiindulási alapnak nem rossz számodra.*

- blogok
- microsite-ok
- brand site-ok
- céges oldalak

#### RESS (Responsive Design + Server-Side Components)

Gyakorlatilag Responsive Web Design, viszont azt kiegészítik szerver oldali komponensekkel, így lehetővé válik, hogy szerver oldalon tudják a fejlesztők milyen eszközzel állnak szemben és attól függően küldenek vissza tartalmat az eszköz böngészőjének. Személy szerint a [WURLF-t](http://wurfl.sourceforge.net/?ref=blog.fps.hu) ajánlom, mely rengeteg eszköz részeletes adatait tárolja és teszi elérhetővé.

**Előnyei:**

- Minden, ami RWD
- Optimalizálható eszközökre

**Hátrányai:**

- Minden, ami RWD
- Szerver oldali eszközdetektálás nem 100%-os  
Miután a böngésző által küldött user-agent alapján történik az eszköz és annak képességeinek meghatározása, ezért nem teljesen megbízható. Sajnos a noname készülékek böngészői sok esetben „hazudnak”. Például van bent az irodánkban egy noname tablet, mely azt mondja magáról, hogy egy Samsung Galaxy okostelefon.

**Milyen típusú oldalaknál érdemes alkalmazni:**

- portálok, különösen hírportálok
- e-commerce site-ok

#### Szeparált oldalak

Manapság talán ez a legelterjedtebb megoldás szerintem nagyon helytelenül. Ez az a bizonyos m.domain.hu, t.domain.hu, domain.hu/mobil, domain.hu/tablet URL-es oldalak sokasága.

![m.domain.hu, t.domain.hu, domain.hu/mobil, domain.hu/tablet feliratok](https://blog.fps.hu/content/images/2016/01/domain.jpg)

**Előnyei:**

- egyedileg, eszközökre optimalizált oldalak
- sebesség

**Hátrányai:**

- több kódbázis, CMS problémák  
A legtöbb CMS (tartalomkezelő rendszer) nem képes kiszolgálni több domaint, ilyenkor a különböző oldalak verzióinál külön CMS-el kell dolgozni. Ha a CMS képes kiszolgálni több domaint, akkor is több helyen bele kell nyúlni (fejleszteni), hogy alkalmas legyen a különböző verziók megfelelő kezelésére
- drága fejlesztés és support
- szerver oldali eszközdetektálás nem 100%-os  
Itt is szükség van az eszközdetektálásra, hogy oda-vissza átirányítsuk a felhasználót a különböző verziók között. Például találkozom egy URL-el domain.hu/kategoria/termek és azt a mobil eszközöm nyitom meg, akkor azt át kell irányítani szerver oldalon az m.domain.hu/kategoria/termek URL-re. Jelzem, az nem megoldás, hogy a mobil, tablet, desktop oldal nyitó oldalra irányítod a felhasználót!
- SEO nehézségek (URL redirect, canonical)  
A Google (keresők) elől el kell rejtened a megtöbbszörözött tartalmat a content duplication elkerülése miatt.

**Milyen típusú oldalaknál érdemes alkalmazni:**

*Ha elegendő forrás (pénzügyi és humán) áll rendelkezésre, akkor érdemes vele foglalkozni, egyébként nem ajánlom.*

- portálok, hírportálok
- e-commerce site-ok

#### Fél Responsive Design (fél RESS)

A RESS és a szeparált oldalak mixelt változata. Különösen akkor érdemes elgondolkodnod rajta, ha a jelenlegi oldalad nagyszerűen működik, pénzt termel és abszolút felhasználó központú. Mind tudjuk, hogy egy redesignolt web site megnyitása után jelentősen visszaesik a látogatottság, mely persze néhány hónap után visszaáll és ha jól sikerült az újratervezés, kivitelezés, akkor még tovább növekszik. A legtöbb hazai cég nem akarja bevállalni és nem is biztos, hogy kibírná ezt az átmeneti veszteséget, így ilyen esetekben célszerű ennek az útvonalnak a választása.

Leegyszerűsítve: egymás mellett szeparáltan működik egy desktop változat (domain.hu) és egy mobil eszközöknek szánt responsive oldal (m.domain.hu).

**Előnyei:**

- optimalizált oldalak (desktop és mobil eszközök)
- szerver oldali eszközdetektálás elengendő  
a WURLF segítségével majdnem 100%-osan megállapítható, hogy az eszköz mobil vagy desktop.
- sebesség

**Hátrányai:**

- több kódbázis, CMS problémák
- viszonylag drága fejlesztés és support
- SEO nehézségek (URL redirect, canonical)

**Milyen típusú oldalaknál érdemes alkalmazni:**

- e-commerce site-ok
- portálok, hírportálok

### Mobil webre optimalizált online fizetés

![otpbank, escalion, paypal, payu logók](https://blog.fps.hu/content/images/2016/01/otp.jpg)

Amennyiben online fizetést szeretnél a mobil web site-on, érdemes olyan online fizetési szolgáltatást választanod, melyek mobilra optimalizált felületet biztosítanak. Jelen pillanat (2012\. szeptember) Magyarországon a következő négy lehetőség közül választhatsz (abc sorrend):

- escalion
- otpbank
- paypal
- payu

### Responsive Email Design

A teljes és következetes felhasználói élmény eléréséhez a web site-od által küldött emaileknek (jelszó emlékeztető, vásárlás összegző, stb.) is érdemes mobilra optimalizáltnak lennie. A [responsive email designról írtunk már blog posztot](https://blog.fps.hu/responsive-email-design/), olvasd el.

![image](https://blog.fps.hu/content/images/2016/01/hirlevel.jpg)

Érdekességnek [nézd meg ezt az infografikát](http://marketingland.com/infographic-iphone-beats-outlook-as-top-email-client-23481?ref=blog.fps.hu) a mobil eszközökön használt email kliensekről és a megnyitási arányokról a különböző kliensek függvényében. Annyit elárulok, hogy az iPhone-os email megnyitások száma megelőzte az Outlookból történő megnyitást. A napokban jelent meg [Nielsen kutatása a mobil emailezésről](http://www.useit.com/alertbox/mobile-email-newsletters.html?ref=blog.fps.hu), ahol Jakob szintén a responsive megoldást ajánlja.

Az előadáshoz készült prezentációt mengézheted, melynek végén a felhasznált források teljes listáját megtalálod:
### Hogyan használták az Internet Hungary 2012 mobil appokat?
URL: https://blog.fps.hu/internet-hungary-2012-mobil-appok/
Last updated: 2026-07-20T12:45:27.000Z
2012\. október 16–17-én volt Siófokon az Internet Hungary 2012 konferencia, melyhez ügynökségünk fejlesztette a mobil applikációkat. Ezekkel kapcsolatban osztunk meg információkat az alábbi infografikában. Köszönjük a visszajelzéseket és hogy használtátok az alkalmazásokat.
### Desktop vs. mobil keresés
URL: https://blog.fps.hu/desktop-vs-mobil-kereses/
Last updated: 2026-07-17T08:53:47.000Z
Az internetezési szokásaink változásával az interneten való keresési szokásaink is megváltoztak a mobil eszközök megjelenésével. Másképp keresünk, ha az asztali gépnél ülünk, mint akkor, amikor mobilon keresünk valamilyen információt.

Miért is van mindez? Amikor valamilyen mobil eszközön keresünk, jóval nagyobb arányban végzünk lokális keresést. Például épp haladunk valahova, és szükségünk van valamilyen információra, pl. megnézni a térképen, hogyan találunk oda az úti célunkhoz, van-e a közelben pl. benzinkút stb., ott az okostelefon kéznél, pár pillanat, és már meg is van a keresett célpont.

### Mitől mobil, illetve lokális a keresés?

Amikor egy felhasználó online keres információt valamilyen földrajzi területre vonatkozóan, akkor beszélünk lokális keresésről. Mobil keresésről pedig akkor beszélünk, ha valamilyen mobil eszközről indítjuk a keresést, pl. okostelefonról, tabletről, stb.. [(Lokális keresésekről írtam már egy korábbi posztban is](https://blog.fps.hu/lokalis-kereses-seo-mobil/).)

2011-ben a mobil keresések 40%-a, míg a desktop keresések 20%-a volt lokális keresés. 2012-ben a mobil keresések aránya elérte az 50%-ot, és még hátravan két és fél hónap az évből. A [BIA/Kelsey](http://www.biakelsey.com/?ref=blog.fps.hu) tanulmánya szerint 2015-re a mobil keresések aránya eléri a desktop keresések szintjét a lokális keresések viszonylatában.

[![A desktopos keresést várhatóan 2015-ben meghaladja a mobilos keresés diagram](https://blog.fps.hu/content/images/2016/01/desktop-mobile-stat.jpg)](http://streetfightmag.com/wp-content/uploads/120418.gif?ref=blog.fps.hu)

Konverziós időt tekintve desktop kereséseknél a válaszidő átlagosan egy hét, míg mobil keresések esetében **mindössze egy! óra**. Miért ekkora a különbség? A válasz a keresési szokásokban rejlik: mobil keresés esetében általában gyorsan van szükségünk információra, éppen ezért gyorsan is döntünk. Desktop-os keresés esetén nagyobb az esély, hogy több találatot nézünk meg, többféle kulcsszó variációval keresünk, kedvencek közé tesszük az adott oldalt, stb.

Mind a mobil, mind a desktop-os keresés esetében elmondható, hogy a lokális keresések 37%-a esetében történik konverzió (ez lehet vásárlás, megrendelés, regisztráció, stb.). Ezen keresések 26%-a teljesen egyedi kulcsszavakkal, illetve kulcsszó kapcsolatokkal történik.

A mobil keresések 49%-a valamilyen applikáción keresztül indul útjára, pl. Google Maps, Foursquare.

### Mikor hogyan keresünk?

Huszonnégy órára levetítve az alábbiak szerint alakulnak a keresések: reggel hattól délig a desktop vezet a mobillal szemben (elmegyünk dolgozni, bekapcsoljuk a PC-t/laptopot és azt használjuk). Ebédidőben átveszi a mobil a stafétát (ebéd közben a telefonunkat/tabletünket nyomkodjuk), majd a munkaidő végét követően a mobil keresések aránya ugrásszerűen megnő a desktoppal szemben (ekkor indulunk haza, intézzük az ügyeinket, stb.). Este 10 körül csúcsosodik ki a mobil használat, ekkor már többnyire ágyban vagyunk, a desktop drasztikusan lecsökken. Éjszaka is inkább mobil eszközt használunk.

[![Időben mikor hogyan keresünk, milyen eszközökön diagram](https://blog.fps.hu/content/images/2016/01/search-stat.jpg)](http://www.startapp.com/mobile-search-infographic/?ref=blog.fps.hu)

### Miben más a mobil keresés?

Íme néhány dolog, amit másképp csinálunk/használunk mobil eszközön, mint desktopon:

- általánosabb kulcsszavak: mobil eszközön általában egy, maximum két szóból álló kifejezéseket használunk
- automatikus kiegészítés: ezt desktop keresésnél is előszeretettel használjuk, de mobil keresésnél még inkább, mivel nem kell annyit pötyögni
- nemcsak böngészőből való keresés: elsősorban az okostelefonokban a böngészőn kívül is el lehet érni a keresőt, illetve ott a voice search is, (néhány hete már [elérhető magyar nyelven](http://googleblog.blogspot.hu/2012/08/voice-search-arrives-in-13-new-languages.html?ref=blog.fps.hu) is) de ide tartozik a valamilyen applikációból indított keresések is (a mobil keresések közel fele innen indul)
- más felhasználói viselkedés: míg desktopon hajlamosak és hajlandóak vagyunk akár több oldalnyi keresési találatot is átböngészni, mobil keresések esetében az első négy találat szinte „mindent visz”
- más keresési algoritmus: a google 2009 óta más algoritmust használ mobil keresések esetében, mint a desktopos kereséseknél. A lokális kereséseket előrébb hozza a találati listában, illetve ha valamilyen helyre utaló kulcsszóval keresünk, de nem adunk meg konkrét helyet, a hozzánk legközelebb eső helyeket fogja a találati listában előrébb hozni. Pl. a keresési kifejezésünk kínai éttermek, de nem írunk hozzá településnevet, viszont épp Pécsen tartózkodunk, akkor a google a Pécsen, illetve Pécs környékén található kínai éttermek listáját fogja a lista élére tenni
- változó találati lista: másképp rangsorolja a találatokat, a térképes, képes, videós tartalmakat előrébb sorolja a találati listában

### TOP 10 mobil keresőszó

A Startup 2012\. május havi adatai szerint világviszonylatban a TOP 10 legkeresettebb kulcsszavak az alábbiak:

1. Facebook
2. Google
3. Youtube
4. Hotmail
5. Yahoo
6. Google maps
7. Craigslist
8. Ebay
9. Twitter
10. ESPN

Ne felejtsük el, azért is ezek a szavak kerültek erre a listára, mert sokan nem a böngésző címsorába, hanem a keresőkbe írják be az oldal neveket, és úgy kattintanak a találati listában a keresett oldal linkjére.

Mobilra fel, használjuk ki a mobil eszközökben rejlő lehetőségeket! Még ugyan csak gyerekcipőben jár hazánkban a mobil keresés, már most foglalkoznunk kell vele, ott kell lenni a keresési találatok élén, hogy profitálhassunk ezekből a keresésekből addig is, míg a konkurencia nem foglalkozik vele.

A poszt a 2012\. október 3-i Az új szupersztár: a mobil – Traffic Meetup-on elhangzott előadásom alapján íródott. A prezentáció az alábbi gombra kattintva letölthető.

[Töltsd le a diákat](https://www.fps.hu/presentations/desktop%5Fvs%5Fmobil%5Fkereses.pdf?ref=blog.fps.hu "Töltsd le a prezentációt!")
### A nagy visszatérő: meta kulcsszavak
URL: https://blog.fps.hu/meta-kulcsszo-news-keywords/
Last updated: 2026-07-17T08:53:57.000Z
A meta kulcsszavak visszatértek! Bár nem abban a formában, ahogy évek óta használtuk a keresőoptimalizálás egyik alap eszközeként. A Google most picit más szerepet adott a meta kulcsszavaknak. Lássuk, hogyan működik.

A meta keywords tag használata néhány éve még alapvető eleme volt a keresőoptimalizálásnak, a Google algoritmus változásai azonban fokozatosan csökkentették jelentőségét. A Google néhány napja jelentette be [hivatalos blogján](http://googlenewsblog.blogspot.hu/2012/09/a-newly-hatched-way-to-tag-your-news.html?ref=blog.fps.hu) az új funkciót. Az új news\_keywords tag nem a régi meta keywords szerepét veszi át, a funkciója némileg módosul. Az új metatag gyakorlatilag az online újságoknak jelent segítséget, hogy figyelemfelkeltő címeket és híreket tudjanak használni, és ne kelljen aggódniuk a kulcsszavak miatt. Az újságíró kötöttségek nélkül fogalmazhatja meg a szöveget, a cikkhez tartozó kulcsszavakat pedig a news\_keywords tag után adhatjuk meg. Sokszor ugyanis a hírre jellemző kulcsszavak nem, vagy más formában jelennek meg a szövegben, így SEO szempontból nagyon nehéz jó eredményt elérni. A news\_keywords metatag ezt a problémát hivatott orvosolni.

### Hogyan használjuk a news\_keywords tag-et?

A Google már [létrehozott egy oldalt](http://support.google.com/news/publisher/bin/answer.py?hl=en&answer=68297&ref=blog.fps.hu), amely segítséget nyújt a news\_keywords tag használatához, mely így néz ki:

![meta news_keywords példakód](https://blog.fps.hu/content/images/2016/01/meta.jpg)

Maximum 10 kulcsszót célszerű használni, vesszővel elválasztva egymástól. Ez a tag is a része. Ha ezt a tag-et használjuk a kulcsszavak megadására, akkor a „hagyományos” meta keywords tag-et nem szükséges megadni. A Google ugyanakkor figyelmeztet, attól, hogy ezt a tag-et használjuk, még nem jelenti azt, hogy gyorsabban fogja az adott tartalmat rangsorolni. A kulcsszavak sorrendje nem számít, viszont hatással vannak egymásra, pontosíthatják egymás jelentését, ezért sem célszerű egy szót többször is szerepeltetni.

Azonban tartsunk néhány dolgot szem előtt:

- ahhoz, hogy a szerkesztők megtalálják az egyensúlyt a tartalom és a kulcsszavak között, több idő és odafigyelés szükséges, ezért ne sajnáljuk rá az időt, hosszú távon kifizetődik a belefektetett energia
- ez a tag egyelőre csak a Google Hírek találataira lesz hatással (használd, mert hamarosan beépítik az algoritmusukba!)
- a cikkeknek továbbra is szükségük lesz jól megfogalmazott lead szövegekre a keresések, valamint a social media-s megjelenések miatt
- a cikkekhez tartozó képek címkéire nem alkalmazható ez a metatag
- ne feledjük, a hatékony optimalizálás nemcsak a relevanciát és a rangsort befolyásolja, hanem az átkattintási arányt is. Legyen szó hírkeresésről, webes keresésről, a cél, hogy a hír megragadja a tekintetet, felkeltse az érdeklődést, ezáltal kattintásokat hozzon
- bátran használjunk ritkábban használt kulcsszavakat is

Használjuk bátran a **news\_keywords tag**\-et, de sose hagyjuk figyelmen kívül az alapvető keresőoptimalizálási szempontokat, mivel ez a metatag nem helyettesíti, csak kiegészíti azt.
### A 7 legfontosabb dolog, amit a vevőid akarnak
URL: https://blog.fps.hu/mit-akarnak-a-vevok-infografika/
Last updated: 2026-07-17T08:54:07.000Z
A vevőid nem csupán a termékedre vagy szolgáltatásodra kíváncsiak. Olyan embereket keresnek, akiknek a munkájában megbízhatnak. Mire is vágynak valójában?

Függetlenül attól mivel foglakozol, többet akarnak pusztán nagyszerű termékeknél, vagy működő megoldásoknál. Amit igazából tudni szeretnének az, hogy bízhatnak a munkádban, vagy sem. Az infografikán látható hét dolgot várják el tőled.

[![7 legfontosabb dolog, amit a vevőid akarnak](https://blog.fps.hu/content/images/2016/01/infographic_760.png)](http://www.fps.hu/mail-frame/infographic.png?ref=blog.fps.hu "a 7 legfontosabb dolog, amit a vevők akarnak")

*klikkelj, tappolj a képre a nagyobb mérethez*
### Responsive Email Design
URL: https://blog.fps.hu/responsive-email-design/
Last updated: 2026-07-17T08:54:16.000Z
Egyre többen és egyre többet használjuk mobil eszközeinket emailek olvasására is. [Egy amerikai kutatás szerint](http://www.dmnews.com/report-mobile-email-will-overtake-webmail-and-desktop-email-by-june/article/239192/?ref=blog.fps.hu) 2012\. júniusától az USA-ban többen olvassák emailjeiket mobilon vagy tableten, mint számítógépükön vagy webmailen keresztül. A legérdekesebb, hogy az összes mobil eszközön megnyitott emailek 85%-kát Apple eszközön olvasták.

Tudom, ez Magyarország, de itthon is tanúi lehetünk a mobil eszközök hihetetlen terjedésének, így eljött az ideje, hogy az emailekkel is foglalkozz. A „hagyományos” html emailek (hírlevelek, különböző üzenetek stb.) mobilon való megtekintésekor jelentkező problémákat az alábbi kép szemlélteti. Ez a hírlevél ma érkezett a postafiókomba (spam :)) és az iPhone-omon készítettem a képernyőképet.

![hírlevél képe egy mobilon, ami kicsi, zsúfolt, olvashatatlan és átláthatatlan](https://blog.fps.hu/content/images/2016/01/mobileemail.jpg)

### Mi a gond ezzel?

- az elrendezés összecsúszik
- a szöveg mérete oly kicsi, hogy az olvashatatlan, ha elkezdem nagyítani, akkor nagyon hamar az idegeimre megy a tologatósdi
- a képek szintén aprók nem mondanak semmit
- a „tappolható” területek mérete nem felel meg az elvártnak, azaz az ujjammal képtelenség „eltalálni” azokat, csak nagyítás árán

Nyilvánvaló, hogy ez az állapot nem segít a hírleveled konverziós rátáján, tehát mindenképpen tenned kell valamit. A [mobil vezeti az email forradalmat](http://returnpath.net/landing/mobilestudyQ212/Mobile%5FInfographic.jpg?ref=blog.fps.hu) címmel a Return Path közreadta infografika formájában fél éves (2011\. október – 2012\. március) kutatásának eredményeit, melyet érdemes átnézned, és nem lesz kétséged afelől, hogy a hírleveleiden dolgoznod kell.

### Mi a megoldás?

Ha olvastad a korábbi bejegyzésünket a [Responsive Web Designról](https://blog.fps.hu/magyar-responsive-web-design/), akkor már sejtheted is, igen, a Responsive Email Design. Szerencsére az okostelefonok, tabletek levelező kliensei elégségesen támogatják a vonatkozó W3C ajánlásokat, így lehetőség van arra, hogy RWD-t alkalmazz(unk).

### Mit kell tenned?

Újra kell tervezni a hírleveleket, több ok miatt is:

- szinte biztos, hogy a mostani html emailben a linkek, gombok „tappolható” mérete kicsi és nem felel meg a kényelmes érintőképernyős használatnak
- fogadok, hogy feleslegesen túl sok a szöveg
- az is valószínű, hogy sok képet és nagy méretben használsz. Erről le kell mondani, mert szükség van a gyors betöltésre. A mobil email kliensek azonnal letöltik a képeket is, szemben a desktopos kliensekkel, melyek alapértelmezetten megkérdezik, hogy le akarod tölteni azokat, vagy sem.

Ajánlom figyelmedbe a Luke Wroblewski által kitalált [Mobile First paradigmát](http://www.lukew.com/ff/entry.asp?933&ref=blog.fps.hu), illetve egy infografikát, ami bemutatja [a tökéletes mobil email anatómiáját](http://litmus.com/blog/anatomy-mobile-email/anatomy-mobile-email-24-1000px?ref=blog.fps.hu).

[![Anatomy of the perfect mobile email infografika a Litmustól](https://blog.fps.hu/content/images/2016/01/mobileanatomy.jpg)](http://litmus.com/blog/anatomy-mobile-email/anatomy-mobile-email-24-1000px?ref=blog.fps.hu)

### Talán a legfontosabb

Hajlamosak vagyunk nem folyamatokban gondolkodni. Megelégszünk azzal, hogy elkészítjük a szuper responsive email designos HTML emailünket és örülünk. Vajon a tökéletes call-to-action gombunkra kattintva a felhasználó egy mobilra optimalizált oldalra fog érkezni? Ha nem, felesleges volt minden erőfeszítés.

*UPDATE*  
A Google végre 2016\. szeptember végére megígérte, hogy [Gmailben támogatni fogja a media query-k használatát](https://www.campaignmonitor.com/blog/email-marketing/2016/09/responsive-email-support-in-gmail-is-coming/?ref=blog.fps.hu)! \\o/
### 50%-os konverzió? Mégis hogyan?
URL: https://blog.fps.hu/mobil-lokalis-kereses-konverzio/
Last updated: 2026-07-17T08:54:26.000Z
A mobil eszközök rohamosan fejlődő piacán olyan jelek mutatkoznak, melyekből egyértelműen kitűnik, hogy a mobil lesz a legmeghatározóbb eszköz a következő években. A [marketingland.com egyik tanulmánya](http://marketingland.com/study-50-percent-of-mobile-queries-in-travel-restaurants-autos-result-in-a-purchase-18404?ref=blog.fps.hu) konkrét iparágakkal és számokkal támasztja alá mindezt, amely annyira előremutató, hogy úgy gondoltuk mindenképpen lefordítjuk Nektek.

Az okostelefonok és a táblagépek megjelenése új lehetőségeket nyitott meg a piacon. Az elmúlt két évben számtalan tanulmány erősítette meg a mobil létjogosultságát, sőt mi több, a mobil és a PC hirdetések közül a mobil hirdetések ma már sokkal jobban teljesítenek. A legújabb kutatások elsősorban a mobil felhasználók viselkedését és fogyasztói magatartást vizsgálták.

Az egyik ilyen – közelmúltban megjelent – Amerikában készült tanulmány rámutat arra, hogy a legtöbb keresés három nagy iparág irányába történik (vendéglátás, autó, utazás), és különbségek mutatkoznak az okostelefon és tablet használat között is a felnőttek körében. A kutatás alapja egy online felmérés volt, mely 1500 amerikai okostelefon és tablet tulajdonos felhasználói magatartását figyelte meg. Az eredményekhez használt adatokat két forrásból gyűjtötték össze, a Telmetrics hívás lokalizátorból és az xAD mobil hirdetési hálózatból.

### TOP témák: Vendéglátás, autó, utazás

A tanulmányban vizsgált három iparág a vendéglátás, utazás és autóipar voltak. Az adatok egy része meglepő eredményekkel szolgált, más részük megerősítette a korábbi piaci tapasztalatokat.

#### Meglátni és megszerezni!

A tanulmány szerint a vásárlói magatartás eszköz és iparág szerint változik, például a megtekintés és a vásárlás között eltelt idő iparáganként eltérő. Az éttermek esetében például az okostelefont használók 89 százalékának, míg a tabletet használók 84 százalékának volt azonnali vásárlási szándéka és a keresést követően 24 órán belül vásárolt is. Viszont az okostelefont használók 64 százaléka, a tabletet használók 44 százaléka hoz döntést egy órán belül.

Az utazás és az autó iparágban azért több idő telik el a keresés és a tényleges vásárlás között. A tanulmány megállapította, hogy a mobileszközt használók egyharmada egy napon belül befejezik a tranzakciót. Autós témakörben a mobil felhasználók 49 százaléka vásárolt azon a napon, amikor a keresést indította. Mindkét kategória esetében – függetlenül az időtényezőtől – a felhasználók közel fele vásárolt a keresést követően (Autós témakörben 51%, míg utazás témakörben 46%). Az éttermek esetében ugyanez az arány 85 százalékos.

Végülis az okostelefonon vagy tableten keresők fele vásárlást hajtott végre, ez döbbenetes, **50%-os konverziós arányt jelent**.

![](https://blog.fps.hu/content/images/2016/01/arrow.jpg)

### „Helyben vagyunk!”

Egy másik jelentős eredmény, melyet [az IAB és más korábbi kutatások is megerősítenek](http://internet2go.net/news/data-and-forecasts/study-localization-best-way-make-mobile-ads-relevant-users?ref=blog.fps.hu), a lokális hirdetéseknek nagy szerepük van a mobil eszközökön. Megkérdezték a mobil eszközt használókat, mely tényezők késztetik őket arra, hogy reagáljanak egy hirdetésre. Az alábbi válaszok születtek:

- hirdetések, amelyek helyileg rám vonatkoznak (okostelefont használók: 73%, tabletet használók 70%)
- a hirdetések, amelyek kuponokat/akciókat kínálnak (okostelefont használók: 72%, tabletet használók 69%)
- Ismert márkák hirdetései (okostelefont használók 59%, tabletet használók 65%)

A tanulmány azt is megállapította, hogy a mobil eszközt használók 66 százaléka észleli a hirdetéseket, és 33 százalékuk rá is “kattint”.

### Útközben vs. otthoni használat

Több forrás is megerősítette, hogy a tablet használat az esetek 72 százalékában otthon történik, míg az okostelefon használat 68 százaléka útközben (bár elég magas itt is az otthoni használat). Mivel a 7 inch-es tabletek száma folyamatosan növekszik, valószínűsíthetően nőni fog tabletek esetében a házon kívüli használat, azonban egyelőre még inkább otthoni jelenség.

A három vizsgált iparág közül a vendéglátás és az autós szolgáltatásokra való keresés, autóból, mint domináns helyszínről valósult meg, főleg okostelefonnal. Utazás témakör esetében az otthoni keresések száma magasabb, mint az útközbeni (37% szemben a 28%-kal). Kétségtelen, hogy az okostelefonok két leggyakoribb használati helye az otthonunk és az autónk. Ez utóbbi esetben az emberek éppen úton vannak, hogy vásároljanak valamit és közben információt gyűjtenek ehhez, részben ezért ennyire magas a konverzió.

![Kistücsök Étterem Google találatként képernyőkép](https://blog.fps.hu/content/images/2016/01/kistucsok.jpg)

### Hívások és térkép lekérdezések

A leggyakoribb használati ok akár okostelefon, akár tablet esetében egyaránt egy bolt vagy szolgáltató kapcsolati adatainak és tartózkodási helyének keresése. A tanulmány megállapította, hogy a mobil eszközt használók 73 százaléka keresett telefonszámot és lépett kapcsolatba a bolttal az elmúlt 30 napban és 84 százaléka keresett rá valamely boltra a térképen vagy keresett útvonalat ahhoz.

Végül a tanulmány rámutatott arra, hogy az egyes iparágakban más-más az alkalmazások és weboldalak használata eszközönként. A felmérés szerint:

- Okostelefon használók esetében: a lokális linkgyűjtő applikációk a legnépszerűbbek az éttermet és autós szolgáltatásokat keresők körében (53 és 34 százalék), a brand site-ok (mobil web) a legnépszerűbbek az utazást keresők körében (47%)
- Tabletet használók esetében: a márkaoldalak (mobil web) a legnépszerűbbek minden kategóriában (Éttermek: 51%, utazás 56%, autós 48%)

A tanulmány egyértelműen megerősíti azt a feltételezést, hogy a mobil eszközt használók sokkal inkább készek vásárolni, mint PC-s társaik. Ez is azt mutatja, hogy a jól célzott, lokális mobil hirdetések sokkal relevánsabbak a vásárlókra nézve, mint a lokális célzás nélküli, általánosabb hirdetések.

Van már mobil webes jelenléted? Megtalálható vállalkozásod foursquare-en, Google Places-ben, stb.? Ha hirdetsz Google Adwords-ben, mobilokon is megjelenik hirdetésed? Nos, itt lenne az ideje!
### Sebesség optimalizáció mindenek felett
URL: https://blog.fps.hu/sebesseg-optimalizalas-gyors-honlap/
Last updated: 2026-07-17T08:54:35.000Z
Az egyik legfontosabb felhasználói elvárás a webes alkalmazás (különösen mobil web) használata közben, az oldalak betöltési sebességének gyorsasága. Ki akarna olyan szolgáltatást igénybe venni, amely lassú, nehezen kezelhető és csak az időnket rabolja?

Sok kutatást végeztek a betöltési sebesség konverzióra gyakorolt hatásával kapcsolatban. Két ilyen tanulmányt emelek ki, melyek egyértelműen megmutatják, hogy közvetlen a kapcsolat.

- Amikor [az amazon.com **betöltési ideje 100 ms-al megnőtt**](http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html?ref=blog.fps.hu), az **eladások száma 1%-kal csökkent**.
- [a Google betöltési ideje **500 ms-al megnőtt**](http://news.cnet.com/8301-10784%5F3-9954972-7.html?ref=blog.fps.hu), akkor **20%-kal kevesebb keresést** hajtottak végre a felhasználók

A két felmérésből tisztán látszik, hogy **foglalkozni kell a sebesség optimalizációval.**

Első blikkre mindenki azt gondolja, hogy szerver oldalon kell fejlesztéseket végezni. Nem állítom, hogy a több memória, gyorsabb processzor, háttértár, különböző web szerver és program értelmezést, futtatást gyorsító kiegészítők és nem utolsó sorban az optimalizált kód (legyen az php, asp.NET, stb.) nem fontosak, de csak 20%-ban befolyásolják a betöltési időt.

[A betöltési idő nagyrészt az oldalak különböző elemeinek (képek, stíluslapok, JavaScriptek stb.) letöltésével és azok feldolgozásával telik](http://developer.yahoo.com/performance/rules.html?ref=blog.fps.hu#num%5Fhttp), mely a teljes folyamat 80%-át teszi ki. Az elemek számának lecsökkentésével növelhető a betöltési sebesség. **Ez a kulcsa a gyors oldalaknak!** Ebben a posztban a szerver oldallal nem foglalkozom, csak minimális mértékben.

### Milyen előnyei vannak a gyors webes alkalmazásoknak?

- a pozitív felhasználói élmény alapja
- keresőoptimalizálást segíti (a Google a találatok osztályozásánál figyelembe veszi a sebességet)
- hozzájárul a konverzió növekedéséhez

**Tedd boldoggá a felhasználóid egy gyors webes alkalmazással!**

![két aranyos kislány mosolyog](https://blog.fps.hu/content/images/2016/01/keraranyoskislanymosolyog.jpg)

### Mit kell tenni, hogy növeljük a sebességet?

#### Http kérések számának csökkentése, CDN használat

Vagyis minél kevesebb kérés érkezzen a szerver felé. Tegyük fel, hogy van egy 100 kB-os file, illetve két 50 kB-os fájl. Egyértelműen a 100 kB-os fájl letöltése lesz gyorsabb, mert két fájl esetén pluszban megjelenik a második kapcsolat inicializálásra fordított idő.

A másik amiről tudni kell, az az, hogy a böngészők limitálják az egy hosztról egy időben letölthető fájlok számát. Íme, egy lista a fontosabb böngészők korlátozásáról:

- [Internet Explorer 8: 6 kapcsolat](http://msdn.microsoft.com/en-us/library/cc304129%28VS.85%29.aspx?ref=blog.fps.hu)
- [Internet Explorer 9: 4 kapcsolat](http://www.computertipsfree.com/enable-more-simultaneous-downloads-in-internet-explorer-9/?ref=blog.fps.hu)
- [Google Chrome: 6 kapcsolat](http://code.google.com/p/chromium/issues/detail?id=12066&ref=blog.fps.hu)
- [Firefox 3-: 15 kapcsolat](http://kb.mozillazine.org/Network.http.max-connections-per-server?ref=blog.fps.hu)

Ez a korlát nagyon szoros, ezért az okos fejlesztők mindenféle trükköt agyalnak ki a kikerülésre, csak néhány hasznos megoldás ezek közül:

- miután a böngészők hosztra korlátoznak, ezért szoktak használni különböző aldomaines megoldásokat pl. images.website.hu, docs.website.hu stb.
- CDN – vagyis [Content Delivery Network](http://en.wikipedia.org/wiki/Content%5Fdelivery%5Fnetwork?ref=blog.fps.hu). **Használata kötelező!** A nagy mogulok (Google, Amazon, stb.) a világ számos pontján üzemeltetnek szervereket és ingyen, vagy kevés pénzért szolgáltatnak CDN-t, aminek haszna, hogy nem a Te szervered szolgálja ki a kód letöltését, hanem a felhasználóhoz legközelebb eső szerver és az is nagy sávszélességgel, rendelkezésre állással. Például a jQuery lib minden verziója megtalálható a [google CDN-jén](https://developers.google.com/speed/libraries/devguide?ref=blog.fps.hu).
- Expire http fejlécek beállítása is jó és követendő megoldás. Ilyenkor a böngésző cache-ből tölti be kliens oldalon a kívánt fájlt. Megjegyzendő, hogy a DNS Lookup is időbe telik (még ha kevés is).
- nemrég egy nagyon okos megoldással találkoztam. Dropboxra, Google Drive-ra, Microsoft SkyDrive-ra töltik fel a statikus tartalmakat és onnan linkelik. :)

#### Jó sitebuild

Erről [írtam egy posztot, olvasd el](https://blog.fps.hu/a-sitebuild-sitebuilder-fontos/). A lényeg, hogy minél kevesebb legyen a HTML kód, amennyire lehetséges, a megjelenítést szeparálni kell a tartalomtól. A teljesség igénye nélkül néhány tipp:

- tagnél add meg minden esetben a kép valódi méreteit és ne hagyd a böngészőre annak meghatározását, pláne ne bízd rá, hogy méretezzen (ez mind időbe telik)
- CSS tippek:  
  - kerüld a \* használatát, szerencsétlen böngésző a DOM-ot sokszorosan járja végig és megpróbálja alkalmazni a feltételed, inkább támaszkodj az öröklődésre. Például ilyet NE: html \* {font-size:12px;}
  - # content #rightpanel #loginform input\[type=”submit”\] {width:100px;} helyett elég a #loginform input\[type=”submit”\], azaz ne dolgoztasd feleslegesen a böngésző motort
  - kerüld az ismétléseket, avagy vond össze a hasonló stílussal rendelkező elemeket
  - használd az összevont megadási lehetőséget, pl. background: #fff url(image.png) top right no-repeat;
  - lehetőség szerint kerüld a class-ok használatát, csak indokolt esetben alkalmazd

#### CSS sprite-ok használata

![CSS sprite példakép](https://blog.fps.hu/content/images/2016/01/sprite.jpg)

A http kérések számának csökkentése indokolja a sprite-ok használatát is. Arról van szó, hogy az állandó képi elemeket (ikonok, hátterek, egyéb apró grafikák) egyetlen képre helyezed és CSS-ben használod úgy, hogy a háttér pozícióját állítod. Sok esetben nem olyan egyszerű ezt megvalósítani, akkor a legkézenfekvőbb, ha fix szélességgel és magassággal rendelkezik a design elem, ellenben egy változó szélességű elem végére helyezendő kis ikon esetében már trükközni kell.

Nézd csak a kis képet, melyet egy munkám során használtam, ott a kis lefele mutató nyíl erre ad példát. (megjegyzendő, hogy CSS3-ban már meg lehet adni a háttérkép szélességét és magasságát is, de sajnos jelenleg még nem támogatják általánosan a browserek). [Olvass bővebben a CSS Sprite-okról](http://css-tricks.com/css-sprites/?ref=blog.fps.hu).

#### Képek optimalizálása

A webes alkalmazásoknál a képeket, grafikai elemeket jpeg, png és gif formátumokban használjuk. Fontos arra ügyelned, hogy ezek fájl mérete a lehető legkisebb legyen, ezért a következőkre kell figyelned:

- ha transzparens képre van szükséged, a png a legjobb választás, viszont ha az adott grafikának nincs alfa transzparenciája és kevesebb, mint 254 színt használ, akkor a gif formátum kisebb fájl méretet eredményez
- a fotók, bonyolultabb képi elemek mindig jpeg formátumban lesznek a legkisebb fájlméretűek. A jpeg veszteséges tömörítést használ, így állítható a tömörítés mértéke, amit addig fokozz, amíg a kép nem lesz „rágott” (jpeg artifacts)
- akármekkora a kép, ami pár színből áll, gif formátumban lesz a legkisebb. Ráadásul a gif dithering lehetőségével nem észrevehető a színek egymásba keverése (noise – zajjal), így sokszor előfordul, hogy kisebb lesz a kép fájl mérete, mintha jpeg-ben mentenéd. Mindig próbáld meg a gif formátumot, hacsak nincs gradiens (színátmenet) a képen, akkor biztos nem lesz jó.

#### Külső CSS, JavaScript (nem inline)

Külső CSS fájlokat használj a link html elemmel, ezzel eléred, hogy mikor a böngésződ feldolgozza a tartalmat, már előformázott formában jelenítse meg azt, így a felhasználó számára hamarabb jelenik meg a végleges eredmény. Ha a html kódban helyezel el CSS blokkokat (style), illetve az egyes html tagokra adsz ki helyben CSS utasításokat, lelassítod a megjelenítést, mégpedig a sok felülbírálás miatt és mert a böngészőnek mindig újra kell „rajzolnia” az érintett elemeket. A felhasználók a fehér, üres képernyőt bámulják majd és lelépnek.

#### JavaScript fájlok kerüljenek az oldal aljára

Ha az oldal aljára teszed ezeket a hivatkozásokat, a felhasználók már látják a tartalmat, mikor a böngésző betölti a JavaScripteket. Tudom, sajnos sokszor ez nem valósítható meg. Sokszor látom, hogy a jQuery-hez rengeteg plugin be van töltve és a felét sem használja az oldal, csak az legyen, ami feltétlen szükséges.

#### Minimalizált és egybevont CSS és JavaScript kódok

A http requestek számának csökkentése indokolja, hogy minél kevesebb CSS és JavaScript hivatkozás legyen a forrásban, ezért érdemes a CSS, JS fájljaid egyetlen fájlba tenni (és nem @importtal a CSS-en belül, mert az is külön http request lesz). Ha már egy fájlod van, akkor használj minimalizáló scripteket, vagy a keretrendszeredbe építs be ilyet, vagy vedd igénybe a számos online megoldás valamelyikét (az elterjedt keretrendszerekhez, blog motorokhoz találsz plugin formájában). Jelentősen csökkentheted a letöltendő CSS, JS fájl(ok) méretét.

#### 301-es átirányításokat ne alkalmazz

Nyilvánvaló, hogy a 301-es átirányítások lassítják a működést, persze SEO miatt nagyon sokszor használják és kell is alkalmazni, viszont kerülni kell, amennyire ez lehetséges.

#### Gzip beállítása szerver oldalon

A web szerveren be kell állítani, hogy gzip-el tömörítse a böngészőnek elküldött tartalmakat. Minden böngésző képes már lekezelni a gzippelt állományokat. Ezáltal a letöltési időt lehet csökkenteni, igaz, kliens oldalon a kitömörítés időt vesz el, de a kettőt összegezve pozitív lesz az egyenleg.

![elmosódott ujjak fotó](https://blog.fps.hu/content/images/2016/01/tumblr_m8vfak9WIt1r105v8--1-.jpg)

#### Egyéb oldal betöltést lassító elemek

- Social media gombok (Facebook like, google +1, megosztás gombok, stb.) – csak azt használd, amire feltétlen szükséged van
- Hirdetés kezelő rendszerek JavaScriptjei – nincs mit tenni, de jelentősen lassíthatja a megjelenítést az inline JS miatt
- Analitikai rendszerek JS kódja(i) – lehetőleg egy mellett tedd le a voksod, több rendszert ne használj
- Flash és/vagy Java használat – tűzre velük :)

### Eszközök, melyek segítenek a problémák felderítésében

- [Google PageSpeed](https://developers.google.com/pagespeed/?ref=blog.fps.hu)
- [YSlow](http://yslow.org/?ref=blog.fps.hu)
- [pingdom TOOLS](http://tools.pingdom.com/fpt/?ref=blog.fps.hu)
- [JavaScript minify](http://www.minifyjavascript.com/?ref=blog.fps.hu)
- [CSS minify](http://www.minifycss.com/css-compressor/?ref=blog.fps.hu)
- [CSS Sprite Generator](http://spritegen.website-performance.org/?ref=blog.fps.hu)
- [Kép optimalizáló](http://www.smushit.com/ysmush.it/?ref=blog.fps.hu)
### Lokális hirdetés – egy lépéssel a konkurencia előtt
URL: https://blog.fps.hu/lokalis-hirdetes-targetalas/
Last updated: 2026-07-17T08:54:46.000Z
A mobil eszközök rohamos terjedésével egyre nyilvánvalóbbá válik, hogy a lokális keresés mellett a lokális hirdetések is fontos tényezővé válnak a piacon. A lokális hirdetések rendkívül hatékonyak, hiszen egészen pontos célzást tesz lehetővé, így nagyobb konverziót lehet elérni egy-egy hirdetési kampánnyal. Lássuk, milyen eszközök állnak rendelkezésünkre.

Kezdjük az elején: mi is az a lokális hirdetés? Akkor beszélünk lokális hirdetésről, amikor úgy targetáljuk a hirdetéseket, hogy egy földrajzilag jól körülhatárolható területen tartózkodók az üzenetünk „címzettjei”.

Keresőmotorok, helyi linkgyűjtemények, mobil web. Már nem számít, éppen hol tartózkodsz, az emberek 98 százaléka a keresőkhöz fordul, ha valamilyen információra van szüksége.

A kereső az első lépés ahhoz, hogy az emberek megtalálják a vállalkozásod a környezetükben. A lokális keresések száma egyre nő, mivel egyre több mobil eszköz van kéznél, amivel a felhasználók helyi termékeket és szolgáltatásokat keresnek.

A Google-ben minden ötödik keresés valamilyen lokális dologra irányul. A Google a folyamatos [keresési algoritmus változtatásaival](https://blog.fps.hu/google-pingvin-panda-seo/) arra ösztönzi a weboldal tulajdonosokat, hogy minőségi tartalommal, jó SEO-val olyan weboldalakat alakítsanak ki, melyekkel a keresési találatok élére kerülhessenek.

Vannak azonban olyan esetek, amikor ezt nem tudod kivitelezni:

- túl nagy a verseny a piacodon
- technikailag nem megfelelő az oldalad
- induló vállalkozásod van, és még teljesen új az oldalad
- az oldalad megfelelő, de növelni szeretnéd a bevételeid, stb.

Ilyenkor kell elővenni a marketing eszköztárat, és felmérni a lehetőségeket. Vannak ingyenes és fizetős lehetőségek, vegyük sorra őket. 

### Google+ Local

![Google+ local ikon](https://blog.fps.hu/content/images/2016/01/googleplus.jpg)

Régebben ez a szolgáltatás a Google Maps-ben volt elérhető. Az alapinformációkon kívül (név, cím, telefonszám, weboldal cím, email cím, stb.) a Google beépített útvonaltervezője is megjelenik, hogy a leendő ügyfeleid könnyebben megtaláljanak, fotókat tölthetsz fel, a látogatók értékelhetik és véleményezhetik az általad nyújtott szolgáltatás minőségét. Ez még egy viszonylag új dolog, érdemes egy kis időt fordítani rá és megadni az alapadatokat, ugyanis a Google előnyben részesíti azokat az oldalakat, akik többféle szolgáltatását is igénybe veszik, mint pl. az Adwords. Ez bárki számára elérhető ingyenes eszköz, elsősorban azoknak javasolt, akiknek van fizikailag is elérhető üzlete. [Bővebben a Google+ Localról](http://www.google.com/intl/hu%5FALL/+/learnmore/local/?ref=blog.fps.hu). (Egyébként itt jegyzem meg, hogy a többi keresőnek is van ilyen szolgáltatása, pl. [Yahoo Local](http://local.yahoo.com/?ref=blog.fps.hu), [Bing Places](http://www.bing.com/businessportal/?ref=blog.fps.hu), ezekre akkor érdemes regisztrálnod, ha többnyelvű az oldalad, illetve nemzetközi szolgáltatást nyújtasz, szerencsére ezek is ingyenesen elérhetőek)

### Helyi oldalak, hírportálok

Kereshetsz helyi és regionális megjelenési lehetőségeket. Legyen az egy helyi vonatkozású linkgyűjtemény, vagy helyi hírportál szponzorált megjelenési lehetősége. A célcsoportod ezeken a helyeken gyakran megfordul, így jó eséllyel találkozik az oldalad linkjével. A linkgyűjteménybe való bekerülés általában ingyenes, sok helyen elég egy egyszerű regisztráció, és már ajánlhatod is az oldalad.

### Google Adwords

![Google Adwords logó](https://blog.fps.hu/content/images/2016/01/googleadwords.jpg)

Az [Adwords](http://adwords.google.com/?ref=blog.fps.hu) az egyik legjobb hirdetési mód, ugyanis szinte tökéletesen testre szabható a lokális keresésekhez. Mobil eszközök esetében is elérhető mind a kereső hálózaton, mind a tartalmi hálózaton történő hirdetés.

A desktop keresések piacán nagy a verseny egy-egy népszerű kulcsszó esetén. Mivel a mobil hirdetések még csak gyerekcipőben járnak, a versenytársaid nagy része még nem használja ezt a lehetőséget, így lépéselőnybe kerülhetsz velük szemben. **Mobil hirdetési kampány létrehozásával fokozhatod a láthatóságodat alacsonyabb CPC mellett.**

Néhány ötlet, hogyan készíts konvertáló kampányokat:

- hozz létre külön kampányokat a desktopot használóknak, az iOS és Android operációs rendszert használóknak, valamint a normál mobiltelefonon megjelenő hirdetésekhez, így könnyebben tudod mérni a teljesítményt, valamint rendszerre szabott kulcsszavakkal, hirdetésekkel is tudod fokozni az eredményességet
- használj külön kulcsszavakat: a mobil eszközön keresők rendszerint kevesebb kulcsszót adnak meg a kereséshez, mint desktopon, itt az általánosabb kulcsszavakkal is jó eredményeket lehet elérni
- próbálj minél frappánsabban, ütősebben fogalmazni, és tartsd szem előtt a call-to-action irányelvet, ugyanis a hirdetés szövege nagymértékben képes befolyásolni az átkattintást
- próbálj ott lenni, ahol a célcsoportod: a mobil felhasználók nemcsak keresnek, hanem böngésznek, mobil alkalmazásokat használnak, így próbáld ki a tartalmi hálózaton a kontextus szerinti célzást, valamint érdemes kipróbálnod a képes hirdetést is (kontextus szerinti célzással tudsz megjelenni pl. Youtube videókon)

### Social Media – Facebook

![Facebook logó](https://blog.fps.hu/content/images/2016/01/facebook.jpg)

Lokális hirdetések szempontjából a Facebook lehet érdekes számodra, így most csak erről írok pár gondolatot. Az Adwords-höz hasonlóan itt is nagyon jól lehet célozni a hirdetéseket, viszont többféle és másféle lehetőségek vannak, melyeket használhatsz. Alapvető különbség, hogy itt nem kulcsszavak alapján jelennek meg a hirdetések, hanem a profil oldalak, hírfolyamok mellett. Nézzük a lehetőségeket:

**Rajongói oldal:** létrehozhatsz a termékednek/szolgáltatásodnak/vállalkozásodnak egy külön oldalt, ahová össze tudod gyűjteni az érdeklődőket, illetve a potenciális célközönséget. Kommunikálhatsz velük, kikérheted a véleményüket, aktivizálhatod őket egy-egy játékkal, stb. A rajongói oldal létrehozása ingyenes. A lényeg, hogy ha már elkezded csinálni, akkor rendszeres időközönként posztolj az oldalon, folyamatosan tartsd fenn a rajongóid érdeklődését.

**Hirdetések:** Az árképzésben hasonló módon működik, mint az Adwords, CPC alapon és CPM alapon is futtathatod a hirdetéseket. Maguk a hirdetések úgy épülnek fel, hogy 25 karakter a cím, 90 karakter lehet maga a hirdetés szövege, és egy pici bélyegkép is társul a szöveg mellé. A címet csak akkor tudod egyedire venni, ha külső weboldalra hirdetsz. A rajongói oldalra mutató hirdetéseknél a cím adott, az oldalad neve. Landing page-nek megadhatod a rajongói oldaladat, de akár a weboldaladat is.

Célzás tekintetében itt a legszélesebb a paletta:

- kor szerint
- nem szerint
- családi állapot szerint
- földrajzi elhelyezkedés szerint
- beszélt nyelvek szerint
- érdeklődési kör szerint (itt tucatnyi lehetőség közül választhatunk)
- iskolai végzettség szerint, stb.

A megfelelő célcsoport beállításakor információt kapsz arról, hogy az eddig megadott paraméterek alapján hány emberhez fog eljutni a hirdetésed, akik nagy valószínűséggel konverziót is fognak hozni a konyhára.

Ezen kívül vannak még különböző Sponsored Story hirdetések, melyekkel egy-egy bejegyzést is kiemelhetünk illetve hirdethetünk.

A Facebook mobil felületei is napról-napra fejlődnek, már az okostelefonokon is megjelennek a hirdetések, felbontástól függően vagy ugyanúgy, mint a desktop verziónál, vagy a hírfolyamba csempészve.

A mobil SEO és lokális hirdetések területén még rengeteg lehetőség van, érdemes kipróbálnod a különböző csatornákat, és a leghatékonyabbat használni, így lépéselőnybe kerülhetsz a versenytársakkal szemben, ami azért nem egy rossz dolog.
### Lokális keresés – kézzelfogható jövő
URL: https://blog.fps.hu/lokalis-kereses-seo-mobil/
Last updated: 2026-07-17T08:54:56.000Z
Nem kell jövendőmondónak lenni ahhoz, amit már látunk: a weboldalak forgalma egyre inkább a mobil eszközökről érkezik. Ez azt jelenti, hogy szép lassan (persze nem egyik napról a másikra) megváltozik az internetes keresések módja, egyre inkább eltolódik a lokális keresések irányába. Annak érdekében, hogy ki tudjuk használni ezeket a lehetőségeket, íme néhány tipp, amit mindenképp érdemes átgondolnunk.

### Miért fontos a Mobil SEO?

Gondolkozzunk egy picit a kereső szempontjából. Amikor választ keresünk arra, hogy hol található élelmiszerbolt a közelben, vagy hogyan tüntethetjük el a vörösbor foltot az abroszról, akkor egy problémára keressük a választ, illetve választ várunk egy kulcsszavakkal megfogalmazott kérdésünkre. A kereső végigpörgeti a lehetséges okokat, ami miatt ezekre a kulcsszavakra keresünk. Vajon egy helyi szolgáltatót szeretnénk találni? Valamilyen mobil eszközről érkezett a kérés? Ha a keresőmotor igen választ ad a fenti két kérdésekre, akkor ezeknek a paramétereknek megfelelően ad találati listát a felhasználónak. A fenti példánál maradva az élelmiszerbolt esetén beazonosítja a tartózkodási helyünket, és ennek megfelelően alakítja ki a találati listát.

![Mobilon Google map a találati lista elején képernyőkép](https://blog.fps.hu/content/images/2016/01/miskolcuvegezes.jpg)

A [Nielsen piackutató cég 2012-es elemzése](http://blog.nielsen.com/nielsenwire/consumer/more-us-consumers-choosing-smartphones-as-apple-closes-the-gap-on-android/?ref=blog.fps.hu) szerint az Egyesült Államokban a mobiltelefon tulajdonosok 41%-a használ okostelefont, akiknek így lehetőségük van arra, hogy ezen eszközön keresztül csatlakozzanak a világhálóhoz. Ennek a bázisnak a 61%-a használja keresésre is a mobil eszközüket. És ez a szám tovább fog növekedni, ahogy ezen eszközök használata beépül a hétköznapi életbe. És ez már az a kritikus tömeg, ahol a mobil site alapvető fontosságú. A mobil oldal az érintőképernyős okostelefonra és tabletre van optimalizálva, így ezen eszközöket használó felhasználók is megkapják azt az élményt, amelyhez a desktopon már hozzászoktak. Tehát ha még nincs mobilra optimalizált weboldalunk, épp itt az ideje készíteni egyet! (Az alábbi infografikán láthatjuk, [hirdetés szempontjából is mekkora potenciál van a lokális keresésben](http://searchengineland.com/infographic-local-search-evolved-96929?ref=blog.fps.hu), de erről majd egy külön posztban fogok írni)

[![Local Search Evolved infografika](https://blog.fps.hu/content/images/2016/01/evolved.jpg)](http://searchengineland.com/infographic-local-search-evolved-96929?ref=blog.fps.hu)

### Mire figyeljünk egy mobil site kialakításánál?

- az alap SEO beállításokat ugyanúgy alkalmazzuk, mint websiteok esetében (H-tagok, meta adatok megadása, hiteles és megbízható tartalom, sitemap stb.)
- a mobil eszköz képernyőfelbontásához igazítsuk a designt (ez lehet responsive web design, külön mobil design stb.)
- figyeljünk az URL használatára: ha külön mobil verziós tartalmakat állítunk elő, használjuk a rel=canonical tag-et, így a keresők nem veszik duplikációnak az azonos tartalmakat
- néha különböznek a kulcsszavak, néha nem: mobil site létrehozásakor mindig meg kell vizsgálni a kulcsszavakat, keresési trend elemzést végezni , hogy lássuk, mely eszközről milyen szavakra/kifejezésekre keresnek a felhasználók. Ha egyeznek a kulcsszavak, nincs teendőnk, ha különböznek, ezeknek megfelelően kell optimalizálni az oldalt
- használjuk a Google Analytics-et a mobil site esetén is: így pontos képet kaphatunk a felhasználói szokásokról

A Google egyébként nemrégiben [közzétette blogján a hivatalos irányelveit a Mobil SEO kapcsán](http://googlewebmastercentral.blogspot.hu/2012/06/recommendations-for-building-smartphone.html?ref=blog.fps.hu).

### Tedd kézzelfoghatóvá, és add a kezükbe!

A mobil keresés és a lokális keresés az új SEO csapásirány. Amellett, hogy az alapvető SEO paramétereket beállítottuk, figyeljünk arra is, hogy lokális keresésre is optimalizáljuk az oldalt (kivéve, ha egyáltalán nincs lokális vonatkozása az oldalunknak). Emlékezzünk vissza: az Egyesült Államokban az okostelefon tulajdonosok 61 százaléka használja lokális keresésre az eszközüket. Egy kis számolással hamar rádöbbenhetünk, hogy ez mintegy 60 millió okostelefon használó, akik lokális kereséseket is végeznek. (Egyébként egy nagyon jó kis infografika mutatja be [az Egyesült Államok lokális keresési szokásait](http://www.localeze.com/files/Images/infographic%5FLocaleze%5FSearch%5FStudy.jpg?ref=blog.fps.hu))

[![Local search: When a consumer searches online for information that is refined by geography. felirat](https://blog.fps.hu/content/images/2016/01/localsearch.jpg)](http://www.localeze.com/files/Images/infographic%5FLocaleze%5FSearch%5FStudy.jpg?ref=blog.fps.hu)

Íme néhány szempont, melyek szükségesek ahhoz, hogy a mobil site-unk lokális keresésre is optimalizálva legyen:

- Készítsünk lokális profilt! Ha nem vagyunk jelen a Google+ Local-on (korábban Google Places), a Yahoo Local-on, a Bing Place-en, a Foursquare-en, stb., akkor kihagyod a legjobb lokális keresőoptimalizálási taktikákat.
- Keressük meg a helyi és regionális lehetőségeket. Ezek az oldalak az egyik legjobb módjai annak, hogy a keresők felismerjék a lokális jelentőségünket, és ezáltal geo-specifikus kulcsszavakra előrébb sorolja az oldalunk a találati listán. Ezen oldalak közé tartoznak a helyi hírportálok, helyi linkgyűjtemények, helyi szervezetek oldalai stb.
- Ellenőrizzük, hogy a cím és a kapcsolat felvételi adatok mind a felhasználók, mind a keresők számára elérhetőek legyenek. Sokszor a felhasználók eljutnak egy oldalra, és pont azokat az alapvető információkat nem találják meg, ami miatt keresték a site-ot (név, cím, telefonszám, nyitva tartás, stb.) Ezen kívül, ha a keresők sem találják meg ezeket az információkat, akkor negatívan fogja megítélni az oldalt lokális SEO szempontjából. Hogyan tehetjük elérhetővé a keresőnek a lokális adatokat? A Google a rich snippets használatát javasolja, melyekről részletesen [a Google webmestereknek szóló oldalán találunk leírást](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=99170&ref=blog.fps.hu "Rich Snippets").
- Végezzünk lokális versenytárs elemzést! A legjobb módja annak, hogy megismerjük a helyi konkurenciát, megnézzük, ők mire jók, és próbálunk náluk még jobbak lenni, hogy a keresők a mi oldalunkat preferálják jobban. Ne feledjük: „a jó művészek másolnak, a nagy művészek lopnak”.

Ha jól kombináljuk a mobil és a lokális SEO eszközöket, akkor garantált a helyünk a keresési találatok élén. Gondoljuk át a céljainkat, és ennek megfelelően válasszuk ki a stratégiánkat a mobil site elkészítéséhez. ([Egy korábbi posztunkban áttekintettük a lehetőségeket.](https://blog.fps.hu/mobil-seo/))  
A Mobil SEO eredmények sem jönnek egyik napról a másikra, és itt is ugyanolyan fontos a folyamatos nyomon követés, hogy szükség esetén időben be tudjunk avatkozni. Bízunk benne, hogy sikerült kedvet csinálnunk a mobil site-okhoz, és hazánkban is egyre több pozitív példával találkozhatunk a közeljövőben.
### Weboldalak és webalkalmazások funkcionális tesztélese
URL: https://blog.fps.hu/webalkalmazasok-funkcionalis-tesztelese/
Last updated: 2026-07-17T08:55:04.000Z
Webes fejlesztésekkor elkerülhetetlen a már kész funkciók, folyamatok tesztelése, a hibák kiküszöbölése, valamint a működés finomhangolása. Legyen ez egy egyszerű regisztrációs vagy bejelentkezési űrlap, vagy akár egy webáruház rendelési folyamata. Egy-egy ilyen tesztelés elég időigényes tud lenni (emiatt sokan nyűgnek is érzik), gondoljunk csak bele, egy rendelés esetén ki kell keresnünk a terméket, a kosárba helyezni, majd a megrendelés űrlapot kitölteni, elküldeni (név, email cím, telefonszám, szállítási és fizetési mód, illetve a számlázási és fizetési cím megadása), így hasznos lenne, ha ezt automatizálni tudnánk.

### A Selenium

Erre nyújt megoldást a Selenium nevű eszköz, amely már szinte a weboldalak funkcionális tesztelésének de facto szabványává vált.  
Többféleképpen használhatjuk, létezik szerver oldali változata, illetve különböző programnyelvekhez kliens programkönyvtárak, ezen kívül készítettek egy Firefox kiterjesztést, mely a böngészőnkbe épülve segít nekünk bizonyos folyamatok, események rögzítésében, majd később bármikori megismétlésében.  
Az utóbbiról fogok most írni, egy gyakorlati példán keresztül bemutatva a használatát.

### Telepítés

A [Selenium hivatalos oldaláról](http://seleniumhq.org/?ref=blog.fps.hu) tudjuk letölteni magát a [Firefox kiterjesztést](http://release.seleniumhq.org/selenium-ide/1.8.1/selenium-ide-1.8.1.xpi?ref=blog.fps.hu). Érdemes átböngésznünk a weboldalt, egy elég részletes dokumentáció található róla, ebben a bejegyzésben csak az elinduláshoz szükséges információkat fogjuk kitárgyalni.  
Letöltés után a Firefox megkérdezi, hogy szeretnénk-e telepíteni a bővítményt, ennek elfogadása, majd a böngésző újraindítása után használatba is vehetjük.

![Firefox plugin telepítés képernyőkép](https://blog.fps.hu/content/images/2016/01/szoftvertelepites.jpg)

### Egy példa: webáruház rendelési folyamata

Az eszköz használatát egy általunk fejlesztett webáruházon keresztül fogom bemutatni, laptopot fogunk rendelni.  
Első lépésként nyissuk meg a Firefox-ot, és írjuk be a weboldalunk címét. Ezek után ha kiválasztjuk az Eszközök/Selenium IDE menüpontot, egy új ablakban meg kell nyíljon a Selenium.

![Selenium felülete képernyőkép](https://blog.fps.hu/content/images/2016/01/seleniumide.jpg)

**Az ablak főbb részei**

- A fenti részben találhatók a teszt rögzítéséhez illetve visszajátszásához kapcsolódó gombok. A jobb oldalt található gombra kattintva tudunk egy tesztesetet rögzíteni, a bal oldalt található zöld gombok segítségével pedig visszajátszani, szüneteltetni, léptetni, illetve szabályozni a teszt sebességét.
- Bal oldalt találhatóak a teszteseteink felsorolása, alattuk pedig a sikeresen és sikertelenül lefutott tesztek száma.
- A középső legnagyobb helyet elfoglaló részen látható, hogy az adott tesztesetekben milyen műveleteket végzünk el.
- Az alsó sávban láthatjuk a naplóbejegyzéseket, illetve információkat kaphatunk bizonyos műveletekről, felületi elemről.

Miután megismerkedtünk az ablakkal, térjünk is rá a használatára. Én a példában a következőket fogom elvégezni:

- keresek egy notebookot
- a kosárba helyezem
- továbbnavigálok a megrendelés űrlapra
- a megrendelés űrlap mezőinek kitöltése utána elküldöm a megrendelésem

![Acer shop vizsgálata Seleniummal képernyőkép](https://blog.fps.hu/content/images/2016/01/seleniumidedevelop.jpg)

Ezt a folyamatot végigcsinálni nekem **7 percembe került**, a képen jól látszik, ahogy a Selenium rögzíti a tevékenységemet, majd listázza az ablak középső részén.  
Ha visszatérünk a weboldalunk kiinduló állapotába, a „Play” gomb segítségével futtathatjuk a tesztünket, ami **így fél perc alatt kész**.  
A teszthez további parancsokat is adhatunk kézzel, ezekről részletesen írnak a projekt dokumentációjában, leellenőrizhetük például bizonyos HTML elemek meglétét, az oldal címét, szövegeket, kattintást, szöveg gépelését emulálhatjuk.

### Összegzés

Ahogy a példából is láthatjuk, ezt a rendelési folyamatot végigcsinálni 7 percig tartott, és egy fejlesztés folyamán ezt legalább 20-30 alkalommal megismételjük. Ha számolunk egy kicsit, legalább 3 és fél órát töltünk el gombok nyomkodásával és űrlapmezők kitöltésével. Ez nem csak hogy fárasztó és időigényes, de könnyen belefásul az ember, akarva-akaratlanul, észrevétlenül, és ennek következtében kijavítatlanul hagyva hibákat.  
Érdemes tehát minden webfejlesztőnek vagy tesztelőnek feltelepítenie és egyszer kipróbálnia, hogy kiderüljön, hogyan tudja a munkafolyamataiba integrálni, illetve miként tudja hatékonyabbá tenni a tesztelés folyamatát.

### További cikkek, linkek a témában

- [http://seleniumhq.org/](http://seleniumhq.org/?ref=blog.fps.hu)
- [http://seleniumhq.org/docs/](http://seleniumhq.org/docs/?ref=blog.fps.hu)
- [http://jroller.com/selenium/](http://jroller.com/selenium/?ref=blog.fps.hu)
- [http://www.slideshare.net/agoucher/selenium-144336](http://www.slideshare.net/agoucher/selenium-144336?ref=blog.fps.hu)
### Konverziónövelés – acer.shop.hu esettanulmány
URL: https://blog.fps.hu/konverzionoveles-ux-acer/
Last updated: 2026-07-17T08:55:12.000Z
Többen kérték, hogy írjam meg blog posztban az [Evolution konferencián](https://www.evolution.hu/?ref=blog.fps.hu) elhangzott előadásom anyagát és persze rakjam ki a prezentációt is, ami a magyarországi hivatalos acer márkaboltok webshopjának konverziónöveléséről szól. Tessék.

### Probléma

Az [acer.shop.hu](http://www.laptop-notebook-netbook.hu/?ref=blog.fps.hu) tulajdonosa azzal keresett meg minket, hogy szeretné növelni a vásárlások számát, nagyobb bevételt szeretne realizálni a webshopból, továbbá az acer éppen frissítette logóját (színét, formáját), így a felülethez is hozzá kellett nyúlni. Nem volt egyszerű a feladat, mert a korábbi shop nagyon szépen teljesített.

### Tervezés

A projekt esetében szerencsénk volt, ugyanis a korábbi változatot is mi fejlesztettük, így Google Analytics és clickheat (heatmap) is el volt helyezve a kódban, melyeket elemezve jutottam hasznos következtetésekre. Ezek mellett a háttér adatbázist is vizsgáltam. Kiragadok néhány fontosabb következtetést:

*a korábbi oldalon*

- lehetett több számlázási, szállítási címet rögzíteni. Az adatbázisból SQL lekérdezésekkel kiderült, hogy a felhasználók kevesebb, mint 1%-a használta ezt a lehetőséget, így ennek megszüntetése a „felületi zaj” csökkentése miatt indokolt volt
- a termék kosárba helyezésekor jobb oldalt egy „dobozban” gyűjtötte a kosár termékeit, majd az ebben a blokkban található gomb segítségével lehetett a kosár oldalra jutni. Szintén az adatbázist vizsgálva derült ki, hogy a felhasználók több, mint 80%-a egyetlen terméket vásárol. Ebből egyenesen következett az, hogy a termék kosárba helyezésekor a felhasználót azonnal a kosár oldalra navigáljuk.
- a vásárlási folyamat 5 lépcsőre bontott volt és a Google Analytics-ben beállított cél csatorna alapján jól látszott, hogy milyen sokan hagyják el menet közben a folyamatot. Lehetett volna a csatorna egyes lépéseit optimalizálni, de miután semmi nem indokolta a sok lépést, inkább az egyszerűsítés mellett döntöttem, azaz kosár oldalról egyetlen megrendelés oldal, majd sikeres vásárlás után a köszönő oldal.
- szintén az Analytics adataira és a hőtérképekre támaszkodva szüntettünk meg funkciókat, tartalmakat. Jó példa erre a Női termék kategória, mely narancs színnel kiemelt volt és ennek ellenére gyakorlatilag senki sem klikkelte.

### Sexy Design

Don Normantől tudjuk, az attraktív dolgok jobban működnek ([olvasd el korábbi írásom](https://blog.fps.hu/miert-kell-az-esztetikus-design/), ahol bővebben kifejtettem miért van ez így) és mert a grafikához egyébként is hozzá kellett nyúlni, végeztünk egy egyszerű felmérést a korábbi vásárlókkal. Megkérdeztük őket, hogy 1-10-es skálán mennyire értékelik a designt. Az eredmény 4/10 lett, ami finoman szólva nem mondható jónak, így a teljes redesign mellett döntöttünk az ügyféllel közösen. Természetesen még fejlesztés előtt ismét felmértük a vásárlók véleményét, ami ezúttal a kielégítő 8/10-es eredményt hozta.

![korábbi és az új acer shop felülete kéernyőképek](https://blog.fps.hu/content/images/2016/01/acershop-regi-uj.jpg)

### Bizalomépítés

Egy e-commerce site-nál (is) különösen fontos a bizalom keltése a látogatókban. Esetünkben az alábbi elemeket alkalmaztuk:

- sexy design
- fizikailag létező üzletek kiemelése – nagyobb bizalommal vásárolnak az olyan webshopokban, melyekhez kötődik egy üzlet is, ahova betérhetünk bármikor.
- telefonos ügyfélszolgálat – fontos kiemelni a telefonszámot jól láthatóan, különösen a kosár és a vásárlási folyamat oldalain, mely a biztonság érzetét kelti. Ha gondom, kérdésem van, telefonálhatok és választ, megoldást kaphatok. Sajnos nagyon sok a bizalmatlan ember, akik eljutnak a kosárig, de a rendelést már inkább telefonon keresztül adják le. Ha nincs ott kiemelten a szám, akkor kilép és elveszíted a vásárlót. (a kosár és megrendelés oldalakra Gyakori kérdéseket és válaszokat is helyeztünk, hogy kevesebb legyen a telefonálók száma)
- plecsnik, logók – miután az acer.shop.hu-n van bankkártyás fizetés, a bank által egyébként is megkívánt logókat érdemes jól látható helyre tenni. A bizalomépítésben nagy szerepe van a különböző bankok, fizetési megoldásokat biztosító szervezetek (mastercard, visa) logóinak. Ha ezek a szervezetek adták a nevüket a web shophoz, akkor nyugodtan vásárolhatok. Ha titkosított csatornát használ az oldal (SSL), akkor a tanúsítványt kibocsájtó szervezet logóját is fontos kihelyezni. Gyakorlatilag minden plecsni növeli a vásárló bizalmát. Az acer webshopnál csináltattam a grafikussal egy saját plecsnit, 100% Elégedettségi Garancia néven, melyre húzva az egeret, tooltipként bővebb információt kap a felhasználó, az elállástól kezdve a szakértői segítségig. A posztban később találsz egy AB tesztet is ennek a plecsninek a tényleges hatásáról.
- az oldalon külön oldalak foglalkoznak az elállás, a garancia, a szállítás témájával.
- kapcsolat oldal alapos kidolgozása – az Analytics adataiból kiderül és ez igaz gyakorlatilag mindegyik web shopra, hogy a kapcsolat oldal az egyik leglátogatottabb. Vásárlás előtt a felhasználók nagy hányada megnézi a kapcsolat oldalt, biztos akar lenni abban, hogy nem fogják átverni. Ezzel az oldallal külön foglalkoztunk, feltüntettünk minden céges adatot, az adószámtól kezdve a cégjegyzékszámig, a nyitvatartástól az ügyvezető fotójáig. Tudd, hogy egyre több a tudatos vásárló, aki még az adószám alapján is leellenőrzi a céget és ha eltérést talál, távozik a boltodból. Az ügyvezető fotója, névvel is a bizalomépítés fontos része.

### Sebességoptimalizálás

Az oldalak betöltési sebességének közvetlen hatása van a konverzióra (vásárlás). Ebben a témában hamarosan írok, legyen most annyi elég, hogy több kutatást végeztek már, ami ezt az állítást alátámasztja, példának okáért egy ilyen: mikor az [amazon.com betöltési ideje 100ms-al megnőtt, az eladások száma 1%-al csökkent](http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html?ref=blog.fps.hu). Józan paraszti ésszel gondolkozva: ki szeretne olyan alkalmazást használni, ami lassú és nehézkes? Nyilván senki.

![egy óra részlete fotó](https://blog.fps.hu/content/images/2016/01/clock.jpg)

Az acer.shop.hu-nál **+35%-os** gyorsulást realizáltunk (cache nélkül és cache-elt állapotban 10x mértük a fontosabb oldalak sebességét, azokat átlagoltuk az eredeti és az új változat esetében, így kaptuk az eredményt). Mit is csináltunk? Csak címszavakban:

- HTML5 lehetőségek kihasználása, különös tekintettel CSS3-ra
- CSS sprite-ok alkalmazása
- CSS, JavaScript bundle és minify
- web szerver hatékonyabb konfigurációja

### Csináld –> Teszteld –> Gondolkodj –> Csináld –> Teszteld –> és így tovább…

Már a wireframe-eket is, csakúgy mint a grafikát, majd az űrlapokat is teszteltük felhasználókkal. Ez esetben szerencsések voltunk, mert a célközönség az fps irodájában ült, így könnyen tudtunk felhasználói teszteket végezni. Amilyen hamar csak tudtuk ki is raktuk élesbe az oldalt, persze ezzel még korántsem végeztünk. A [mouseflow.com](http://mouseflow.com/?ref=blog.fps.hu) scriptjeit helyeztük el az oldalban, melynek segítségével hőtérképek készültek, illetve ez a nagyszerű eszköz rögzítette a felhasználók egér és oldalakon át történő mozgását is munkafolyamatonként (session). A heatmapeket, illetve a videókat visszanézve sok apró finomhangolást végeztünk még az oldalon. Érdemes megemlíteni a megrendelés oldal űrlapján a telefonszám mezőt, mely korábban két mezőből állt, körzetszám és szám. Ezzel a pontos formátumot szerettük volna erőltetni, de rá kellett döbbenni, hogy semmi értelme, ez inkább csak hátráltatta a felhasználókat, sőt, láttam olyat is, amikor emiatt lépett ki a látogató.

### A/B tesztek

A [google website optimizert](http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CGQQFjAA&url=http%3A%2F%2Fwww.google.com%2Fwebsiteoptimizer%2F&ei=pgDmT-CuFsTwsgae15SgAQ&usg=AFQjCNGzx1ADg0zzX-KGr%5F5-kg0iSguElg) használtuk sok A/B tesztre, melyek közül kettő látványos eredménnyel járót emelek ki.

1\. A kosár oldalon a továbblépésre szolgáló gomb alá elhelyeztünk egy rövid szöveget, ami leírja, hogy mi történik majd a következő lépésben. Ez **+33.03%-os** konverziót (a megrendelés oldalra lépés) eredményezett.

![Megrendelem gomb alá kiírva, hogy mi következik megnövelte 33,03%-kal a konverziót képernyőképek](https://blog.fps.hu/content/images/2016/01/acer-abtest.jpg)

2\. A megrendelés oldalon a megrendelést véglegesítem gombhoz elhelyeztük a 100% elégedettségi garancia plecsnit. (ezt később a kosárhoz is beraktuk egyébként hasonló eredménnyel) Ez a saját készítésű embléma **+59.01%-os** konverziót (köszönő oldalra lépés) hozott.

![100% garancia plecsni képernyőkép](https://blog.fps.hu/content/images/2016/01/feliratkozom-garancia.jpg)

### Eredmény

A teljes átalakítás **\~80–90%-os forgalomnövekedéssel** járt. A tervezési, átalakítási, fejlesztési költség közel **3 hónap alatt megtérült**. A felhasználók elégedettségét jól mutatja az arukereso.hu értékelése (jelen pillanatban 94.68%). Érdemes [átolvasnod a szöveges értékeléseke](http://www.arukereso.hu/stores/acershop-s50727/velemenyek.html?ref=blog.fps.hu)t, melyek alátámasztják a munkánk sikerét.
### Mobil SEO és a pitty-putty
URL: https://blog.fps.hu/mobil-seo/
Last updated: 2026-07-17T08:55:21.000Z
Mobil SEO. Mit is takar ez pontosan? Ez egy olyan témakör, ami megosztja még a SEO szakembereket is, nemhogy az egyszerű halandókat. Kell ezzel foglalkozni? Vagy elég, ha mobil barát weboldalt készítünk? Nagyon sok mítosz és legenda kering a köztudatban, ezeket próbáljuk most megerősíteni vagy cáfolni.

Az okostelefonok rohamos terjedésével egyre többen használják az internetet ezeken a készülékeken keresztül. Praktikus, mert mobil, mindig kéznél van, csak néhány mozdulat, és máris hozzájutunk a szükséges információkhoz, legyünk épp a boltban, ahol egy termékről szeretnék további infót, vagy kirándulunk éppen, és a környék nevezetességeiről szeretnénk tájékozódni. Legtöbbször tehát lokális keresésekre használjuk a mobilunkat.

[![Mobile Search In Your Backyard infografika](https://blog.fps.hu/content/images/2016/01/mobilesearch.jpg)](http://assets.econsultancy.com/images/0001/9957/MobileSearchinYourBackyardAnInfographic%5F4ef39d9a58d92.jpg?ref=blog.fps.hu)

### Mi a különbség a lokális és a mobil keresés között?

Mobil keresésről akkor beszélünk, ha valamilyen mobil eszköz segítségével keresünk. Lokális keresésről pedig akkor, amikor valamilyen helyspecifikus dologra keresünk. Itt olyan találati oldalakat várunk, melyek térképet és egyéb olyan szolgáltatásokat adnak, melyektől azonnali segítséget kapunk. A Google kijelentette, hogy külön mobil algoritmusok működnek a jobb mobil felhasználói élmény érdekében.

Ahhoz, hogy mi, mint weboldal tulajdonosok/üzemeltetők ki tudjuk szolgálni ezt az igényt, szükségünk van-e külön mobil verzióra vagy sem? Vegyük sorba, milyen lehetőségek közül választhatunk.

### 1\. A legjobb mobil SEO stratégia az, ha nincs mobil SEO stratégiánk

A [barackobama.com](http://www.barackobama.com/splash/are-you-in-c??ref=blog.fps.hu) egy nagyszerű példa arra, hogyan kell kezelni a mobil oldalakat (RWD). Ugyanazt az oldalt és design-t kínálja a mobil és a „hagyományos” látogatóknak is. Ugyanaz a megjelenés, ugyanaz az URL. Természetesen a stílusalap különböző, de ez minden. Az élmény ugyanaz!

![Obama oldala desktopon és mobilon képernyőképek](https://blog.fps.hu/content/images/2016/01/mac-phone.jpg)

Ezt a fajta design-t hívjuk responsive web designnak, amiről [egy korábbi posztunkban](https://blog.fps.hu/magyar-responsive-web-design/) már részletesen írtunk. A [Bing](http://www.bing.com/community/site%5Fblogs/b/webmaster/archive/2012/03/07/building-websites-optimized-for-all-platforms-desktop-mobile-etc.aspx?ref=blog.fps.hu) kora tavasszal, a [Google](http://googlewebmastercentral.blogspot.hu/2012/06/recommendations-for-building-smartphone.html?ref=blog.fps.hu) néhány hete jelentette be, hogy az egy URL-es megoldást támogatják és ajánlják, szemben az aldomaines és egyéb megoldásokkal. A Google még a responsive web design megvalósításához is segítséget nyújt a [Webmaster Central blogban](http://googlewebmastercentral.blogspot.hu/2012/04/responsive-design-harnessing-power-of.html?ref=blog.fps.hu). Így nem fő a fejünk a tartalomduplikálás és egyéb olyan dolgok miatt, melyek negatívan befolyásolják a SEO eredményeket. 

Mivel azonos az URL, egyetlen oldalt kell optimalizálni. Az összes keresőoptimalizálási munkát egyszer kell csak elvégeznünk, nincs szükség külön mobil SEO stratégiára.

De mi a helyzet akkor, ha az oldalunk nem alkalmas responsive web design használatára? 

### 2\. m.oldalamneve.hu

Vannak olyan típusú oldalak, pl. webshopok, amikor célszerű külön mobil oldalt készítenünk. SEO szempontból jön máris az első probléma: kétféle URL, azonos tartalommal. Természetesen nem szeretnénk saját magunkkal versenyezni a keresőkben, és van is erre megoldás. Ha már külön site-ot hoztunk létre, lehetőleg az m.oldalamneve.hu megoldást válasszuk. SEO szempontból nem nyújt semmilyen előnyt, de nemzetközileg ezt a megkülönböztetést használják a mobil oldalakra. Másik előnye, hogy minden URL-t meg tudunk tartani, csak az m. lesz a különbség. Ezzel is segíteni tudjuk a látogatóinkat az eligazodásban.

A canonical tag-nek köszönhetően kereséskor csak a „sima” URL-eket adja ki a találati listában, és megnyitáskor az adott eszköznek megfelelő oldalra dobja a felhasználót. Így ki is küszöböltük a duplikált tartalom problémát.

![html forráskód head része](https://blog.fps.hu/content/images/2016/01/code.jpg)

Itt kell még megemlítenünk a Google [Skip Redirect/Old Possum](http://insidesearch.blogspot.hu/2012/01/30-search-quality-highlights-with.html?ref=blog.fps.hu) megoldását, amely a gyorsabb mobil böngészést teszi lehetővé. Számos oldal használ átirányításokat az okostelefonokon való optimalizált megjelenés miatt. Ez a megoldás azt teszi lehetővé, ha mobil eszközről történik a keresés, a találat megjelenítésekor kikerüli ezeket az átirányításokat, így gyorsabban töltődik be a keresett oldal.

### 3\. Mobil eszközökre optimalizált site-ok

Hazánkban még picit messze állunk ettől a lehetőségtől, de az Egyesült Államokban már bontogatja szárnyát egy új irányvonal. A tartalmak kétféleképpen készülnek: egy mobil webes verzió, és egy desktop verzió. Mindkettő a saját platformjának megfelelően van kulcsszavazva, megszerkesztve. A [Google kulcsszóválasztó eszköze](https://adwords.google.com/o/Targeting/Explorer?%5F%5Fc=1000000000&%5F%5Fu=1000000000&ideaRequestType=KEYWORD%5FIDEAS&defaultView=2&ref=blog.fps.hu) már lehetőséget ad arra, hogy megnézzük, egy adott kulcsszóra mennyien keresnek mobil eszközről és mennyien asztali gépről. (a beállításoknál a legördülő menüben találjuk a mobil eszközöket) Így könnyebben választhatunk megfelelő kulcsszavakat, mobil fókuszált tartalmakat állíthatunk elő, és könnyebben ott lehetünk az első találati oldalon. 

Ha jól megszerkesztett (és SEO-zott) tartalmunk van, a látogatók szívesen osztják meg valamilyen közösségi csatornán keresztül. Ezzel számtalan, a tartalmunkra mutató linket generálunk, ami a lehető legjobb linképítési stratégia. És mint arról már szintén [írtunk korábban](https://blog.fps.hu/google-pingvin-panda-seo/), a Google Panda és Pingvin nagy hangsúlyt fektet a tartalmunkra mutató releváns linkekre, így ezek a megosztások is nagyban hozzájárulnak ahhoz, hogy az adott kulcsszóra a mi tartalmunk legyen az első pozícióban.

![notebookon két mobil letéve fejlesztés közben fotó](https://blog.fps.hu/content/images/2016/01/fejlesztes.jpg)

Az oldalon belüli URL-ek használatáról se feledkezzünk meg. Használjunk belső és külső linkeléseket is. A belső linkek a keresőbotok miatt fontosak, hogy minél teljesebben be tudja indexelni az oldalunkat. A kifelé mutató linkek pedig erősítik a tartalmi relevanciát, amennyiben a tartalmunkhoz témába vágó oldalra hivatkozunk. Amire nagyon figyeljünk oda: mindig működő oldalra linkeljünk csak, és ne vigyük túlzásba a linkelést, mert könnyen áteshetünk vele a ló másik oldalára, és még büntetést is kapunk a keresőktől.

Ha tovább szeretnénk növelni a mobil felhasználói élményt, készítsünk mobil sitemapet. Nem csak a felhasználóinknak segít az eligazodásban, de a keresők szempontjából is fontos.

### Ha többet akarsz

Ha valami igazán egyedi dolgot akarsz megjeleníteni, akkor nem mobil verzióra van szükséged, hanem mobil alkalmazásra. Itt tudsz használni multi-touch funkciókat, GPS és egyéb szolgáltatásokat, melyekkel olyan különleges és egyedi felhasználói élményt tudsz adni, melyre egy weboldal nem képes. Ugyan a mobil alkalmazás, mint olyan, nem SEO-zható, viszont reklámozhatod az oldaladon, linkelhetsz rá. Ugyanakkor a Google Playben vagy az App Store-ban a leírás és kulcsszavak részben lehetőség van a SEO-ra.

![Deszkatemplom Wiki oldal mobilon fotó](https://blog.fps.hu/content/images/2016/01/wiki-oldal-mobil-foto.jpg)

Ha nem tudod eldönteni, mire is van szükséged, mobil oldalra vagy alkalmazásra, [ebben a posztunkban](https://blog.fps.hu/mobil-web-vs-mobil-app/) összefoglaltuk az előnyöket és a hátrányokat.

**Ami még nagyon fontos!**  
Bármelyik irányba indulsz el, MINDIG mérd az eredményeket, figyeld a látogatóid tevékenységét. A Google Analyticsben már külön filterezés nélkül is látod a mobil adatokat, összehasonlíthatod a desktop-os adatokkal. Látod a mobil operációs rendszereket, böngészőket, készülék típusokat stb. Ha a mobil applikáció mellett döntesz, a Google Analytics for Mobile Apps SDK, illetve az Apple iTunes Connect segítségével mérheted az app teljesítményét.

### Hogy miért pitty-putty?

Csak. Mert jó.
### Magyar Responsive Web Design
URL: https://blog.fps.hu/magyar-responsive-web-design/
Last updated: 2026-07-17T08:55:32.000Z
Nekiestünk a magyar webnek, felvettük a kapcsolatot több webre fejlesztő ügynökséggel, hogy bemutassunk magyar responsive web design példákat.

### Mi a responsive web design, vagy RWD?

Adott a tartalom, melyhez külön stíluslapokat, stílus bejegyzéseket rendelve különböző felbontásokhoz igazodó elrendezéseket (layoutokat) hoz létre a fejlesztő csapat (CSS3 media queries). Jellemzően fluid (nyúlós) elrendezést alkalmaz (különösen a kisebb felbontások esetén pl. a mobil eszközöknél) és többnyire flexibilis képekkel operál (különböző méretek és a méret határokon belül méreteződnek) A lényege, hogy nem kell különálló web site-okat fejlesztened a különböző méretű kijelzővel és felbontással rendelkező eszközökre. [Olvasd el a WikiPedia ide vonatkozó szócikkét](http://en.wikipedia.org/wiki/Responsive%5FWeb%5FDesign?ref=blog.fps.hu). Ez a technológia már több, mint 2 éves múltra tekint vissza, a [List Apart oldalon született az első cikk](http://www.alistapart.com/articles/responsive-web-design/?ref=blog.fps.hu) a témában.

### Érvek, ellenérvek

A web design világában jelenleg is komoly vita folyik az RWD-ről, szólnak mellette és ellene is érvek. [Jakob Nielsen is írt róla](http://www.useit.com/alertbox/repurposing.html?ref=blog.fps.hu), aki szerint UX szempontból mindenképpen az egyedi eszközre tervezett és fejlesztett oldalak kivitelezése a megoldás. Ez így igaz, viszont a különálló oldalak karbantartása, külön fejlesztése nagyobb költségvetést igényel az üzemeltetőtől, illetve ellentmond a web természetének, amikor is ideális esetben a tartalomnak el kell különülnie a megjelenítéstől. Gondolj csak bele, hamarosan jönnek a webezésre alkalmas TV-k, és már manapság is olyan nagy az eszközpark. Képtelenség mindenre külön fejleszteni, nem?

Nem utolsó szempont a SEO (keresőoptimalizálás) kérdése. Nem olyan régen jelezte a [Microsoft (Bing)](http://www.bing.com/community/site%5Fblogs/b/webmaster/archive/2012/03/07/building-websites-optimized-for-all-platforms-desktop-mobile-etc.aspx?ref=blog.fps.hu) és a [Google is](http://googlewebmastercentral.blogspot.hu/2012/06/recommendations-for-building-smartphone.html?ref=blog.fps.hu), hogy az egy és közös URL-t ajánlják, szemben a mobilokra létrehozott külön aldomaines és egyéb megoldásokkal (m.domain.hu). Sőt, a Google a [webmestereknek szóló blogposztjában](http://googlewebmastercentral.blogspot.hu/2012/04/responsive-design-harnessing-power-of.html?ref=blog.fps.hu) a responsive webdesign megvalósításához nyújt segítséget.

Egy biztos, az RWD-nek helye van és lesz a webes világban, egyre több ilyen módon készült oldallal fogsz találkozni. [Nézd meg a mediaqueri.es](http://mediaqueri.es/?ref=blog.fps.hu) site-ot, ahol sok külhoni példát gyűjtöttek már össze.

### Magyar példák

Sajnos nagyon kevés magyar RWD oldalt találtunk, pedig nagyon jól állunk a modern böngészők elterjedtségében és az idejétmúlt browserek elsüllyedésében.

Kérlek, ha tudsz, lehetőleg magyar nyelvű RWD oldalt, ami **nem** mások által fejlesztett *(update 2012.06.14.)* WordPress és hasonló theme-t használ, akkor a poszt alatt kommentben írd meg! Folyamatosan bővíteni kívánjuk a listát. 

**KÖSZÖNJÜK, DE MÁR NE KÜLDJETEK TÖBBET! ;)**  
*(update 2013\. április 1.)*

A megjelenést két módon tudod „tesztelni”. A böngésző horizontális méretezésével, vagy a [screenqueri.es oldalon](http://screenqueri.es/?ref=blog.fps.hu) az URL-t begépelve és az eszközök váltásával. Lássuk mit találtunk.

*utolsó update: 2013\. március 21\. 14:26*

**kirowski Isobar**

[![kirowski Isobar website képernyőkép](https://blog.fps.hu/content/images/2016/01/isobar.jpg)](http://www.kirowskiisobar.com/?ref=blog.fps.hu)

**Endless Mobil**

[![Endless Mobil website képernyőkép](https://blog.fps.hu/content/images/2016/01/endlessmobil.jpg)](http://endlessmobil.hu/?ref=blog.fps.hu)

**Pixel perfect web design by Zoltan Hosszu**

[![Pixel perfect website képernyőkép](https://blog.fps.hu/content/images/2016/01/zoltanhosszu.jpg)](http://www.zoltanhosszu.com/?ref=blog.fps.hu)

**fps webügynökség**

[![fps website képernyőkép](https://blog.fps.hu/content/images/2016/01/fps-website.jpg)](https://www.fps.hu/?ref=blog.fps.hu)

**Magyar Konyha Online**

[![Magyar Konyha Online website képernyőkép](https://blog.fps.hu/content/images/2016/01/magyarkonyha.jpg)](http://magyarkonyhaonline.hu/?ref=blog.fps.hu)

**Pannako**

[![Pannako website képernyőkép](https://blog.fps.hu/content/images/2016/01/pannako-1.jpg)](http://pannako.hu/?ref=blog.fps.hu)

**Kelet és Nyugat**

[![Kelet és Nyugat website képernyőkép](https://blog.fps.hu/content/images/2016/01/keletesnyugat.jpg)](http://www.keletesnyugat.hu/?ref=blog.fps.hu)

**Plastik média**

[![Plastik média website képernyőkép](https://blog.fps.hu/content/images/2016/01/plastikmedia.jpg)](http://plastik.hu/?ref=blog.fps.hu)

**Weblabor**

[![Weblabor website képernyőkép](https://blog.fps.hu/content/images/2016/01/weblabor.jpg)](http://weblabor.hu/?ref=blog.fps.hu)

**Szecsődi Ügyvédi Iroda**

[![Szecsődi Ügyvédi Iroda website képernyőkép](https://blog.fps.hu/content/images/2016/01/szecsodi.jpg)](http://www.szecsodi-office.hu/?ref=blog.fps.hu)

**Internet Solutions**

[![Internet Solutions website képernyőkép](https://blog.fps.hu/content/images/2016/01/internetsolutions.jpg)](http://internetsolutions.hu/?ref=blog.fps.hu)

**Akadálymentes web**

[![Akadálymentes web képernyőkép](https://blog.fps.hu/content/images/2016/01/akadalymentesweb.jpg) ](http://www.akadalymentesweb.hu/?ref=blog.fps.hu)

**Magyar Olimpiai Bizottság**

[![Magyar Olimpiai Bizottság website képernyőkép](https://blog.fps.hu/content/images/2016/01/magyarolimpia.jpg) ](http://mob.hu/kezdooldal?ref=blog.fps.hu)

**ALTernative mobILITY**

[![ALTernative mobILITY website képernyőkép](https://blog.fps.hu/content/images/2016/01/altmob.jpg) ](http://www.altmob.com/hu%5FHU/kezdolap?ref=blog.fps.hu)

**Cégtaláló**

[![Cégtálaló website képernyőkép](https://blog.fps.hu/content/images/2016/01/cegtalalo.jpg)](http://www.cegtalalo.hu/?ref=blog.fps.hu)

**IneTrack**

[![IneTrack website képernyőkép](https://blog.fps.hu/content/images/2016/01/inetrack.jpg)](http://www.inetrack.hu/?ref=blog.fps.hu)

**workania**

[![workania website képernyőkép](http://38.media.tumblr.com/tumblr_mcpgywnvCb1r105v8.jpg)](http://www.workania.hu/?ref=blog.fps.hu)

![](https://blog.fps.hu/content/images/2016/01/workania.jpg)

**MAN’s Terrace**

[![MAN's Terrace website képernyőkép](https://blog.fps.hu/content/images/2016/01/man.jpg)](http://mansterrace.net/?ref=blog.fps.hu)

**Café Budapest Fesztivál**

[![Café Budapest Fesztivál website képernyőkép](https://blog.fps.hu/content/images/2016/01/cafebudapest.jpg)](http://cafebudapestfest.hu/?ref=blog.fps.hu)

**kolboid**

[![kolboid web page képernyőkép](https://blog.fps.hu/content/images/2016/01/kolboid.jpg)](https://kolboid.eu/?ref=blog.fps.hu)
### Kung fu Panda és Master Pingvin
URL: https://blog.fps.hu/google-pingvin-panda-seo/
Last updated: 2026-07-17T08:55:40.000Z
Az elmúlt néhány hónapban számtalan változás történt a Google kereső háza táján. Íme egy kis összefoglaló a legfontosabb, és szinte mindenkit érintő változásokról.

Április 24-én a Google Magyarországon is alkalmazni kezdte a legújabb algoritmusát, amelyet Pingvinnek keresztelt el. Sokakat hátrányosan érintett, néhány weboldalnak azonban előrelépést hozott. Nem ez az első nagyobb szabású frissítés csomag, az előzőekről [itt olvashatsz](https://docs.google.com/spreadsheet/viewform?formkey=dEVxdmdRWFJRTjRoLWZVTHZkaTBQbkE6MQ&ndplr=1&ref=blog.fps.hu).

A frissítés célja az, hogy háttérbe szorítsák az interneten lévő értéktelen, és a Google algoritmusát kijátszó weboldalakat. Korábban már többször tettek lépéseket ennek érdekében, például a tavaly elindított Panda algoritmussal. Lássuk, milyen változások történtek, és ezek hogyan befolyásolják a találati listákat.

![Panda mackó fotó](https://blog.fps.hu/content/images/2016/01/panda-2.jpg)  
*a kép forrása:* [*WikiPedia*](http://en.wikipedia.org/wiki/File:Atlanta%5FZoo%5FPanda.jpg?ref=blog.fps.hu)

### Panda: a minőségi tartalom a legfontosabb

Magyarországon 2011 nyarán jelent meg az első verzió, a legutóbbi pedig idén április 19-én (Panda 3.2). Az elmúlt háromnegyed évben több frissítése is volt, folyamatosan finomítják az algoritmusokat. Célja, hogy kiszűrje azokat a tartalomszolgáltatókat és weboldalakat, akik nem frissülő, elavult, nem megfelelő minőségű tartalmat szolgáltatnak. A Google számára az a legfontosabb, hogy minél pontosabb és relevánsabb találatokkal tudja kiszolgálni a felhasználókat.

### Néhány szempont, amire különösen figyelni kell

- Fontos hogy a tartalom minőségi, helyesírásilag és stilisztikailag megfelelő, és természetesen egyedi, máshol nem fellelhető tartalom legyen
- Ne ugyanaz a tartalom legyen többféleképpen megírva
- Ne a keresőrobotoknak, hanem a felhasználóinknak írjuk a tartalmakat. Mesterségesen fel tudjuk juttatni az oldalunkat az első pozíciókba, de a „rossz” tartalommal úgysem tudjuk elnyerni a látogatók bizalmát, ezért is fontos egyedi, releváns információkat adó tartalmakat készíteni.
- Bár sokan az oldalon megjelenő reklámokból élnek, de nem szabad túlzásba esni, a túl sok reklám is riasztóan hat a látogatókra
- Figyeljünk arra, hogy minden oldalon elegendő egyedi, kizárólag az adott oldalra jellemző tartalom legyen, mivel ezzel lehet az állandó elemeket ellensúlyozni.

![Pingvinek fotó](https://blog.fps.hu/content/images/2016/01/pingvin.jpg)

### Pingvin: többet ésszel, mint erővel

2012\. április 24-én ismét algoritmus frissítés volt a Google-nél, mivel több nagyobb volumenű változás is történt, így Pingvin névvel került a köztudatba. Az új algoritmus is folytatja a Panda útját, a kereső kijátszása ellen irányulnak a változtatások. A spam jellegű weboldalaknak vélt honlapokat könyörtelenül kiszűrik. A „vélt” szó itt nem véletlen.

Az online világban a spam egyet jelent a kéretlen dolgokkal. Nincs ez másként a kereső szempontjából sem. Számtalan olyan website létezik, amely valamilyen módon próbálja kijátszani a kereső algoritmusát. A keresők folyamatosan harcban állnak ezzel, és már régóta hangoztatták, hogy mitől kell tartózkodniuk a webmestereknek. A jelenlegi frissítés által több olyan weboldal forgalma és pozíciója is visszaesett, amely nem követett el alapvető hibákat.

Mire kell akkor figyelni az alapvető javaslatokon kívül? Nem szabad túlzásba vinni az optimalizálást, és életszerűen kell SEO-zni a weboldalakat. Sokan a gyorsabb előrelépés reményében igen intenzív munkát végeznek, vagy kiskapukat keresnek, viszont egy nagyon könnyen visszaüthet.

### Javaslatok a jobb pozíciók eléréséhez

- A Panda kapcsán leírt javaslatokat most még inkább be kell tartani
- Ne pakoljuk tele az oldalunkat értéktelen tartalmakkal. Csak olyat publikáljunk, amelyek a célközönség számára értékes.
- A gyors linképítést kerülni kell. Egyáltalán nem életszerű, hogy egy nap alatt több ezer bejövő link mutat az oldalunkra.
- Próbáljunk olyan hasznos információkat megosztani a látogatóinkkal, hogy természetes hivatkozásokat is generáljanak a weboldalunkra.
- Átgondolva és logikusan építsük fel a tartalmakat, ne legyen több oldal hasonló tartalommal
- A fizetett linkeket és linkhálózatokat szintén kerülni kell.
- Nem életszerű az sem, hogy minden bejövő hivatkozás ugyanolyan szövegű, illetve csak a nyitó oldalra mutat, ez egyértelműen spam jellegű linképítés a kereső szempontjából. Ez az oldalon belüli hivatkozásokra is érvényes.
- Kulcsszóhalmozást, kulcsszavakkal teletűzdelt tartalmakat szintén ne alkalmazzunk.

Ha nem találunk semmilyen problémát, és mégis hátrasorolt minket a Google, [itt lehet értesíteni a szakembereket](https://docs.google.com/spreadsheet/viewform?formkey=dEVxdmdRWFJRTjRoLWZVTHZkaTBQbkE6MQ&ndplr=1&ref=blog.fps.hu), hogy vizsgálják meg az oldalunkat. A Pingvin elég nagy felháborodást keltett világszerte, és egy [petícióval](http://www.change.org/petitions/google-please-kill-your-penguin-update-l?ref=blog.fps.hu) próbálják meg visszavonatni a kezdeményezők a frissítés csomagot.

Íme [egy remek infografika](http://www.seopalbg.com/blog/google-algorithm-changes-1998-2012-infographic/?ref=blog.fps.hu), amely összefoglalja a Google algoritmus változásait 1998-tól napjainkig.
### Hogy használták a Media Hungary 2012 mobil appot?
URL: https://blog.fps.hu/hogy-hasznaltak-a-media-hungary-2012-mobil-appot/
Last updated: 2026-07-17T08:55:49.000Z
2012\. május 8–9-én Siófokon került megrendezésre a [Media Hungary 2012 konferencia](https://www.mediahungary.hu/?ref=blog.fps.hu), melyhez ügynökségünk csapata fejlesztette a mobil applikációkat. Ezekkel kapcsolatban osztunk meg információkat.

### Melyik verziót, milyen arányban használták?

A konferenciához egyelőre két operációs rendszerre fejlesztettünk, mégpedig iOS-re (iPhone) és Androidra. Összesen nagyságrendileg **300-an töltötték le** az appokat, melynek 69%-a iOS volt, amiből következik, hogy Magyarországon a Média jeles képviselői főként az Apple iPhone készülékeit részesítik előnyben, szemben az Androidos készülékekkel.

![69% iOS és 31% Android a 300 letöltés alapján diagram](https://blog.fps.hu/content/images/2016/01/stat.jpg)

### Kedvencek és mobil top lista

Az alkalmazásokban az előadásokat kedvencnek lehetett jelölni, mellyel saját program lista összeállítására nyílt lehetőség. Ezzel a funkcióval az appot használók kb. 65%-a (azaz több, mint 200 felhasználó) élt. A háttérben a rendszer ezeket a jelöléseket adatbázisba mentette, mely alapján készítettünk egy TOP10-es listát.

![A Media Hungary 2012 kedvenc előadásai mobil appok adatai alapján](https://blog.fps.hu/content/images/2016/01/top10.jpg)

Sok adatot gyűjtöttünk és rengeteg visszajelzést is kaptunk. A következő változatokban ezeket mind figyelembe fogjuk venni, hogy növeljük a felhasználói élményt.
### A sitebuild, sitebuilder fontos?
URL: https://blog.fps.hu/a-sitebuild-sitebuilder-fontos/
Last updated: 2026-07-17T08:55:58.000Z
Ezt a posztot inkább a fejlesztőknek, webes cégeknek szánom, de érdekes lehet persze mások számára is. Először is tisztázzuk, mit értünk sitebuild alatt.

A sitebuild a megtervezett és a designer által elkészített felületek (nagyrészt photoshop, vagy fireworks) megvalósítása HTML és CSS nyelvek segítségével.

A webes fejlesztők között a sitebuilding egy „lenézett” munkafolyamat. Éppen emiatt írom ezt a posztot, hogy ideje lenne már a helyén kezelni. **A jó sitebuild aranyat ér**, igenis nehéz és komoly feladat, melyen egy webes, vagy mobil webes projekt sikeressége múlhat. Vegyük sorra, milyen fázisokból áll a sitebuilder munkája – ez a sorrend nyilván ízlés dolga.

### Első fázis

A bedesignolt oldalakat át kell néznie, majd azokból gyors vázlatokat készít magának, hogyan is fog ez HTML formába kerülni. Sokan használnak [CSS grid](http://spyrestudios.com/css-grid-systems/?ref=blog.fps.hu) rendszereket, azok közül is a [960px széles](http://960.gs/?ref=blog.fps.hu) a legelterjedtebb. A gridek használata megkönnyíti ezt a fázist, de csak akkor, ha már a tervező és a designer is eleve ebben gondolkodott. A lényeg, hogy felépíti a layoutokat HTML-ben és létrehozza hozzá a CSS-t.

### Második fázis

Szükség van ugyebár [CSS resetre](http://www.css-reset.com/?ref=blog.fps.hu). Minden böngészőnek van egy alapértelmezett CSS stílus készlete, melyek eltérnek egymástól. Éppen ezért hoztak létre különböző CSS reset stíluslapokat, melyek megpróbálják az összes böngészőt beállítani egy közös stílus készletre (a legtöbbet alkalmazott, legismertebb az [Erik Meyer féle reset](http://meyerweb.com/eric/tools/css/reset/index.html?ref=blog.fps.hu)). Sokan mások által létrehozott megoldásokat alkalmaznak, mi ezekből gyúrtuk össze a ránk szabott változatot és arra esküszünk.

### Harmadik fázis

Ki kell alakítani egy globális alap stílust, ami az egész oldalnak megfelel és jó alapot szolgáltat. Ehhez az összes oldalt végig kell nézni és meg kell határozni az alap font készletet, méretet, sor magasságot, a címsorok, lista elemek, űrlap elemek, normál és akció gombok stb. stílusát. Itt kell nagyon óvatosan eljárni! Ha ennél a fázisnál „hibázik” a sitebuilder, akkor a későbbi fejlesztések során rengeteg felesleges stílus felülbírálás keletkezik, ami egyrészt nagyobb CSS kód mennyiséget és lassabb renderelést eredményez, ezáltal rontva a felhasználói élményt. Kiemelten fontos, hogy a fejlesztők tudjanak a globális stílusokról és használják is azokat.

### Negyedik fázis

*„Darabolás”*, ahogy viccesen nevezik. Ilyenkor a design állandó képi elemeinek kivágása történik. A jó sitebuilder tudja, hogy ezeket az ikonokat, logót, háttérképeket (amennyiben CSS-ben nem valósíthatók meg) érdemes [CSS sprite(-ok)](http://css-tricks.com/css-sprites/?ref=blog.fps.hu) formájában tárolni. A gyors letöltés érdekében fontos, hogy minél kevesebb http request legyen. Minél kevesebb fájl kerül letöltésre, annál gyorsabban jelenik meg a böngészőben az oldal. A CSS sprite-oknál sok trükköt érdemes és kell alkalmazni, emellett a kivágott képek optimalizálásával is foglalkozni kell. A felhasználói oldalon egyáltalán nem mindegy, hogy a letöltött kép 80 kB, vagy 50 kB méretű.

### Ötödik fázis

A tényleges HTML megvalósítás. Törekedni kell a minimális HTML kód használatára! Egyrészt a gyorsabb betöltés érdekében, másrészt a SEO szempontok miatt. *„Minden manager tud HTML-ben programozni”* – tartja a mondás, de egy „elegáns” HTML kód komoly szakmai kihívást jelent.

![image](https://blog.fps.hu/content/images/2016/01/havenofearofperfection_new.jpg)

### Mit kell tudnia egy sitebuildernek?

- a DOM a barátja
- ismeri az összes layout típust, legyen az fix széles, fluid, stb.
- a megfelelő HTML tageket használja az adott tartalomhoz (pl. ha táblázat, akkor <table>, ha felsorolás, akkor <ul>, ha számozott felsorolás, akkor <ol> és így tovább)
- CSS-t mélyrehatóan bírja, különös tekintettel a selectorokra, tudja, hogyan vonhatóak össze CSS utasítások (pl. background: #fff url(/image/background.gif) repeat-x;)
- ismeri az összes böngészőt és azok verzióinak kínjait (HTML, CSS)
- használja a HTML validatort és valid kódot ír
- kisujjában vannak a különböző CSS trükkök (hackek)
- tudja, mire van szükség a jó SEO-hoz és érti is az alapelveket
- legalább közepes szinten használja a photoshopot és/vagy fireworks-öt
- folyamatosan képzi magát! A még mindig befejezetlen HTML5 ajánlásait a böngészők programozói folyamatosan belefejlesztik az újabb és újabb verziókba, melyekkel lehetőségek tárháza nyílik meg az egyszerűsítés irányában
- webes tipográfia alapelveivel tisztában van
- szépérzékkel van megáldva
- a mobil webes sitebuild egy külön történet, a responsive megvalósítás és a különböző mobil eszközök problémái újabb ismereteket igényelnek

### Az oldal betöltési sebessége

A betöltési idő nagyrészt az oldalak különböző elemeinek (képek, stíluslapok, JavaScriptek stb.) letöltésével és azok feldolgozásával telik, mely **[a teljes folyamat 80%-át teszi ki](http://developer.yahoo.com/performance/rules.html?ref=blog.fps.hu#num%5Fhttp)**. Az elemek számának lecsökkentésével növelhető a betöltési sebesség. Ez a kulcsa a gyors oldalaknak!

Kedves vérbeli fejlesztők! Tudomásul kell vennetek, hogy a jó sitebuild és front-end fejlesztés sokkal fontosabb a felhasználói élményt tekintve, mint a legzseniálisabban optimalizált szerver oldali kód. ;) Nem véletlen egyébként, hogy világszerte külön cégek jöttek létre, melyek kizárólag sitebuild szolgáltatást nyújtanak. Ahogy látom, sajnos Magyarországon kevés a jó sitebuilder, és sok cég szenved az ilyen jellegű kompetencia hiányától. Kérlek, cáfoljatok meg!

Nyilván írhatnék még a bundle, minify hasznos és kötelező megoldásokról, de ezek már nem passzolnak igazán a sitebuild témakörébe – egyébként a sebesség optimalizálás is megér egy posztot. Majd. Később.

### Néhány eszköz, ami sitebuilderként segítségedre lehet:

- [képek optimalizálása](http://www.smushit.com/ysmush.it/?ref=blog.fps.hu)
- [CSS trükk gyűjtemény](http://css-tricks.com/?ref=blog.fps.hu)
- [CSS sprite generator](http://css-sprit.es/?ref=blog.fps.hu)
- [CSS3 generatorok](http://designshack.net/articles/css/20-free-css3-code-generators?ref=blog.fps.hu)
- [Böngészők renderelésének összehasonlítása](http://browsershots.org/?ref=blog.fps.hu)
- [Adobe Shadow responsive webdesignhoz](http://labs.adobe.com/downloads/shadow.html?ref=blog.fps.hu)
- [favicon generator](http://www.favicon.cc/?ref=blog.fps.hu)
- [HTML5 böngésző támogatottság](http://html5readiness.com/?ref=blog.fps.hu)
- [HTML5 és CSS3 támogatottság](http://findmebyip.com/litmus?ref=blog.fps.hu)
### Mit nekem social media?
URL: https://blog.fps.hu/social-media-haszna-neked/
Last updated: 2026-07-17T08:56:08.000Z
Sok cikket, posztot olvastam már a social mediaról, ezek mindegyike kivétel nélkül arról szól, hogy a cégeknek, termékeknek, szolgáltatásoknak miért szükséges a jelenlétük a különböző social oldalakon, és ebből hogyan tudnak bevételt realizálni. Viszont arról nem sok szó esik, hogy az egyes embereknek a szórakozáson és a kapcsolattartáson túl milyen haszonnal járhat. Most megosztom veletek, hogyan használom ezeket az eszközöket és hogy ezt miért teszem.

*Kérlek, miután elolvastad ezt a posztot, ne törölj az ismerőseid közül, és ne szüntesd meg semelyik csatornámmal a kapcsolatot, inkább ellenkezőleg.*

### Első haszon – Self marketing

Tudom, magyarok vagyunk, itt nem szokás magunkról és eredményeinkről beszélni, mert akkor nagyképű, önelégült hólyag lesz belőlünk. Na ezen kell változtatni! Miért ne lehetnék büszke arra, hogy elértem valamit, hogy éveken keresztül elolvastam több tucat könyvet a szakterületemen, és nap, mint nap tanulok, végzem a munkám, időnként rosszul, sok esetben pedig jól. Miért jó az, ha tudod magadról, hogy jó vagy adott témában, de ezt nem közölheted senkivel? Hogy fogják elhinni Neked, hogy igazad van, és pláne miért fizetnének akár 1 Forintot is a tanácsodért? Pontosan ezért van szükséged self marketingre, és a social media szinte tálcán kínálja a lehetőséget.

Szimplán egy kis tudatosságra van szükséged, amikor a Facebookon, twitteren és egyéb oldalakon posztolsz, tweetelsz. Tisztában vagyok azzal, hogy ezek a felületek alapvetően a szórakozásról szólnak, de miért ne tolhatnál néha egy fotót magadról, miközben a munkád végzed, vagy ott voltál egy konferencián, találkozón, vagy mutathatnád meg, amit te alkottál. Pl. ha asztalos lennék, biztos felraknám időnként az általam jónak tartott termékeim. Ennek valójában mi is az értelme? Biztos nem azért, hogy kiéld az exhibicionizmusodat, sokkal inkább azért, hogy az ismerőseid (szándékosan nem barátokat írtam) tudják, hogy mivel foglalkozol, mihez értesz. Vágod?

![kolboid feje illusztráció](https://blog.fps.hu/content/images/2016/01/kolboid-art.jpg)

Ebben a pillanatban remélhetőleg van munkád. Ennek amúgy nagyon örülök, de mi lesz, ha megszűnik az állásod, a cég csődbe megy, esetleg váltani akarsz, vagy ne adj Isten kirúgnak?! Kezdheted az álláskeresést. Felhívod a közvetlen barátaid, hogy tudnak valami jó munkát és izzadsz, szenvedsz, mert bizonytalan a jövőd. Ilyenkor derül ki majd számodra, hogy senki sem tudja, hogy mivel is foglalkozol, mihez értesz.

Tudatosan, lépésről-lépésre építkezem a social mediaban. Most például blogot írok, amit te meg jól elolvasol és valószínűleg Facebookról, vagy twitterről érkeztél :) Mondhatom, hogy jól érzem magam a cégben, amit a barátommal és az fps csapatával közösen építünk. Ennek ellenére kaptam jó pár állásajánlatot és volt köztük olyan, amit szívesen el is vállaltam volna, ha nem lenne az fps a szívügyem. Semmi kétségem nincs afelől, ha bármi is történne az fps-sel, azonnal lenne munkám. És neked?

#### Néhány jó tanács

- Bármennyire is viccesnek gondolod az obszcén fotókat és videókat, akik nem ismernek (márpedig sok ilyen ember látja és nem csak a közvetlen barátaid), rossz véleménnyel lesznek rólad, és bezársz sok kaput magad előtt.
- Vedd tudomásul, hogy az emberek alapvetően nem szeretik a szenvedést, a nyavalygást. Lehet, hogy most durván fog hangzani, de nem érdekli az embereket, hogy meghalt egy közvetlen rokonod és pláne nem, hogy az évfordulója van a szomorú eseménynek. A social media felülete egyébként sem arra való, hogy a legbelső érzéseid megoszd idegenekkel.
- Ne posztolj folyamatosan! Borzasztóan irritáló, amikor valaki egymás után kirak 3245556 videót, csak mert meghallgatta és éppen tetszett neki.
- Ha lehet és nem a lényeddel összeférhetetlen, akkor légy mindig pozitív, barátságos. A trollkodás is lehet vicces, de hosszú távon egyértelműen káros a személyedre.
- Ne legyenek kétségeid, akármelyik csatornát is használod, ha éppen állásra pályázol, akkor a cég HR-esei utánad fognak nézni minden oldalon. Csendben jegyzem meg, hogy mi magunk is megtesszük, persze nyilván nem kérjük el a Facebook jelszavad :)

![You forget it in people felirat](https://blog.fps.hu/content/images/2016/01/youforgeritinpeople.jpg)

### Második haszon – Az információszerzés

Hihetetlen mennyiségű információ áll rendelkezésre és ömlik minden csatornán keresztül. Ha ügyes vagy és okosan használod a social media adta lehetőségeket, akkor rengeteget tanulhatsz, képezheted magad és jól informált lehetsz. Használd te is ezeket az eszközöket! Íme egy felsorolás, hogy mit, mire és miért használok.

**[Facebook](https://www.facebook.com/kolboid)**

Alapvetően szórakozásra, kapcsolattartásra használom, illetve a self marketingem fontos eleme, ugyanis itt érhető el a legtöbb ember. Általában reggel és este nézek rá (mint ahogy sokan mások), és gyorsan végigpörgetek 20-30 posztot. Sok esetben találkozom engem érdeklő cikkekkel, leírásokkal. Nem utolsó sorban a csoportok előnyére hívnám fel a figyelmed! Tagja vagyok több fb csoportnak, ahol hasonló érdeklődésű emberrel tudom megvitatni a minket érdeklő problémákat, sokat lehet fejlődni. Ezúton is köszönöm a UX csoport minden tagjának a posztokat, véleményeket, ötleteket.

**[twitter](https://twitter.com/kolboid?ref=blog.fps.hu)**

Értetlenül állok az előtt, hogy milyen kevesen használják még mindig Magyarországon, pedig **a legjobb információforrás**. Igaz, kezdetben kell egy kis kutatómunkát folytatnod, hogy megtaláld azokat a személyeket, online újságokat, cégeket, akiket követni fogsz, de nagyon megéri.

**[LinkedIn](http://www.linkedin.com/pub/istv%C3%A1n-kolozsi/26/674/916?ref=blog.fps.hu)**

A self marketing alapja! Alapvetően egy szakmai önéletrajz oldal, ahol kapcsolatokat építhetsz, ajánlásokat kaphatsz másoktól. Itt is vannak csoportok (hasznos!) és céges oldalak, stb. Ma már hazánkban is **komolyan használják a fejvadászok**. Érdemes rendszeresen frissíteni, feltenni a szakmai eredményeid, végzettségeid. Többek között innen is érkezett már állásajánlat hozzám.

**[StumbleUpon](http://www.stumbleupon.com/stumbler/kolboid?ref=blog.fps.hu)**

Alig ismert és használt hazánkban. Pedig nagyon jó! Beállítasz néhány kategóriát az érdeklődésed szerint, majd a böngésződ tetején megjelenő sávban található Stumble gombot nyomogatod, és egymás után kapsz minőségi tartalmakat a webről az érdeklődésednek megfelelően. Egy óriási csapat dolgozik a rögzített oldalak folyamatos karbantartásán, így biztosítva a minőséget. Olyan oldalakkal találkozom és olyan ismeretekre teszek szert, amit sehol máshol nem kapok meg.

**[Google+](https://plus.google.com/104642436258722458738/posts?ref=blog.fps.hu)**

Csak, mert geek vagyok, ezért ott vagyok. Egyelőre csak self marketingre használom, sok haszna nincs, ugyanis alig van valami pörgés. Habár itt is lehet követni sok érdekes külhoni személyt, akiktől tanulhatsz, azonban ez nekem már sok lenne, így nem foglalkozom vele.

Használok még néhány social cuccot, mint a [Pinterest](http://pinterest.com/kolboid/?ref=blog.fps.hu), az [Instagram](http://instagram.com/?ref=blog.fps.hu), a [Tumblr](http://www.tumblr.com/?ref=blog.fps.hu), de ezek inkább a szórakozásról, a vizuális élményekről és a fotózásról szólnak.

![Facebook like szemeteskosárban a többi szemét között illusztráció](https://blog.fps.hu/content/images/2016/01/likeintrash-2.jpg)

### Mennyi időt vesz mindez igénybe?

„Te nem vagy normális!” – gondolod most – „Egész nap csak ezeken az oldalakon lógsz és akkor mikor dolgozol, élsz?”. Jogos a kérdés. Mélységes túlzásokba lehet esni és bevallom, meg is történt velem többször is, a feleségem sokat tudna mesélni erről, ezúton is bocsánat kérek tőle! DE! Minden eszközt meg lehet és **meg kell tanulni értelmesen és optimálisan használni**. Szerencsére erre is létrejöttek már szolgáltatások. Például bevezettem a [Flipboard](http://flipboard.com/?ref=blog.fps.hu) és a [Zite](http://zite.com/?ref=blog.fps.hu) használatát. Ez a két eszköz újság formájában gyűjti össze az általad megadott forrásokból az információt, és egyben fogyaszthatod lényegesen kevesebb időt „pazarolva”. Esténként egy óra alatt végiglapozom, a fontos cikkeket elolvasom, reagálok egy-két posztra, tweetre, lájkolgatok és megyek tovább.

Tudom, nincs idő mindent elolvasni vagy megnézni, pedig nagyon érdekelne. Itt jön képbe az [Instapaper](http://www.instapaper.com/?ref=blog.fps.hu) (olcsó) és a ~~[Readability](http://www.readability.com/?ref=blog.fps.hu) (ingyenes!)~~, melyeket nagyon szeretek. Időközben a Readibility megszűnt, ezért ebben [a listában találsz alternatívákat](https://blogging.com/rss-dead/?ref=blog.fps.hu#readers). Beépülnek a böngészőmbe, a mobil eszközeimen is megtalálhatóak. Ha találkozom egy érdekes tartalommal, de épp nincs rá időm, akkor megnyomom a „Read Later” funkciót és az elmenti nekem.

A mobil eszközök lehetőséget biztosítanak az „üres” idők kitöltésére – mint pl. várok a bankban, utazom, trónolok :), várok valakire stb. Ilyenkor előkapom a mobilt, vagy a táblát és elolvasok egy-két cikket.

Zárásként egy könyvet ajánlok, ami a self marketingről szól és **mindenképpen érdemes elolvasnod:**  
[John Purkiss: Énmárka](http://www.hvgkonyvek.hu/index.php/Pszichologia-onismeret/Enmarka/book%5Fflypage.tpl.html?ref=blog.fps.hu)
### Kulcsszó választás, avagy mennyire kössük az ebet a karóhoz?
URL: https://blog.fps.hu/kulcsszo-valasztas-avagy-mennyire-kossuk-az-ebet/
Last updated: 2026-07-17T08:56:18.000Z
Amikor egy ügyfél megkeres minket azzal, hogy a már meglévő oldalát szeretné keresőoptimalizáltatni, sokszor sorol fel kulcsszavakat – jobb esetben egy-két, rosszabb esetben akár egy tucatnyit is – melyekre szeretné az oldalát az első találati helyen látni a keresőkben.

Mit tegyünk ilyenkor? Többféle utat választhatunk, de amit MINDIG szem előtt kell tartanunk, hogy az ügyfél legyen elégedett! 

### Ügyfelek vs. szakember

Vannak olyan ügyfeleink, akiknek konkrét és határozott elképzeléseik vannak, és egyszerűen képtelenség őket meggyőzni arról, hogy más kulcsszavakat kellene választani ahhoz, hogy azt a célt érjük el, amit kitűztek. Velük kell a legóvatosabban bánni, ugyanis ha engedünk az „erőszaknak” és csak az ő általa megadott kulcsszavakkal dolgozunk, de nem jönnek az eredmények, mi leszünk a hibásak, ráadásul még meg is kérdőjelezik a szaktudásunkat. 

Ha viszont mi választjuk ki a kulcsszavakat, és elkezdünk velük dolgozni anélkül, hogy az ügyféllel egyeztettünk volna, könnyen mellélőhetünk. Lehet, hogy a mi kulcsszavaink jól fognak teljesíteni, jó pozícióba hozza az oldalt a keresőkben, csak épp nem a célcsoportot sikerül elérnünk. A hosszú távú és gyümölcsöző kapcsolat reményében rá kell vennünk őket az együttműködésre, kölcsönös kompromisszumokkal és statisztikákkal próbáljuk meg meggyőzni őket. 

![Egy ember mérgesen beszél egy másik emberhez illusztráció](https://blog.fps.hu/content/images/2016/01/people.jpg)

Vannak „ideális” ügyfeleink is, akik elmondják, mivel foglalkoznak, mi az üzletpolitikájuk és felvázolják, milyen célt szánnak a weboldaluknak, a technikai megvalósítást pedig teljes mértékben ránk bízzák. Ilyenkor könnyebb a dolgunk, jobban tudunk tesztelni és kísérletezni, míg meg nem találjuk a leginkább a témához passzoló és jól teljesítő kulcsszavakat. 

### Hogyan válasszunk kulcsszavakat?

Keresőoptimalizáláskor a legelső és egyben legfontosabb lépés eldönteni, mely kulcsszavakra szeretnénk optimalizálni. Ehhez alaposan ismernünk kell az optimalizálandó oldalt, annak küldetését. Ezután összegyűjtjük a lehetséges szavakat, kifejezéseket és variációkat, majd egy keresési trend elemzéssel megnézzük, melyik kulcsszóra hányan keresnek és mekkora a verseny. Az ügyfelek ilyenkor azt gondolják, vegyük az első x legkeresettebb kulcsszót, és optimalizáljunk arra. Ám ez ennél jóval bonyolultabb. Biztos, hogy mi is versenybe szeretnénk szállni a legkeresettebb kulcsszavakkal? 

### Short tail vagy long tail?

A legáltalánosabb, sok esetben egy szóból álló kifejezéseket nevezzük short tail kulcsszavaknak. Ezekre a szavakra keresnek a legtöbben, éppen ezért ezekre a verseny is a legnagyobb, így nagyon nehéz az első 10 találati pozícióba bekerülni. Ilyen kulcsszó például az edzés szó.

A specifikusabb, több szóból álló kifejezéseket nevezzük long tail kulcsszavaknak. Ezekre a kifejezésekre jóval kisebb a keresés, ugyanakkor jóval könnyebb jó pozícióba kerülni a keresőkben. Akik ilyen kulcsszavakat használnak, pontosan tudják, mit keresnek, így jóval nagyobb az esély arra, hogy ezek a látogatók konverziót hoznak az oldalnak. Az előző példánál maradva long tail kifejezés pl. a személyi edzés Miskolcon kifejezés.

![short vs. long tail grafikon](https://blog.fps.hu/content/images/2016/01/rovid-hosszu.jpg)

### Hogyan tovább?

Mérlegeljük, hogy mit is szeretnénk elérni: látogatottságot vagy konverziót? A short tail kulcsszavakkal tudunk könnyebben látogatottságot generálni, de mivel jóval nagyobb a merítés, így kisebb lesz a konverziós arány. A long tail kulcsszavakkal azokat a látogatókat érhetjük el, akik a konverziót hozzák, így ez az arány jóval magasabb lesz, viszont a látogatottság nem lesz túl magas. 

### Ha elkészült az optimalizálás…

Miután felkerültek a módosítások az oldalra, várjuk, hogy a keresőbotok indexeljék a site-unkat, így a módosított meta adatok és tartalom is „láthatóvá” válik a keresőkben. Azt, hogy hogyan jelennek meg az egyes oldalaink a kulcsszavainkra, mi magunk is ellenőrizhetjük. Néhány naponta vagy hetente célszerű rákeresni a kulcsszavakra, hogy lássuk, hogyan alakulnak a pozíciók. DE! Mivel a Google logolja a keresési előzményeket, így ha gyakran keresgetünk ugyanazokra a kifejezésekre, előbb-utóbb a saját találati listánkon előnyösebb helyen jelenik meg, mint amilyen pozícióban van valójában. Emiatt fordulhat elő az is, hogy különböző gépeken, vagy akár ugyanazon a gépen, de különböző böngészőkben is más-más pozícióban látjuk az oldalunkat. 

### Mi erre a megoldás?

Mivel a Google akár 180 napig is tárolhatja a nem bejelentkezett felhasználók keresési előzményeit (a bejelentkezettekét gyakorlatilag korlátlan ideig), így célszerű kikapcsolni a személyre szabást. [Olvasd ezt a posztot](http://seo-konyv.eu/seo-keresooptimalizalas/kulcsszo-ellenorzes.seo?ref=blog.fps.hu), ami részletesen taglalja, hogyan deríthetjük ki a pontos pozícióját az adott kulcsszavaknak.

![Éva begipszelt keze, amivel like-ot mutat fotó](https://blog.fps.hu/content/images/2016/01/kez-1.jpg)

Éva keze be lett gipszelve, de lájkolni azért még tud. [Adj neki Te is lájkot](https://www.facebook.com/fpsugynokseg/posts/154755231318568) ;)
### Miért KELL az esztétikus design?
URL: https://blog.fps.hu/miert-kell-az-esztetikus-design/
Last updated: 2026-07-17T08:56:28.000Z
Úgy éreztem, le kell írnom, mitől működik a jó grafikai design, miért van rá szükség, mihez ért nagyjából egy webgrafikus (UI designer), és hogy mi a különbség a DTP (nyomdai) grafikus és egy webgrafikus között.

Az esztétikum emberi agyra gyakorolt hatásait a kognitív pszichológia régóta kutatja, melyből most két nagyon fontos gondolatot osztok meg.

### Halo effektus

A [Halo effektus](http://en.wikipedia.org/wiki/Halo%5Feffect?ref=blog.fps.hu) Edward Thorndike amerikai pszichológus nevéhez fűződik. Gyakorlatilag arról van szó, hogy [a felhasználók 50 ezredmásodperc alatt eldöntik](http://www.websiteoptimization.com/speed/tweak/blink/?ref=blog.fps.hu), tetszik a grafikai megjelenés nekik, vagy sem. Mindez a tudatalattiban történik, és ez tudatosan nem kontrollálható. Ráadásul ez az „első benyomás” vagy „érzelmi reakció” kihatással van a későbbi használatra is. Úgynevezett [„megerősítési torzítás”](https://blog.kolboid.eu/67-modszer-hogyan-novelheted-a-konverziot/?ref=blog.fps.hu) is fellép, amikor az egyén (felhasználó) bizonyítékokat keres arra, hogy alátámassza a kezdeti hipotézisét. Ezért van az, hogy egy jóképű, jó fellépésű, megnyerő emberről alapvetően azt feltételezzük, hogy ő jó és megbízhatunk benne (a szélhámosok ezt használják ki). Magyarul, ha nem esztétikus a designod, akkor eleve hátránnyal indulsz még akkor is, ha zseniális a tartalom, a szolgáltatás, felhasználóbarát az oldal. A tiszta és egyben professzionális design fél siker.

![kolboid feje szakállasan, szőrősen, mellette pedig szépen megborotválkozva, mosolyogva](https://blog.fps.hu/content/images/2016/01/melykikukbenbiznal-1.jpg)

### Az attraktív dolgok jobban működnek!

A gondolat [Don Normantől](http://en.wikipedia.org/wiki/Donald%5FNorman?ref=blog.fps.hu) származik. Az esztétikus design kellemes érzést kelt az egyén (felhasználó) agyában (pozitív érzelmi állapotot idéz elő), ezáltal növeli kreativitását és toleranciáját, így ha később problémával találkozik az alkalmazás használata során, akkor azt könnyebben és hatékonyabban oldja meg. Más szóval, ha jobban érzed magad, akkor hajlamos vagy átlépni tervezési, használhatósági hibákon is. Egy [kutatás (What Is Beautiful Is Usable)](https://phdproject01.wordpress.com/2010/01/24/what-is-beautiful-is-usable-tractinsky-n-et-al/?ref=blog.fps.hu), ami alátámasztja ezt az állítást.

Don másik fontos következtetését egyszerű kérdésfelvetéssel értheted meg: „Mikor lemosatod, waxoltatod, kitakaríttatod az autód, akkor könnyebb vezetni, ugye? Vagy legalábbis úgy érzed…” Olvasd el Don könyvét, mert hasznos, [íme egy rövid kivonat](http://www.jnd.org/dn.mss/emotion%5Fdesign.html?ref=blog.fps.hu).

### Mit kell tudni a grafikusról?

A grafikus vagy született zseni, vagy tanulja ezt a szakmát (a zseni is). Nyilván az utóbbi a jellemzőbb, és miután ő ért hozzá, érdemes elfogadni a gondolatait. Nem jó út az, ha tedd ide, tedd oda, színezd át, próbáld már ki így, meg úgy jellegű ötleteiddel fárasztod, mert szinte minden esetben rá fogsz jönni, hogy nem jó az elképzelésed. A grafikus megtanulta a tipográfia csínját-bínját, az aranymetszés szabályait, a színkeverés tudományát és még sok mindent, amit felhasznál minden design előállítása során. Inkább érzéseket, benyomásokat fogalmazz meg irányába, ha nem tetszik az eredmény, mert azokból építkezve tud újabb tervekkel előállni.

**Szóval ezt ne csináld!**

![kicsit jobbra, kicsit balra körkörösen folyamatosan](https://blog.fps.hu/content/images/2016/08/designers-life.gif)

Ajánlom figyelmedbe [ezt a rendkívül humoros történetet](http://cushtybrovs.blog.hu/2010/11/10/miert%5Fne%5Fkerj%5Fsziveseget%5Fgrafikustol?ref=blog.fps.hu), melyet elolvasva képet alkothatsz, milyen is egy vérbeli grafikus.

### A DTP grafikus nem webgrafikus!

Ez nagyon fontos! A webgrafikus egy másik bolygóról érkezett. Felsorolom a teljesség igénye nélkül mihez kell értenie egy jó webgrafikusnak:

- értenie kell minimális szinten (jó esetben nagyon) a sitebuildhez (a HTML és CSS kódoláshoz) – erre azért van szükség, mert mindent nem lehet megvalósítani
- tisztában kell lennie az alap betűkészletekkel (melyek minden operációs rendszeren elérhetők), illetve a webfontokkal és azok nyűgjeivel is közeli ismeretséget kell kötnie
- ismernie kell az alap használhatósági szabályokat (usability) – pl. ha valami [gomb, akkor az nézzen ki gombnak](https://blog.kolboid.eu/gomb-call-to-action-button/?ref=blog.fps.hu), a tartalmi linkek [következetesek legyenek](https://blog.kolboid.eu/kovetkezetes-design-consistent-consistency/?ref=blog.fps.hu)
- tudnia kell, hogy milyen felbontásra tervezzen (a fluid layoutokról és a responsive webdesignról ne is beszéljünk)
- érti, hogy a webdesignnak funkcionálisnak kell lennie

![Good design is good business. felirat](https://blog.fps.hu/content/images/2016/01/good-design.jpg)

### Milyen a jó webdesign?

- a jó design beszédes, segíti a fő üzenet megértését
- a jó design [pozitív érzelmi állapotot](https://blog.kolboid.eu/pozitiv-erzelmi-allapot/?ref=blog.fps.hu) alakít ki a felhasználóban
- a jó design elmeséli a felhasználónak, hogy az üzemeltető törődik a termékkel, szolgáltatással, arra áldoz
- a jó design elhiteti a felhasználóval, hogy az oldal jól működik (még akkor is, ha ez nem igaz)
- a jó design bizalmat épít
- a jó design mindenben segíti a használhatóságot
- a jó design vezeti és egyben tudatosan irányítja a szemet

Nézd meg ezt az ábrát, mert sajnos tükrözi a valóságot.

![Mennyire jó a design és mennyire tetszik függvény](https://blog.fps.hu/content/images/2016/01/ugyfel-designer.jpg)

Egyetlen megjegyzés ehhez: Kit érdekel, hogy az ügyfél, grafikus mennyire szereti az elkészült webdesignt? Nyilván sarkítok, de nem **a honlapot használó felhasználóknak** kellene, hogy **vizuális és funkcionális élményt nyújt**son?

*Update 2017\. május 2.*  
Végül nézd meg ezt az előadást, ami többek között arról mesél, hogy a szép arc, ergo a szépség az agy örömközpontját aktiválja:
### Webshopok mobil weben
URL: https://blog.fps.hu/webshopok-mobil-weben/
Last updated: 2026-07-17T08:56:37.000Z
A [Smartmobil 2012](http://smartmobilhq.hu/?ref=blog.fps.hu)\-es konferencián az m-commerce szekcióban tartottam előadást, melyről sokan kérdeztek, illetve kérték, hogy küldjem el a prezentációmat. Miután 10 perc állt rendelkezésre sok mindenről nem tudtam beszélni, így ebben a blog posztban kicsit bővebben fejtem ki gondolataimat.

### Miért kell mobil web, app a webshopodhoz?

1. a [Performics kutatásában](http://blog.performics.com/search/2012/02/mobile-search-surges-into-2012.html?ref=blog.fps.hu) (2012 január időszakra) a google mobilos fizetett kereséseket vizsgálták és arra a következtetésre jutottak, hogy a CTR (átkattintási arány) 45%-kal magasabb volt, mint desktop böngészők esetén
2. A [mobify 2011-es évi elemzésében](http://mashable.com/2012/02/16/mobile-commerce/?ref=blog.fps.hu) (nagyságrendileg 20 000! ecommerce site-ot vizsgáltak) az átlagos kosár méret desktopon $95.19, míg mobilon $96,92 volt, ez közel 2%-kal magasabb érték
3. a tableteket külön vizsgálta az [Adobe](http://success.adobe.com/en/na/programs/digital-marketing-insights.html?s%5Fcid=%2043341&ref=blog.fps.hu), kb. 150 oldal esetében, ahol az átlagos kosár érték desktopon $102, míg tableten $123 dollár volt
4. minden általunk kezelt oldalon 2% feletti a mobilról történő böngészés (vedd figyelembe azt is, hogy ezek az oldalak nincsenek optimalizálva mobil készülékekre)

![egy ember nyomkodja a mobilját fotó](https://blog.fps.hu/content/images/2016/01/unlock.jpg)

### Webshophoz mobil web vagy app?

Sokszor felmerül a kérdés, hogy milyen stratégiát válasszanak a webshop tulajdonosok, melyik útra lépjenek rá elsőként. Íme egy kis segítség a döntéshez.

1. [linkek nem appokat nyitnak!](http://blog.cloudfour.com/links-do-not-open-apps/?ref=blog.fps.hu) a webshopodra érkező látogatók nagy része SEO-ból (keresőből), különböző social media oldalakról (facebook, twitter, stb.) érkezik és nem az appba kerülnek, hanem a webshopra
2. egy friss [Nielsen kutatásból](http://blog.nielsen.com/nielsenwire/?p=31164&ref=blog.fps.hu) jól látszik, hogy majd kétszer annyian használják az világ öt legnagyobb ecommerce oldalait (Amazon, Best Buy, eBay, Target, Walmart), mint appon keresztül
3. a [zmags kutatásából](http://media.zmags.com/files/zmags-cc-survey-web.pdf?ref=blog.fps.hu) kiderül, hogy a vásárlók 4%-a vásárol appon (mobil és tablet) keresztül, míg mobil weben keresztül ez a szám már 14% mobilok esetén és 9% tabletek esetén

A fentiek alapján egyértelmű, hogy **mobilra optimalizált webshoppal** kell első körben foglalkoznod. Mindenképpen meg kell jegyeznem, hogy a mobil webnek sok előnye van az appokkal szemben:

- sokkal könnyebb a fejlesztés
- sokkal olcsóbb a fejlesztés
- a hibajavítás gyorsabb (az Apple-nél legalább leghamarabb 6 nap mire megjelenik a frissítésünk az AppStore-ban, Android esetében akár azonnal is, de akkor is elő kell állítani a csomagot és betolni, Windows Phone7-nél minimum 4 nap kell, hogy megjelenjen az update)

Jelenleg az appok korát éljük, de meggyőződésem, hogy hosszabb távon a mobil webé, a HTML5 appoké a jövő. Igen, pontosan tudom, hogy a mobil webes felhasználói élmény még nem igazi. Lassabb, ezáltal nem elég gördülékeny a működés, szemben a natív alkalmazásokkal, de a készülékek hihetetlen ütemű fejlődésével ez a különbség meg fog szűnni (gondolj csak a 2,4,8,16,32,… magos processzorokra) Azzal is tisztában vagyok, hogy HTML5-ön keresztül még nem érhető el az eszköz sok funkciója, úgy mint például a kamera. Még! A HTML5 munkacsoport (W3C) és a mobil böngészők fejlesztői rohamos ütemben fejlesztenek és nemsokára elérhetővé tesznek mindent a fejlesztők számára. Egy év múlva ezek a kérdések már nem fognak felmerülni senkiben, mert pont kerül a mondat végére.

![HTML5 vs. mobil operációs rendszerek illusztráció](https://blog.fps.hu/content/images/2016/01/html5vs.jpg)

### Resposive webdesign vagy sem?

A [responsive webdesign](http://designmodo.com/responsive-design-examples/?ref=blog.fps.hu) egy nagyon hasznos technológia, személy szerint nagy híve vagyok, de ecommerce site-ok esetében egyáltalán nem ajánlom a használatát, habár tervezői szemszögből egy szép kihívás. Webshopoknál a mobil és a desktop változatok elrendezése, megjelenítése, használata nagyon nagy mértékben eltér egymástól, így sokkal egyszerűbb egy külön mobil site tervezése és lefejlesztése. Az sem utolsó szempont, hogy responsive webdesign esetében a már meglévő webshopod újra kellene tervezni és át kellene alakítani, ami további költségeket jelentene számodra, amit nyilván nem akarsz.

### Mikor használják az emberek a mobil készüléket?

Mikor mobilra tervezünk, jó ha tisztában vagyunk azzal, hogy mikor és milyen körülmények között használják a felhasználók a készülékeket.

A [compete pulse-on közkinccsé tett tanulmány](http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/?ref=blog.fps.hu) szerint az alábbiak szerint használjuk mobilunkat:

- **84% – otthon**
- 80% – amikor épp van rá pár perc
- 74% – mikor várakozunk (villamos, metró, bank, találkozó)
- **69% – vásárlás közben**
- 64% – munka közben
- 62% – TV nézés közben

A webshopod számára kiemeltem a két legfontosabb pontot. Sokan nem is gondolnak arra, hogy az otthonainkban használjuk a mobilunkat a legtöbbet, reggelinél, a toaletten :), az ágyban, a kanapén stb.

Elég magas a vásárlás közbeni használat. Ez itt azt jelenti, hogy a felhasználó ott álldogál a boltban, előkapja a mobilját és megnézi az adott terméket és annak jellemzőit stb. (nyilván a boltban emailezünk, facebookozunk is, de ennek a mutatónak nem ezek a jellemzői). Éppen ezért tervezéskor feltétlen vedd figyelembe a keresési lehetőséget oldaladon, magyarán ki kell emelni a kereső mezőt!

Megállapítható még a fenti listából, hogy a mobilos felhasználókra úgy kell tekinteni, mint akinek egy szeme és egy ujja van. Mobilozás közben állandóan elveszítjük a fókuszt (elmegy mellettünk valaki, vagy valami, amire feltekintünk, vagy szól a gyerek, vagy a TV-ben valami érdekes történik stb.).

### Az ujjak és a tapintási terület

Nagyrészt egy ujjal, mégpedig a hüvelyk ujjunkkal használjuk a mobilt. A mobil operációs rendszerek fejlesztői kiadnak guideline-okat, amiben megmondják, hogy szerintük mekkora legyen a minimális tapintható felület. Nincs annál frusztrálóbb érzés, amikor nyomkodom az érintőképernyőt és nem történik semmi, mert nem tudom eltalálni azt a kicsi gombot, feliratot. Erre különösen ügyelni kell a webshopoknál is, mert itt nem babra megy a játék, az áhított konverziónk múlhat ilyen egyszerű dolgon.

![ujjak és méretek illusztráció](https://blog.fps.hu/content/images/2016/01/felulet.jpg)

Végeztek egy komoly [vizsgálatot az ujjakról és tapintható felületekről](http://uxdesign.smashingmagazine.com/2012/02/21/finger-friendly-design-ideal-mobile-touchscreen-target-sizes/?ref=blog.fps.hu), melyet a linken olvashatsz el. A lényeg, hogy az Apple ajánlása (44x44 pt) áll a legközelebb a kényelmesen tapintható mérethez, de az is kevesebb, mint amit a tanulmány szerzői ajánlanak, miszerint a gomb mérete legyen 45-57 pixel (16–20mm) közötti. Az egyes elemek között pedig minimum 2mm távolságot kell hagyni, hogy ne tapintsunk véletlenül másik elemre.

### Néhány tipp a webshop felépítéséhez

![mobilok mobilea optimalizált oldalakkal illusztráció](https://blog.fps.hu/content/images/2016/01/phone.jpg)

Könyveket lehet írni használhatósági (usability) szempontokról, tervezési alapelvekről. Most csak néhány tippet adok, inkább kérj fel és megtervezem neked.

- kereső mező felül legyen
- kosár, login jól látható helyre kerüljön
- aktuális akció, vagy kupon a főoldalon kiemelve
- használd a GeoLocationt (helyzet meghatározás GPS koordináták alapján) – pl. ha a bolt közelében van a felhasználó, akkor írd ki, hogy hány kilométerre van és ez a felirat legyen link google mapre, így ha viszonylag közel van a fizikai boltodhoz az akciót látva betérhet hozzád
- használd ki a gesture-ök adta lehetőségeket (az érintőképernyőn ujjal végezhető mozdulatok) – például a kosárból elem törlése (végighúzom az ujjam), képek lapozása
- legyen ott a bolt telefonszáma, mégpedig teljes formában (+36 1 333 4444), mert így a mobillal azonnal hívhatóvá válik

Még utolsó tippként ajánlom, hogy a logód mellé (legfelül) jobbra helyezz el egy menü nevű gombot (vagy egyszerűen csak egy lefele mutató nyilat), ami az adott oldal aljára vezet, ahol egy vissza a tetejére linkkel kezdődően a webshop teljes menüjét teheted elérhetővé (tégy ide is egy keresőt).

[Töltsd le a diákat](https://kolboid.eu/kolozsi-istvan-webshop-mobil-web.ppt?ref=blog.fps.hu "Töltsd le a prezentációt!")
### Most már tényleg eljött a mobil ideje?
URL: https://blog.fps.hu/mobil-web-vs-mobil-app/
Last updated: 2026-07-17T08:56:47.000Z
Az fps-nél van egy vezérelvünk a böngészők és verzióik támogatására. Abban a pillanatban, ha 2% alá esik valamely böngésző verzió, többé nem támogatjuk azt és nem foglalkozunk vele. No persze nem mindegy, hogy a 2% valójában mennyi felhasználót takar egy oldal esetében, viszont ha magyarországi viszonylatban tekintjük, akkor már nem számít soknak, egyébként mi a gemius és a stacounter adataira támaszkodunk.

Mindenki arról beszél, hogy a mobil így, a mobil úgy, okostelefonok, tabletek jelentik a jövőt. Biztos, hogy a jövő? Gyakorlatilag bármelyik oldalt nézzük, mindenhol 2% feletti a mobilról történő látogatás hónapok óta. Akkor miért nem foglalkozunk vele?

### Jelenidő

![fps web site mobilokon és tableten](https://blog.fps.hu/content/images/2016/01/eszkoz.jpg)

Most már nem az a kérdés, hogy szükség van mobil webre, mobil applikációra, hanem hogy ki tud a saját piacán minél hamarabb megjelenni az „új” platformokon. Az ügyfelek kerek szemekkel néznek rám, amikor erről beszélek és lazán legyintenek, hogy „jajj, az még messze van, az embereknek nincs pénze, hogy lesz ebből nekem hasznom, bla-bla-bla”

A tavalyi Media Hungary konferencián Mark Forster (Svájc) tartott előadást Smartphone Revolution in Switzerland címmel. Az ő gondolataival maradéktalanul egyetértek, miszerint a mobil fejlesztést nem szabad külön befektetésként kezelni, ami rövid- vagy középtávon biztosan megtérül, inkább a portfólió bővítéseként kell rá tekinteni. Ha most nem lépsz be erre a területre, akkor később veszíteni fogsz, és akkor mikor rádöbbensz a tényre, nagyon bánni fogod.

### Mobil web vs. mobil app?

Ez nem kérdés! Mindkettő! Naná, hogy a mobil webbel kell kezdeni, majd utána jöhetnek az appok is, tudom én ez nem A recept, akár fordítva is működhet, sőt lehet, hogy te most csak mobil applikációban gondolkodsz. Viszont azért olvasd el az alábbiakat és gondold végig miért is a mobil webbel kezdj.

![HTML5, iOS, Android logók](https://blog.fps.hu/content/images/2016/01/html5-ios-android.jpg)

### Linkek

A honlapodra, webshopodra, portálodra honnan érkeznek a felhasználók? Nagyrészt SEO-ból, esetleg a hírleveleidből és mind inkább különböző social oldalakról (mint Facebook, twitter és még sorolhatnám). Ezek a felhasználók mind linkeken keresztül érkeznek, melyek a webes megjelenésed valamely oldalát nyitják meg. Tudomásom szerint linkek nem nyitnak mobil applikációt, ugye? Beérkeznek az oldaladra, ami a mobil eszközükön lassan töltődik be, nehezen kezelhető, rossz esetben egyáltalán nem használható, ergo lelépnek. Szerintem tedd őket boldoggá azzal, hogy mobilra optimalizálod web site-od. Nyilván a direkt látogatás most nem érdekes ebből a szempontból, mert ők már a te fogyasztóid (nekik kell majd az appot készíteni).

### Figyeld az amerikai piac alakulását!

![kislány szép szemei fotó](https://blog.fps.hu/content/images/2016/01/l-ny.jpg)

Érdemes figyelned az amerikai piac történéseit, nagyjából ugyanaz fog történni itt is. Azt látni, hogy mobil webről és applikációból nagyobb a vásárlási hajlandóság, mint a desktop böngészőkből. A kettő közül a mobil web erősen kezd elhúzni (pl. amazon). A Financial Times pedig meg is szüntette a natív applikációját és inkább [HTML5 mobil webet fejleszt](http://www.readwriteweb.com/archives/financial%5Ftimes%5Fproves%5Fhtml5%5Fcan%5Fbeat%5Fnative%5Fmobil.php?ref=blog.fps.hu).

### HTML5 vs. natív

Most még azt mondják, hogy a mobil web lassabb és nehézkesebb, nem elég gördülékeny a natív mobil applikációkhoz képest. A [HTML5](http://hu.wikipedia.org/wiki/HTML5?ref=blog.fps.hu) és lehetőségeit kihasználva nagyon jó élményt lehet varázsolni a mobil eszközökre és nem adok neki egy évet, olyan eszközök lesznek az emberek kezében, melyek már olyan sebességgel bírnak majd, melyeken nem veszed észre a különbséget a natív applikációkhoz képest.

### Új felhasználók a láthatáron

![ember árnyéka fotórészlet](https://blog.fps.hu/content/images/2016/01/arnyek.jpg)

Új embereket érhetsz el! Csak gondolj bele, hány és hány olyan ember van közöttünk, aki egyszerűen nem tud megbarátkozni a „hagyományos” számítógépekkel (desktop, laptop stb.) és soha nem is fogja azokat használni, mert egyszerűen nem akarja megtanulni a windows, linux, mac OS nyűgjeit. Viszont ezek az emberek kezükbe kapnak egy érintőképernyős készüléket legyen az mobil, vagy tablet és egyszerűen csak használják azokat. Az érintőképernyő egy olyan „újítás”, ami emberközelivé, természetessé teszi a digitális világ elérését. Ha nem csinálsz mobil webet, akkor ezekről az emberekről egyszerűen lemondasz!

### Responsive webdesign

Ha most csináltatsz új web site-ot magadnak, akkor ajánlom figyelmedbe a responsive webdesign technológiát. Gyakorlatilag arról van szó, hogy az oldalad a kezdetektől úgy tervezik és fejlesztik, hogy az „minden” eszközre idomul. Hogy jobban megértsd, mire gondolok, nyisd meg a honlapunkat [www.fps.hu](https://www.fps.hu/?ref=blog.fps.hu) a böngésződben, majd az ablakot méretezd át. (ha mobilról olvasod ezt a cikket, akkor bizonyára már feltűnt, hogy optimalizáltuk ezt a blogot is) Sok jó példát találsz a [http://mediaqueri.es/](http://mediaqueri.es/?ref=blog.fps.hu) oldalon is.

**Csak egyet mondhatok: azonnal kezdd el fejlesztetni a mobilra optimalizált oldalad, mert már most késő!**

**Olvass a témában**

- [Mobile Web App vs. Native App? It’s Complicated](http://www.forbes.com/sites/fredcavazza/2011/09/27/mobile-web-app-vs-native-app-its-complicated/?ref=blog.fps.hu)
- [Native App vs. Web App: Which Is Better for Mobile Commerce?](http://mashable.com/2011/05/23/mobile-commerce-apps/?ref=blog.fps.hu)
- [Mobile Web Use vs. Mobile App Use](http://www.lukew.com/ff/entry.asp?1413&ref=blog.fps.hu)
### Többnyelvű honlapok készítése
URL: https://blog.fps.hu/honlapok-nyelvesitese/
Last updated: 2026-07-17T08:56:59.000Z
A webfejlesztők számára nincs borzasztóbb feladat, mint nyelvesíteni egy honlapot. Hogy miért is van ez? Ezt a témát járom most körbe és fejtem ki a véleményem.

### Nyelvválasztó

Kezdjük azzal, hogy felhasználóbarát módon kell megjeleníteni a nyelv választására szolgáló elemet. Egyáltalán nem jó ötlet, ha zászlókat használunk erre a célra. Ugyan jól mutatnak és kevés helyet is foglalnak a kis zászlócskák, de problémákat is okozhatnak. Érdemes belegondolni, hogy pl. német nyelv esetén milyen zászlót tegyünk ki? A német zászlót? Biztos, hogy fog ennek örülni egy osztrák?

Amíg néhány nyelvről van szó a legjobb megoldás, ha kiírjuk a nyelveket egymás után (vagy a nyelv kódokat) és igen mindig a saját nyelvén. A német, aki a magyar oldalra érkezik németül akarja látni és úgy is tudja értelmezni a feliratot (számára az, hogy magyar | német semmit sem fog mondani) Ezt csak azért írom le, mert elég sok helyen láttam már ilyen megoldást.

![magyar | english | deutsch feliratok](https://blog.fps.hu/content/images/2016/01/nyelvvalaszto.jpg)

Ha teheted, akkor valósítsd meg az igazi nyelvek közötti váltást! Arra gondolok, hogy ha egy adott tartalmon állok, akkor nyelv váltáskor ugyanazon oldal lokalizált változatára kerüljek. Tudom, nehéz ezt megoldani, de akkor is. 

#### Mi van akkor, ha sok nyelvet kell megjeleníteni és nincs hely?

Sajnos nincs egységes szimbólum a nyelv választóra. Ugyan van egy kezdeményezés az univerzális ikon létrehozására ([http://www.languageicon.org/](http://www.languageicon.org/?ref=blog.fps.hu)), de a jelenlegi jel elég semmitmondó. Fut egy verseny is, aminek egy ilyen ikon létrehozása a célja. 2012\. március 22-én jár le a határidő, meglátjuk mi sül ki belőle, addig is nézd meg a beérkezett pályamunkákat és szavazz: [http://www.adesignaward.com/vote.php?CID=1001](http://www.adesignaward.com/vote.php?CID=1001&ref=blog.fps.hu)

Jó lenne ilyen ikon, de nincs. :( Akkor hogyan oldjuk meg? Személy szerint azt javaslom, hogy egy kicsi földgömb, vagy kiterített föld térkép ikont használjunk és egy select mezőt, valahogy így:

![choose language példa képernyőkép](https://blog.fps.hu/content/images/2016/01/valassz-2.jpg)

#### Hova helyezzük a nyelvválasztót?

Mindenképpen látható helyre! Erre a célra az oldalunk jobb felső sarka a lehető legjobb választás, de jó megoldás az is, ha a menüpontok elejére tesszük. Sok helyen a láblécben található a választó (ki találja meg?), illetve első belépéskor a nyelvválasztás jelenik meg és csak utána tudunk tovább lépni a tartalomhoz. Ez utóbbi egy world-wide szintű cégnél még beleférhet, de minden más esetben csak felesleges lépésre kényszeríti a felhasználókat, akik nagy valószínűséggel nem lesznek türelmesek és tovább állnak.

#### Automatikus átirányítás és süti

Jó és kötelező megoldás, hogy a felhasználót első belépéskor automatikusan átirányítjuk a böngésző nyelve szerint. Ettől függően a nyelvválasztóra továbbra is szükség van, mert pl. több ismerősöm angol nyelvű böngészőt használ, vagy éppen külföldön tartózkodáskor egy helyi eszközt használva nem a megfelelő nyelvre irányít ez a megoldás. Arra is figyelni kell, hogy csak első belépéskor irányítsunk (cookie), mert különben nem tudnak váltogatni a nyelvek között.

#### Óvatosan az átirányítással!

Két lehetőségünk van az automatikus átirányításra:

- szerver oldalon (web szerver – pl. .htaccess, szerveroldali nyelv – pl. php, asp .net stb.)
- kliens oldalon (JavaScript)

**Mindkét változat alkalmazható, de oda kell figyelni a SEO-ra!**

Jön a kereső bot (pl. Google) és mi átirányítjuk az angol oldalra mindig? Akkor hogyan fogja leindexelni pl. a magyar, vagy más tartalmat?

Ha szerver oldalon akarsz irányítani, akkor szükséged van egy listára, ami tartalmazza az összes kereső bot „user agent”-jét, hogy botok esetén ne irányíts és persze ezt a listát folyamatosan karban is kell tartanod. [http://www.user-agents.org/](http://www.user-agents.org/?ref=blog.fps.hu)

A legegyszerűbb és legjobb megoldás a JavaScript használata, mert ugyebár a botok azt nem futtatják (habár mostanság már kisebb kódokat képesek lefuttatni, de még nem veszélyezteti az átirányításokat).

Most, hogy van felhasználóbarát nyelvválasztónk, nézzük mit is kell fordítani.

### Miért olyan bonyolult egy honlap nyelvesítése? Mit is kell fordítani?

![kaktusz fotórészlet](https://blog.fps.hu/content/images/2016/01/kaktusz.jpg)

A honlap üzemeltetői azt gondolják, hogy egyszerű folyamat ez, elküldjük a szövegeket a fordítónak, az visszaküldi és végül a fejlesztők létrehozzák a nyelvesített oldal(aka)t. Hát nem.

Először is tisztázni kell a honlap tulajdonosával az alábbi kérdéseket:

- tényleg szükség van 12 nyelvre? mi is a célja a nyelvesített honlapoknak?
- mely oldalakat kell mindenképpen megjeleníteni a lokalizált honlapon?
- lesz rá ember, hogy a nyelvesített oldalakat is frissítse, karbantartsa?
- milyen dinamikus tartalmakat akar feltétlenül frissíteni a CMS-en keresztül?

Sok esetben tapasztalom, hogy kell a honlap ilyen-olyan nyelven, majd mikor felteszem a kérdést, hogy mi a célja, akkor mély csend a válasz. Biztos, hogy szükség van az angol mellett német oldalra is, ha nem kimondottan Németország, Ausztria a célközönség? (a németek nagyon magas arányban jól beszélik az angolt).

Hívd fel az ügyfél figyelmét a lokalizáció viszonylag magas költségeire és a később vele járó sok-sok munkára és máris egyszerűsödik a feladat!

Nézzük meg sorjában milyen jellegű tartalmakat kell fordítani és azok hogyan, hol lehetnek tárolva és milyen kérdések merülhetnek fel.

- oldalak beállításai (SEO – title, meta tagek, URL)
- adatbázisokban tárolt szövegek
- statikus tartalmak
- feliratok, különböző üzenetek
- email sablonok
- képek
- letölthető anyagok
- területi beállítások (dátum, pénznem stb.)
- szállítási költség
- fizetési módok
- stb.

Az első lépés, hogy a jól keresőoptimalizált oldal lehetőleg minimális mértékben, de optimalizált legyen az új nyelv(ek)en is, ezért ki kell gyűjteni az összes fordítandó oldal címét, meta adatait, SEO URL-ét (pl. domain.hu/**seo-url/**). Ez általában egy excel, vagy calc táblázatba kerül.

Érdekesség, hogy a keretrendszernek le kell kezelnie a különböző nyelvek karaktereinek latin abc-re való konvertálását. Így pl. az Érdekességek szövegből /erdekessegek URL rész lesz. Még ez a magyar nyelvnél viszonylag egyértelmű, a cirill karaktereknél már számos egyediséggel kell számolni.

#### Adatbázisok

Következő lépésekben meg kell vizsgálni mit és hogyan tárolunk adatbázis(ok)ban. Itt felmerülhet az adatbázisok bármelyik típusa, akár egyidejűleg is, pl. MySQL, PostgreSQL, CouchDB stb.)

![CMS-en a különböző nyelveknek külön mező van képernyőfotó](https://blog.fps.hu/content/images/2016/01/galeriac-mek.jpg)

Ide tartozhatnak a cikk, blog jellegű tartalmak, de a webshop kategóriái, termékei, a címkék és még sorolhatnám reggelig. Az adatbázisban tárolás hátránya, hogy a CMS-t fel kell készíteni a többnyelvűségre, azaz felvitelkor, módosításkor a megfelelő űrlapokon szükség van a legtöbb mező más nyelven történő szerkesztésére is. Mindemellett a honlapon megjelenítéskor a kódnak figyelembe kell vennie a nyelvet és az éppen választottat kell megjelenítenie az adatbázisból. Általában itt van a legtöbb probléma, mert akár open source, akár saját fejlesztésű keretrendszert használsz, mindig lesz olyan pont, ahol fejleszteni kell a rendszert. Ha végre pontosan feltérképezted az adatbázisban tárolt adatokat, akkor abból kell egy exportot csinálni, mely szintúgy általában xls, vagy calc formátumot eredményez. (arra is ügyelj, hogy ezt vissza is kell majd töltened – import)

#### Statikus tartalmak

Talán ezzel van a legkevesebb gond. Nagyrészt html fájlokban tárolt tartalom, melyet word, vagy open document formátumba gyűjtünk ki.

#### Feliratok, különböző üzenetek

A keretrendszer (open source, saját fejlesztés) rendelkezik beépített feliratokkal, üzenetekkel (hiba és siker, vagy figyelmeztető). Emellett a különböző űrlapoknál szerepelnek címkék (mező név), placeholderek (pl. mezőben segítség szöveg), feliratok (pl. minden mező kitöltése kötelező), gomb nevek, visszajelző üzenetek stb. Ezek egy „okos” rendszerben majd mindenhol ún. po vagy ini fájlokban vannak tárolva.

[http://en.wikipedia.org/wiki/Gettext](http://en.wikipedia.org/wiki/Gettext?ref=blog.fps.hu)  
[http://www.poedit.net/](http://www.poedit.net/?ref=blog.fps.hu)

![Hibaüzenetre példakép](https://blog.fps.hu/content/images/2016/01/email-2.jpg)

Példának okáért a Joomla ini, a WordPress és a Drupal, csakúgy mint a saját rendszerünk (feracotta) po fájlokat használ.

#### Email sablonok

Minden honlap küld legalább egy esetben emailt. Ennek az emailnek van egy designja (hacsak nem plain text), illetve tartalma. Egyszerűbb esetben ezt a keretrendszer küldi ki és a CMS-en létrehozható a nyelvi változat, bonyolultabb esetben viszont egy külső hírlevélküldő alkalmazást használ a honlap (pl. mailchimp, oempro, webgalamb stb.).

#### Képek

Nyelvesítéskor rendszerint elfelejtődik, pedig komoly munkát igényel. A honlapokon sokszor szerepelnek saját hirdetések, melyek a „szép design” miatt kép formájában lettek megvalósítva. Az ilyen jellegű szövegeteket egy külön dokumentumba kell kigyűjteni, majd fordítás után legyártani a nyelvesített változatokat és feltölteni a lokalizált honlapra.

#### Letölthető anyagok

Ezekre is csak később szoktak gondolni. A szuper dokumentumtár, illetve tanúsítványok stb. szintén szükségeltetnek az új nyelveken is.

#### Területi beállítások

Bizony, bizony. Minden ország és nyelv saját területi beállításokkal rendelkezik. A dátumformátumot különböző módon írják a nemzetek, de más a pénznem is. A pénznemnél érdemes megállni és töprengeni egy kicsit. Vajon a webshop termékeink árait más országokban milyen pénznemben és összeggel mutassuk? Egyáltalán nem biztos, hogy a lengyeleknél zlotyi lesz a pénznem, lehet ott Euró alapon akarjuk a vásárlást, nem? Ilyenkor felvetődik még számos fejlesztési kérdés is, pl. automatikusan váltsa a rendszer az árakat valutára, vagy külön szeretnénk tárolni?

A szállítási költség és a fizetési módok is érdekesek. Nyilván külföldre utánvéttel küldve a szállítási költség sokkal magasabb lesz, tehát országonként le kell tárolni egy új költséget minden pénznemben. Nyilván PayPal esetén nem lesz probléma a fizetési móddal, de a CIB-es, K&H-s, vagy OTP-s bankkártyás fizetés megfelelő lesz külföldön is? (megfelelő lehet, de tudd, hogy ezek a rendszerek Forint alapon dolgoznak és tájékoztató jelleggel automatikusan váltják az Eurót és jelenítik meg)

### Fordítandó anyagok összeállítása

Minden esetben, amikor létrehozod a dokumentumokat és abba fordítandó szövegeket öntesz, **használj jelölőket!** (sárga háttérrel pl.) Mind tudjuk, hogy a webfejlesztők nagy százalékban bírják az angol nyelvet, de mi van ha lengyel, vagy ne adj Isten ukrán nyelvre történik a lokalizáció. Ki tudja majd, hogy a fordítótól visszaérkezett dokumentumban melyik szöveg hova tartozik?

A dokumentumokba illeszd meg az adott tartalom URL-jét, hogy a fordító meg tudja nézni, hogy hova kerül majd a fordítása.

Minden anyagot a megfelelő formátumban kigyűjtöttünk, készen állunk arra, hogy elküldjük a fordítónak. Ne felejtsd jelezni a fordítónak, hogy a jelöléseid hagyja benne a dokumentumokban, azokat ne fordítsa le és minden esetben ügyeljen a formázásra (az eredetinek feleljen meg).

### Együttműködés a fordítóval!

![két kéz egymásba fonódva fotórészlet](https://blog.fps.hu/content/images/2016/01/tumblr_m0zt00XCe81r105v8.png)

Nehéz a fordítókkal! A fordítók wordben szeretnek dolgozni, ahol bekezdésenként haladnak és ugyanabban a dokumentumban dolgoznak, hogy egyben lássák a fordítandó szöveget és magát a készülő fordítást. Ebből kifolyólag kimondottan nem szeretik a po, az XML, az xls stb. formátumokat. Ráadásul a fordítók karakterszám alapján számolnak és aszerint adnak ajánlatot is. Egy po, vagy ini fájlból nehéz karakterszámot számolni!

**Az elején tisztázd, hogy UTF-8 karakterkódolást kell használni!**

#### Fontos a folyamatos kapcsolattartás!

- meg kell ismertetni őket a behelyettesítő kifejezésekkel. az email sablonokban, po file-okban sok helyütt szerepelnek ún. behelyettesítő kifejezések.  
pl. „Kedves %s!” – ahol a %s egy sztring és nyilvánvalóan egy név kerül a helyére.  
Persze nem minden esetben ilyen egyértelmű a kulcs, ezért sokszor fog kérdezni a fordító.
- gomb nevek, feliratok – sok esetben fogalma sincs a fordítónak, hogy hol jelenik meg, milyen szövegkörnyezetben a fordítás, ezért jó ha folyamatosan kérdez, ha nem biztos a dolgában.  
Volt olyan esetünk, amikor a CANCEL gomb feliratát TÖRLÉS-nek fordították és a megjelenő dialógus ablak alján a következő gombok szerepeltek: \[MÓDOSÍTÁS\] \[TÖRLÉS\]  
Szerencsétlen felhasználó sehova sem mert így kattintani. ;)
- a fordítónak ügyelnie kell arra, hogy a fordított szöveg hasonló méretű legyen, mint az eredeti szöveg. ez különösen fontos lehet menüpontok, gomb nevek esetében, később sok munkát spórolhatsz meg (egyedi CSS módosítgatások, stb.)!

### Mindig kimarad valami!

De tényleg! Nem volt még olyan projektünk, ahol a végén ne derült volna ki, hogy ez, meg az kimaradt, illetve hogy még fejleszteni kell a rendszeren, mert senki sem gondolt arra hogy…

Higgy nekem, nem lehet senki sem annyira alapos, hogy egy ilyen bonyolultnak mondható feladatnál mindenre előre gondoljon.

![játékszőnyeg fotó](https://blog.fps.hu/content/images/2016/01/tumblr_m0zu1zVpeM1r105v8.png)

A fentiekből egyenesen következik, hogy több nyelvre történő lokalizáció esetén először ajánlott egy nyelvvel kezdeni. Ha lehetséges, akkor ez legyen az angol nyelv. Az első folyamatban fény derül minden hiányosságra, azokat lehet pótolni és utána már könnyedén eshetsz neki a többi nyelvnek.

### Indulhat a lapátolás!

Visszaérkezett a fordítótól minden anyag, el is lehet kezdeni a kulimunkát:

- a nyelvi változat teljes URL struktúra felépítése
- kopipészt, kopipészt és még mindig kopipészt
- kisebb CSS módosítások
- scriptek (kis programok) írása a dinamikus adatok betöltéséhez
- ellenőrzés, ellenőrzés még egyszer
- stb.

### A honlap tulajdonosa felé mit kommunikálj?

A nyelvesítés folyamata alatt

- NE módosítson, módosíttasson semmilyen tartalmat
- NE kérje új anyagok feltöltését
- NE indítson semmilyen promóciót
- LEGYEN TÜRELEMMEL! :)

### Konklúzió

Tervezz, kommunikálj! Olvastasd el az ügyfeleddel ezt a cikket, hogy megértse mekkora feladat a nyelvesítés, ülj le vele többször is és alaposan beszéljétek át mire is van szüksége pontosan. Aztán pedig hadd szóljon!
### Evolution 2012 konferencia mobile app teszt elemzés
URL: https://blog.fps.hu/evolution-2012-konferencia-mobile-app-teszt/
Last updated: 2026-07-17T08:57:11.000Z
A kedden (2012\. február 28-án) megrendezett Evolution 2012 konferenciához ([www.evolution.hu](https://www.evolution.hu/?ref=blog.fps.hu)) készítettünk mobil applikációkat iOS és Android oprendszerek alá. Az iOS verzióban futott egy jó kis kód, amivel hőtérképes elemzést készítettünk, amit most ebben a blog posztban osztunk meg veletek.

Az elemzés során kizárólag az előadások view-ra tettük a „figyelő” kódot, ezért alábbi képek és minimál statisztikai adatok erre a nézetre vonatkoznak.

### Statisztikai adatok

Összesen 202 sessiont rögzítettünk, 384 érintést (tappolást :)) és 1798 egy újjal történt swipe gesture-t, amiből 14 bal, 13 jobb, 496 felfelé, 1275 lefelé irányban történt.

Az app jelenleg csak portrait (álló) móddal rendelkezik ennek ellenére 26-an megpróbálták a landscape (fekvő) módot, nem sok sikerrel. Ez utóbbi 11%-a volt a rögzített sessionöknek, ebből is látszik, hogy nem feltétlenül szükséges foglalkozni a fekvő móddal ennél(!) az appnál. Érdekességképpen 6-an kipróbálták, hogy a shake (rázás) hatására történik valami, vagy sem. (nem :))

Az alábbi két kép mutatja a hőtérképet, első esetben az első érintésre, a második az összesített hőtérképet mutatja.

![mobilos hőtérképek](https://blog.fps.hu/content/images/2016/01/erintes.jpg)

### Konklúzió

- várakozásnak megfelelt, hogy a teremre való szűrést használják a felhasználók és meg is találják elsőre gond nélkül
- nem szükséges a landscape mód ennél az appnál
- érdemes jobb és bal swipe gesture-re a kedvencek közé tételt rákötni
- minden view-ra bepakolni az elemzést a következő appba :D
- mindig tesztlejünk, teszteljünk és legyen a USER BOLDOG!
### fps brand evolúció ;)
URL: https://blog.fps.hu/fps-brand-evolucio/
Last updated: 2026-07-17T08:57:22.000Z
fps brand evolúció ;)

![2001–től 2011-ig az fps logó változatai](https://blog.fps.hu/content/images/2016/01/brand.jpg)
### Díjak
URL: https://blog.fps.hu/dijak/
Last updated: 2026-07-17T08:57:30.000Z
![fps díjak 2008-2014](https://blog.fps.hu/content/images/2016/01/dijak.jpg)