CoderGirls

A UI design ereje

A UI design ereje

Olvasási idő: 3 perc

ui-blog.png

Szerepkörök, feladatok, és felhasználói igények

A UI mint „user interface”, a felhasználói felület tervezését jelenti. UI design esetében nem grafikusi munkáról van szó.

A cél túlmutat egy felhasználó-barát felület megtervezésén, a UI design veleje a megtervezett felület vonzó tálalásában rejlik.

 

Ki a UI designer és mi a szakterülete?

A UI szakember követi az aktuális design trendeket. Megtervezi a felhasználói felületeket, valamint animációkat és illusztrációkat hoz létre, amivel elősegíti az alkalmazás felhasználói élményben gazdag használatát.

A UI szakember

  • ismeri a felhasználói igényeket,
  • tervezés során felel az egységes megjelenés kialakításáért, mely érinti az animációkat, ikonokat, tipográfiát, illetve a fotókat is.
  • hatásköre továbbá a színvilág megtervezése az adott felületen,

legyen szó akár mobil app-ról, akár weboldalról.

Hogy szemléltessük a folyamatot, két igen különböző példát mutatunk be. Eltérő elvárások fogalmazódnak meg egy ipari környezetben használatos cél alkalmazás esetében, és más egy potenciális vásárlókat célzó fogyasztást ösztönző applikáció felületénél.

 

Törekedj az egyensúlyra

Egy gyári környezetben, egyszerűen a funkcionalitás és az iparági adottságok miatt elengedhetetlen a tervezett felület átlátható és egyszerű kezelése. Figyelembe kell vennünk olyan speciális munkakörülményeket, mint a

  • könnyű por képződés,
  • a kedvezőtlen fényviszonyok, vagy
  • a felhasználó védelmi öltözéke, például munkakesztyű használata.

 

Ellenben, a fogyasztói alkalmazások tervezésekor a megkapó vizuális élmény határozottan erőteljesebb hangsúlyt kap, így a UI designernek kiemelt figyelmet kell fordítania az aktuális trendek alkalmazására. A képi elemek tekintetében, - a célcsoport kiszolgálása érdekében -, nagyobb a tervező szabadsága, alkalmazhat:

  • animációt,
  • illusztrációs komponenseket,
  • sőt még humort is

a szegmens igényeinek megfelelően.

Fontos azonban a felhasználhatóság és a látvány közti egyensúly megteremtése, és annak fenntartása a teljes user journey (felhasználói útvonal) alatt.
A felsoroltak alapja azonban egy jól megtervezett UX design. A maradéktalan felhasználói élményhez kulcsfontosságú a két terület (UX & UI) összehangolt munkája.

Egy alkalmazás hibátlan megjelenése nem ellensúlyozza annak használatbéli hiányosságait. Ezen állítás fordítottja is igaz, egy jól átgondolt UX design, az alkalmazás könnyed használata nem váltja ki a felület megtervezéséhez szükséges UI kompetenciák alkalmazását. 

Természetesen a fejlesztők szerepe kihagyhatatlan egy, - a megrendelő számára -, jól működő alkalmazás, vagy szoftver készítésében. Termékünk azonban abban az esetben lesz valóban piacképes, ha azt felhasználói szinten öröm és élmény kezelni.

Ennélfogva minden projekt tervezésénél fordítsunk kiemelt figyelmet a UX-UI design folyamatok beépítésére, így igazi versenyelőnyre tehetünk szert.

 


 

A UX-UI design folyamat alkalmazása elemi üzleti érdek. A felgyorsult digitális transzformáció korában az lép előre, aki, - a user számára -, a leginkább felhasználóbarát, megnyerő és piacképes megoldást szállítja.

Forrás: Autsoft - Buday Mihály ( UI & UX designer )

A UI design ereje Tovább
Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack

Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack

Webfejlesztésnél, kliens és szerveroldalon mi történik?

full-stack-development-main.jpg

Elkezdett érdekelni a programozás világa, de még nem ismered ki magad a fogalmak között? Lehet hogy már tudatosult benned mivel akarsz foglalkozni, de még mai napig több forrásból hallasz kusza információkat egyes szakszavakkal kapcsolatban? Esetleg szimplán kiváncsi vagy, mert nem tudod merre az arra, és szeretnél letisztultabban látni a jövőddel kapcsolatban? Akkor jó helyen jársz, hiszen most egy tapasztalati és szorgalmas utánakeresős, érdeklődő cikket fogsz olvasni tőlem! 

Nagyon sokan dolgozunk azon, hogy amit a felhasználók látnak és tapasztalnak, megfelelően nézzen ki és működjön minden egyes alkalommal. 

Frontend fejlesztő v.1.: Sitebuilder 

A frontend szó jelentése elülső, szemből nézett elsőre nem sokat mondd a szakmáről, miért is van köze a fejlesztéshez, programozáshoz. De ha úgy mondom, hogy most is egy ilyen felületet nézel, akkor talán jobban megérted, mit is csinálhat egy ilyen szakember. Ez az a terület, mely a legközelebb áll a felhasználókhoz, a frontend az IT rendszerek legfelsőbb rétege. Ezt látod, ha felmész egy weboldalra, amikor ráviszed az egeret egy gombra és elváltozik a színe, ezzel is foglalkozik, de persze ez csak egy kis részterülete a szakmának, ezt nevezzük sitebuilder munkának. site = oldal builder = építő, amikor felépítjük a weboldal elemeit HTML vázzal és amikor stílust adunk az oldalunknak CSS-el, SCSS-el stb. ill. amikor az alap funkciókat JavaScript segítségével leprogramozzuk. 

Az igazi Frontend fejlesztő tehát nem csak programozási feladatokat képes ellátni, hanem annak a részegységeit is.

Frontend fejlesztő: 

A frontend fejlesztő az a személy, aki a sitebuilder képességeit profi szintre emeli, és ezt alkalmazza egy felhő alapú rendszer vagy magasabb komplexitású weboldal létrehozásához, kódolásához. A frontend fejlesztő, ahogy a sitebuilder is kap egy design tervet, az oldal vagy webes applikáció grafikai tervét, és ehhez megírja a kódot. Általában kkv szektorban a frontend fejlesztők sitebuilderek is egyben, mivel kis cégnél nem fognak megfizetni két embert ezeknek a feladatoknak az ellátására. Nagyobb cégeknél és multiknál már ezeket külön szedték, de léteznek olyan nagyobb cégek is, melyeknél valaki 8 órában csak Html-t és CSS-t ír, és valaki csak JavaScriptet, vagy csak valamilyen js keretrendszerben programozza a funkcionalitást, modulárisan létrehozva azokat az elemeket amik rá vannak bízva. 

Tehát a Frontend fejlesztés nem áll meg a HTML, CSS, és JavaScript együttesénél, és nem csak pixeltologatások vannak, meg gombok előreugrását kódolja le. Ezelőtt 6-7 évvel ha valaki ezeket tudta profi szinten elég volt az életben maradáshoz és a piacon való értéke sem volt kevés. Ma már ez nem igaz. Ha valaki igazi frontendes akar lenni, akkor nem elég csak ezekhez jól értenie. Ezeken kivűl használunk valamilyen JavaScript keretrendszert, a 3 legnépszerübb a React.js, Angular.js, Vue.js. Melyek már komolyabb applikációk, weboldalak, rendszerek programozásához szükséges skillek. Itt  már nem arról szól a történet, hogy HTML + CSS + JS-t ír a fejlesztő, itt már az adott termék funkcionalitását írja meg főként, és kevesebb HTML + CSS tudást igénylő a feladat. 

Dolgoztam olyan cégnél, ahol pár frontend fejlesztő alap html készségeit évekig nem használta, vagy csak alapból nem jól tanulta meg és (nem érdekelte hogy mélyebben utána nézzen, vagy csak hamar beszippantotta a munkaerőpiac) ezeknek a hatására én, mint junior amikor oda kerültem is tudtam új dolgokat mutatni nekik. Ebből a tanulság az, hogy egy igazi frontend fejlesztőnek a sitebuilder képességeinek ugyanannyira jónak kell lennie, mint annak, hogy jól programozzon le egy Üzenetek modult egy webes applikációban. 

Mik azok a JS keretrendszerek? Miért terjedtek el? Mire jók nekünk? React.js, Angular.js, Vue.js.

Itt most technikai eltérésekbe és VS játékokba nem mennék bele, ha valaki nem kezdő és érdekel a téma, vagy ha kezdő vagy és sztahanovista révén imádod terhelni az agyad itt egy jó kis cikk ezzel kapcsolatban angolul: Összehasonlítás más keretrendszerekkel.

vue.jpg

A JS keretrendszerek frontend technológiák, amik az alkalmazás fejlesztését szolgáló szabályok gyűjteménye. Ezen szabályok nagyon sokfélék lehetnek, vannak előre megírt keretrendszerek, amelyeket tipikusan egy fejlesztői közösség dolgozott ki pl a Google, és talált megfelelőnek, de keretrendszert egy fejlesztő maga is kidolgozhat, ezek a saját keretrendszerek (framework-ök). Csak itt, ha a fejlesztő nem követ bizonyos modelleket, akkor a végén nem tudhatjuk mire is gondolt a költő.

Ezekről a tervezési mintákról és modellekről majd egy másik cikkben teszek említést. Kicsit leegyszerűsitve a dolgot, a JS keretrendszerek által kevesebb a spagetti kód és mert mindennek megvan a helye, komponensekben gondolkozunk és a szabályaik, elveik szerint kódolunk.

Ezeket a kódolási standardokat minden fejlesztő ismerni fogja, és ha véletlenül Gipsz Jakab lelép a cégtől, akkor könnyedén találunk a helyére embert, mert nem a nativ JS-es kódját, vagy a Jquery-s (JavaScript könyvtár) x-soros kódját kell kihámoznia. Ez által az egységesség által pedig a kód is ujrafelhasználhatóvá válik más projektekben is, és átlathatóbb is lesz. Nyilván nem minden projekt esetében használjuk ezeket, hiszen ágyuval verébre nem igazán jó lőni.  Mindegyik technológiának vannak előnyös és kevésbé kedvelt tulajdonságai. Amit minden esetben szem előtt kell tartani, mikor letesszük a voksunkat egyik vagy másik mellett. Mindig az adott feladathoz, projekthez, problémamegoldásához választunk nyelvet és technológiát, és nem forditva. :)

React, Angular vagy Vue.js – frontend framework esetén ők a „piacvezetők”, és a „legjobbak”. 
Pár szóban róluk:

Ha sorrendbe kellene tennem őket véleményem szerint ma ami legkeresettebb a React, utána tenném az Angulart, és a végére a Vue.js-t. Én se értek mind a 3-hoz hozzáteszem, én a Vue-vel kezdtem el, nekem az könnyebb volt kisebb feladatokra bizonyos webes alkalmazásoknál. De én is szeretnék pl. Reactot tanulni, már jelentkeztem is egy céghez projektmunkára, ahol tanulni is tudnék React-ot és Vue-t együtt. A Reactról mindenki tudja, hogy a Facebook nyelve, az Angular a Google gyermeke, a Vue-t Evan You hozta létre, miután számos projektben a Google-nél dolgozott az AngularJS használatával. 

React kiemelve pár szóban


Azért emelném ezt ki jobban, mert mostanában kb. a csapból is ez folyik ha Frontendes állást látok, ill. a barátaim és a Mentorom és jobarátom Milán is ezt emelte ki nekem. A Reactot a Facebook fejlesztette ki 7 évvel ezelőtt, pontosabban Jordan Walke, a Facebook szoftvermérnöke készítette. A react egyik cikkjében, melyet 2013-ban publikáltak egy kérdéssel indul el a cikk, amely magyarul igy hangzik: 

Nagyon sok JavaScript MVC keretrendszer létezik. Miért építettük a React-et, és miért akarod használni?

Nos a cikkben ami nekem  személy szerint a legfontosabb szempont és ami a legjobban is tetszik: 

Reactive updates are dead simple. React really shines when your data changes over time.
(A reaktív frissítések rendkívül egyszerűek. A React igazán ragyogó, amikor adatok idővel változnak.)

Ha érdekel a cikk, angolul eléred az oldalukon: Why did we build React?

Most itt a kezdőknek szóló cikkemben nem szeretnék mélyebben a témába menni, inkább számomra érdekes témákat boncolgatnék. Ha szeretnél olvasni erről mélyebben itt megteheted. Úgy érzem a fentiek elolvasásával kaptunk egy kisebb betekintést abba, mit is csinál egy sitebuilder és egy frontend fejlesztő. Ezt nevezzük kliens oldali programozásnak, fejlesztésnek.

Ehhez a szakmához szükséges van HTML5, CSS3, Native JS, valamilyen JS framework ismeretre, CSS preprocessorokkal képbe vagyunk (SASS, Less), van nemi design érzékünk, egy alap Photoshop vagy egy Figma használat sem okoz gondot, a jQuery kis projekteknél sem ellenségünk, az npm, yarn, webpack és a GIT a legjobb barátunk, egy SQL lekérdezéstől nem halunk meg, ha magunknak kell megírni, láttunk már MVC keretrendszereket, kb. ismerjük azokat, PHP nyelvet sokat láttunk, másolgattunk esetleg problémákat oldottunk meg bennük, a Flexbox-ról tudjuk hogy nem flexelésre használjuk a garázsban, a CSS grid és a Bootstrap grid-ről nem az börtönrács jut az eszünkbe, az hogy ebből 12-őt használnak általában, nem lepődünk meg.

És akkor meg a negyedét se emeltem ki azoknak az eszközöknek, sablon motoroknak (template engine), SEO követelményeknek amivel képben kell lennünk. Szóval amikor valaki azt mondja, hogy a frontend könnyű, az nem igazán tudja hogy miről beszél. Mindegyik ágazatnak megvan a nehézsége és a könnyedsége.

De ha már más ágazatok és fogalmak. Mi is az a backend? Mi is az a Fullstack?

inner-03.png


A backend a frontend ellentéte, de mégis szorosan összekapcsolódik a kettő, mondhatni, hogy legjobb barátoknak kellene lenniük a frontendeseknek és a backendeseknek, de a valóságban mégis sok ellentét van a két szakma között, sokszor hallani nárcisztikus elejtéseket azzal kapcsolatban, hogy a frontend az nem programozás, mert hát az nem egy C, vagy C++, vagy egy Java, de hát felesleges is összehasonlitani ezeket, mert más területek. És aki ezt mondja, az előbb tanulja meg a fentiek használatát precízen, húzzon fel egy maga egy weboldalt mondjuk PSD alapján pixelpontosan, és ha eljutott oda, hogy nem csak HTML, CSS-el megy ez, hanem mondjuk egy SASS-al, egy Flexboxxal, egy Handlebar.js, vagy Mustache template engine-nel, mellette valamilyen JS frameworkben programoz le bizonyos funkciókat, akkor majd beszélhetünk arról, mi miért is nehéz. :D

Na de, mi van akkor ha tényleg imádja egymást a két terület? Hát akkor születnek a csodák, melyek egyik terület nélkül sem létezhetnének. A backend fejlesztő a szerver oldalért felelős, a weboldalak többsége 80%-a még mindig PHP nyelven íródik, obejktum orientált szemleletmód mentén, a maradék 20%-a pedig egyéb mint pl a Java  melynek segítségével gyors, reszponzív, skálázható web alkalmazások készíthetők nagy terheltségű, összetett webes feladatok kiszolgálására. Ami mostanában felkapott lett pedig a Go nyelv, könnyen tanulható, gyors, jól skálázható, megbízható és nagy teljesítményű, biztonságos programnyelv. Na de, mit csinál mégis a backendes?

A feladatuk szintén összetett. Fogja azokat az általam írt kódokat és dinamizálja. Az adatbázisban létrehozott táblákban az adatokat összekapcsolja az általam megírt kódokkal és lehetővé teszi az adatbázissal támogatott dinamikus weboldalak futtatását a webszerveren.

Ilyenkor az adatok nem beleégnek a weboldal HTML vázába, hanem dinamikusan cserélhetőek, az ügyfelek admin felületen könnyedén tudják cserélni a weboldal tartalmát. Írnak olyan funkciókat, hogy a híreket listázza az oldal, a regisztrációt, belépést megvalósitják, az adatok tárolását biztonságossá teszik, és még megannyi feladat. Ők is értenek kicsit a HTML, CSS, JS-hez, elkerülhetetlen ez a készség, hiszen vannak olyan feladatok, ahol találkoznak eféle kódokkal is.

De mi van akkor ha valaki Frontendben és Backendben is profi? Na olyan nincs! Ez persze az én véleményem, de azt tapasztaltam, hogy valamelyik terület mindig erősebb lesz, valamelyik mindig jobban érdekelni fogja az szafiofil embereket. Szokták mondani, hogy aki mind a kettőhöz ért az a fullstack fejlesztő. Ez nem teljesen igaz így, ha valaki frontendben erősebb akkor ő Fullstack Frontend Fejlesztő lesz, ha backend a jobb, akkor pedig Fullstack Backend Fejlesztő, de az igazi Fullstack fejlesztő nem csak ennek a kettőnek az együtteséhez ért, hanem a DevOps-hoz. (a fejlesztés (Development) és az üzemeltetés (Operations) viszonyának javítását takarja.) és Rendszergazda ismeretei is vannak. A DevOps fejlesztő az, aki figyeli és működteti a termékmenedzsment, a szoftverfejlesztés és a műveleti szakemberek közötti kommunikációt és együttműködést. Olyan vállalati kultúra és környezet létrehozásával próbálja automatizálni a szoftverintegráció, a tesztelés, a telepítés és az egyéb változások folyamatát, ahol a szoftverek építése, tesztelése és kiadása gyorsan, gyakran és többször is megtörténhet. A rendszergazda vagy másnéven a sysadmin egy olyan fogaskerék a gépezetben, aki felelős a számítógépes rendszerek karbantartásáért, konfigurálásáért és megbízható működéséért; szerverekért.

Olyan emberrel még nem találkoztam, aki mindezekben kiváló, viszont attól még létezhet, meg létező állás is a Fullstack-es. Ez kb olyan, hogy én most Frontendes poziban dolgozok, de lehet jövőhéten egy másik cégnél már Fullstack-nek számítanék. Értitek, valós a dolog, de azért szerintem, ha valaki ezt így magára aggatja 10-20 éve fejlesztő emberek joggal nevetik ki emiatt. Mindeki döntse el maga, milyen skatulyába szeretne tartozni, és mi az ami jobban érdekli.

Webfejlesztő vs minden egyéb

A fentebbi dolgok hozzátartoznak a webfejlesztéshez is. Sokszor olvasok olyan álláshirdetéseket, hogy már kb. azt nem várják el egy webfejlesztőtől, hogy a portás is ő legyen, ezek vagy kókler cégek, ahova nem szabad menni dolgozni, vagy csak nem hozzáértő írta az álláshírdetést. Általában az olyan posztok, ahol szeretnék ha a webfejlesztő értene a PHP-hoz és a JS-hez is valójában Fullstackes fejlesztőt keresnek valamelyik területben erősebbet.

Ugyanis régebben nem különültek el ezek egymástól ezelőtt 10 évvel, emiatt is van az, hogy mocskosul lassú és undorító design-nal, frontend-el megáldott oldalak születtek. Ma már nem lehet elvárni hogy egy ember végezzen ilyen magas komplexitású nyelvek és eszközök mellett minden munkát. Az átlag programozó se zseni, csak emberek, akik képesek voltak seggelni éveken át a tudást, és volt elég szorgalmuk, kiitartásuk és motivációjuk, hogy ebbe a szakmában maradjanak. Ma már ha nagyobb weboldal kell, ahol kell admin, belépés, regisztráció, akkor elengedhetetlen az elkülönítés akkor ha a webdesign nem egyszerű, hanem asszimetrikus, absztrakt, nagyon trendi. Ezekhez már design érzékek kellenek, amit egy backendes nem minden esetben tud megvalósitani egymaga.


De mi is az a webdesign? Webdesigner? Ux designer? UI designer? Grafikus? 


A webdesign az, amibe mi Frontend fejlesztők lehelünk életet, melyet a webdesigner tervez meg különböző eszközök segítségével. Amiket általában használnak: Adobe Illustrator, Photoshop, InDesign, After Effects, Adobe XD és Premier Pro, Blender. Mindegyik más más eszköz, melyek némileg kapcsolódnak egymáshoz. Itt is a webdesigner dönti el, hogy adott tervezéshez mit használ. Ide tartoznak még a prototípuskezelők is, mint a Figma, InVision etc.

De mitől lesz a webdesigner UX designer? A UX szó, USER EXPERIENCE, azaz felhasználói élmény, felhasználói tapasztalat. Az a webdesigner, aki ilyen képességekkel is rendelkezik, válik UX designerré. A UI pedig a USER INTERFACE design-nal foglalkozik. A UX-es adatokkal foglalkozik, tervet készit, versenytársakat elemez,  minden interakciót megtervez, amikor a felhasználó kapcsolatba lép az oldallal és a termékkel, ezekhez drótvázakat készit, működő prototípusokat hoz létre. A megértését alapvetően az is bonyolitja hogy egy élményt nem lehet megtervezni szó szerint. Maga az élmény a felhasználóban keletkezik amikor interakcióba lép az általunk tervezett szolgáltatással. Ehhez pedig tisztában kell lennünk az ügyféligényekkel, hogy kik a célcsoport és mit akarunk a végfelhasználóktól, milyen érzéssel távozzanak. A UX és a usability (használható) erősen kapcsolódik egymáshoz, hiszen a UX-es könnyen használható felületeket tervez, melyek nem rontják a felhasználói élményt sem. Pl. minél kevesebb kattintással jusson el a cáljához, amiért az oldalunkat valószinűleg használni fogja. Ha érdekel a téma ezen az oldalon részletesen tudsz olvasni róla. Itt pedig lentebb görgetve találsz tematikát a témával kapcsolatban.

Ma már szinte mindenki UX designer meg UI designer, meg Webdesigner, aztán azt se tudják mi a micsoda. Lényegi különbség azon is van, hogy egy webdesigner-nek illik ismerni a HTML+ CSS viszonyát, ill. ezeknek a megjelenési formáit, grid rendszereket. Az éppen aktuális CSS keretrendszert pl. Bootstrap 4-re milyen designt jó tervezni, etc. azt csak úgy tudja, ha ismeri. 

A grafikusok olyan szakemberek akik képesek nyomdailag megfelelő logókat és grafikai objektumokat készíteni, képeket előkészíteni és szerkeszteni nyomdai felhasználásra, valamint a grafikus részeket egy komplett kiadványban egyesíteni és nyomdakészen publikálni, a grafikai ismereteiket webes animáció készítésben is tudják kamatoztatni. A grafikus, mint szakma szinte szégyenfolt lett, nem írják ki, mert hát ma már nem ez a trendi, viszont nem is képzik magukat eléggé ahhoz, hogy webdesignerek legyenek. Persze akinek nem inge, az nem öltözködik, de ugyanez vonatkozik a programozói világra is, ha nem képzed magad állandóan, aggathatsz magadra bármilyen titulust, és előadhatod zseniséged mivoltát olyannak, aki nem jártas a témában, de amikor egyedül vagy egy projektben és bizonyítani kell, magadban mélyen, úgyis tudod miben kell még fejlődni, és valójában hova tartozol most a jelenben, és azt is hol akarsz lenni x év múlva.

Amit én minden embernek tanácsolnék, az-az, hogy járjon utána először annak, tényleg érdekli-e az adott szakterület, mert a motiváció hiánya a legnagyobb zseniket is összeroppantja a munkaerő piacon. Kitartás kelleni fog, és egy jó szék a derekadnak. :) De valamit valamiért nem? :) 

Ha eddig eljutottál olvasásban, akkor köszönöm. Ha tetszett a cikk hagyj egy kommentet, vagy oszd meg olyan emberekkel, akiket szintén érdekelhet a téma. Üdv. egy Frontend lány. 

Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack Tovább
Web alapok egyszerűen - A semmiből egy Sitebuilder szint?

Web alapok egyszerűen - A semmiből egy Sitebuilder szint?

web-development.jpg

Mielőtt belekezdenék egy mélyebb témába, el kell hogy mondjam, hogy a HTML5 és a CSS3 egy egyszerű páros, semmi bonyolult dolog nincs bennük, ha szánunk rá időt gyakorlatban ezek elsajátítására. Igen, direkt írtam gyakorlatot, mert hiába az elméleti tudás, ha mögötte csak copy-paste van, és nem is tudod, hogy miért működik a kód, úgy ahogy. Milyen folyamatok vezetnek el ahhoz, hogy e kettő párosának megtanulásával, eljuss egy olyan szintre hogy mellette sok infót el tudjon raktározni az elméd? Megmutatom!

Amikor annó nekiálltam ezeknek a megtanulásának, volt olyan hogy egy div-et nem zártam le valahol gyakorlat közben és órákon át kerestem, szinte már el tudtam volna magam bőgni, hogy ilyen bagatel hibába estem. Hidd el, ezen bárki áteshet eleinte, szóval az önsanyargatást ki kell tudni zárni, tudom nehéz, mert akik igazán fanatikusan akarnak valamit, egyfajta megfelelési kényszerrel is küzdenek maguk felé. A volt tanárom mondta nekem annó:

"hogyha van egy hiba, amit nem találsz órákig, akkor inkább írd előlről az egészet." D.P.

Na de mi is az a div, amit nem zártam le? Kezdjük az elején. Egy kis történeti áttekintés, ami még érdekes is, nem árt, hiszen ez egyfajta tisztelet a szakmának.

Történeti kitekintés

A HTML (HyperText Markup Language=hiperszöveges jelölőnyelv), egy leíró nyelv, amit weboldalak létrehozására fejlesztettek, informácók közlésére. Ez egy internet által használt szabvány amit a W3C (a Word Wide Web Consortium: Fejlesztésekkel szabványokkal foglalkozó szervezet, akik mint egy szektás csoport úgy hírdetik az open source, nyilt forráskóddal létrehozott szoftverek igéjét. Már önmagában emiatt is illik róluk tudni.) és a WHATWG (Web Hypertext Application Technology Working Group) támogatásával jött létre.

A W3C-nek az elnöke Tim Berners-Lee, aki az URL (Uniform Resource Locator, univerzális erőforrás azonosító) és a HTTP (HyperText Transfer Protocol) és a HTML eredeti megalkotója. Akit érdekel mélyebben a HTML története, sok sok érdekes információval gazdagodhat ezen az oldalon.

Tehát megalakultak ezek a szabványok. Ezek ugye tartalmaznak nyelvi elemeket, megkötéseket, böngésző támogatottságot, és sok sok egyéb hasznos dolgot. A HTML egy élő szabvány, amely technikailag folyamatos fejlesztés alatt áll. A jelenlegi HTML szabvány verziójára HTML5 ként hivatkozunk. Időrendi sorredben HTML 2.0, HTML 3.2, HTML 4.01 és a naprakész HTML5. Sok találgatás van a HTML6-al kapcsolatban, olvastam is nyílt levelezéseket a W3C levelezési rendszerén, de ezt jelenleg a W3C nem fogadta még el, és addig ez nem is tekinthető egy élő verziónak. A HTML5 a jelenlegi szabvány 2008 január 22-től napjainkig.

A le nem zárt div...

A HTML 4.01 verziójában még csak div-ben a div-ben a div-ek voltak és minden div-nek adtunk egy jelölő id-t (Pl.: <div id="header"></div> ), a HTML5-be kerültek be új szemantikai (nevük árulkodik a tulajdonságaikról) cimkék (HTML tag-ek) ezáltal az id-k használata érvényét vesztette minden div-ben, de jelenleg is használjuk ha szükség van rá. A multimédiát (video, audió) nem támogatta a 4-es verzió, csak a flash-t. A JavaScript támogatottságát javitották, a böngészőkompatibilitási problémákra nagy hangsúlyt fektettek, a karakterkódolás és a szabvány verzió infója(<!DOCTYPE>) rövidebb lett. Nagyon leegyszerűsitve, sok javitás ment végbe, és kevesebbet kell gépelni. :)

Emiatt ma már ezeknek a segítségével, ill. a technika és a text editorok és IDE-k (Integrated Development Environment) fejlődésével, segítségével a div lezárása már egyszerűbb, mint ez előtt 10 évvel.

DIV - mint általános tárolóelem && HTML5 tag-ek

Angol neve division (rész,részleg, elosztás), mely egy páros cimke, aminek van nyitó és záró tag-je. Akár mennyit ágyazhatunk egybe, ezt szokták általában Div Tree-nek (Div fának) is nevezni.

<div></div>

A weboldal egy logikailag összetartozó részének csomagolására és blokkszíntű formázásra használjuk. Alap esetben ez egy blokk elem: - display: block; , aminek a formázását szintén stílus deklarálással változtatjuk.

A HTML5-ben is használunk jelenleg is diveket, sőt, sokan azért is használnak még, mert alapvetően nem foglalkoztak ezzel a témával sokat, és kevesebbet használják a szemantikus HTML5 elemeket.

Népszerű elemek

<header></header>
<aside></aside>
<nav></nav>
<article></article>
<main></main>
<footer></footer>
<section></section>
<hgroup></hgroup>
<mark></mark>
<audio></audio>
<video></video>
<canvas></canvas>
<figure></figure>
<figcaption></figcaption>

Még több itt található, példákkal szemléltetve.

Ezeknek az elemeknek a stílus deklarálását, CSS (Cascading Style Sheet - Lépcsőzetes, örököltetett, egymásba ágyazott stíluslap) segítségével adjuk meg.

Röviden a CSS-ről

Az első stílus szabványt 1996-ban fejlesztette ki a W3C CSS1 néven aztán 98'-ban CSS2 néven, és már 1998-2000-től egészen napjainkig a CSS3-at fejlesztik, elmondásuk szerint nem is lesz CSS4.

"There has never been a CSS4. There will never be a CSS4. CSS4 is not a thing that exists." Tab Atkins in 2013

"Many people are waiting for CSS4 to come out. Where is it? When will it arrive? The answer is never. CSS4 will never happen. It’s not actually a thing." Jen Simmons in 2018

CSS3 4-es szintű moduláris fejlesztés van, aminek a legfrissebb változatát 2020 januárjában publikálta a W3C.

CSS3, HTML5 és a Hello World

Demo

<!DOCTYPE html>
<html>
   <head>
      <title>This is document title</title>
      <style>
      h1 {
         color: #36CFFF; 
      }
      </style>
   </head>  
   <body>
     <header>
            <nav></nav>
     </header>
     <main>
            <hgroup>
                    <h1>Hello World!</h1>
                    <h2>Hello Codepen!</h2>
            </hgroup>
     </main>
   </body>  
</html>

CSS importálása az oldalunkba

A stílus beemelése a weboldalunkba 3 féle képpen történhet.

  • Első a fenti ammikor a head-be style tag-ek közé írjuk a css-t, ezt max akkor használjuk, ha hírlevelet készítünk, vagy számlázó programhoz számlaképet, mivel azokat egy oldalon töltjük be, vagy a számlázó program oldalhibák nélkül is kell hogy működjön, vagy pedig a levelező klienssel, aminél szintén egyszerűbb ez az eljárás. Ezt hívjuk Internal (belső) Stylesheet-nek.

  • Második amikor inline style-t írunk a HTML-be. pl.

<!DOCTYPE html>
<html>
   <head>
      <title>This is document title</title>
   </head>  
   <body>
     <header>
            <nav></nav>
     </header>
     <main>
            <hgroup>
                    <h1 style="color: #36CFFF;">Hello World!</h1>
                    <h2 style="color: #36CFFF; background-color: #ddd;">Hello Codepen!</h2>
            </hgroup>
     </main>
   </body>  
</html>

Ezt akkor használjuk maximum, ha JavaScript-ben adjuk meg a CSS formázást, akkor a JS inline teszi bele a CSS utasítást. Vagy még szintén hírleveleknél. De ez nem jó módszer, meg maga az inline style se, szóval ezt engedjük el szerintem. Tudjuk hogy van, létezik, szép és jó, de nem kell erőltetni, mert utána meg csodálkozunk ha egy 5mp-es formázás 25 perc lesz, mert nem tudjuk felülcsapni simán css-fájlban. Ezt hívjuk Inline (sorszintű) Stylesheet-nek.

  • Harmadik pedig a külső fájlból való beemelés, ami a head tag-ek közé kerül. A link igazából linkeket generál a HTML után de még a html kódjaid előtt, a rel meg egy attribútum ami megmondja milyen kapcsolata lesz ennek a fájlnak a te kódoddal. Ez esetben 'stylesheet' ami az assets/css mappádban fog szerepelni a main.css.

Példa

<!DOCTYPE html>
<html>
   <head>
        <link rel="stylesheet" href="assets/css/main.css"/> 
      <title>This is document title</title>
   </head>  
   <body>
     <header>
            <nav></nav>
     </header>
     <main>
            <hgroup>
                    <h1>Hello World!</h1>
                    <h2>Hello Codepen!</h2>
            </hgroup>
     </main>
   </body>  
</html>

Ez az amit általánosan használunk. Ennek a neve External (külső) Stylesheet.

Szünet ON

A fentiek egyértelműen alapok, ami mély alapok, azért mély, mert sokan nem veszik a fáradtságot arra, hogy ezeket tényleg megértsék, pedig ezek igazán fontos, érdekes és egyszerű dolgok. Eddig ugye volt kis történeti betekintés a HTML és a CSS világába, volt egy kis HTML4 vs. HTML5, megismerkedtünk a CSS szintjeivel. Láttunk kódokat. Ez már nem is rossz nem? Ok persze ebbe még nincs benne a syntaxis, de ezt különféle tutorial oldalakról magadra szeded kb 5 perc alatt. A lényeg nem azon van, hogy mennyi elméletet magolunk be, hanem azon hogy már akkor elkezdjük írni a kódokat, amikor még fogalmunk sincs arról, hogyan fogunk egy szöveget pl. szívárvány színűvé tenni.

Ilyenkor mindig van kis feladat, amit részekre kell szedni, és azokra keresni neten. Keresni Stackoverflow-n. Próbálgatni a határainkat, minél több dolgot megérteni a propertyk-ből és azok értékeiből, a HTML tag-eket megszokni és azok osztályainak érthető neveket adni. Ezt egy előző cikkben már kifejtettem.

Szünet OFF: CSS3 és HTML szabályok szintaxisa pár szóban

Egy CSS deklaráció két részből áll: Egy tulajdonságból (property), aminek értéket szeretnénk beállítani. Egy értékből (value), amit a tulajdonságnak adunk értékül.

Ezt a tulajdonság-érték párost kettőspont választja el egymástól.

pl.:

/* this is a comment */
.class {
    property: value;
}

#id {
    property: value;
}

Minden CSS deklarációt egy pontosvessző zár le. (semicolon) Ez a pontosvessző a szabályhoz tartozó utolsó deklaráció végéről elhagyható. Ez azonban nem ajánlott, mert később hibákhoz vezethet.

Uncaught SyntaxError: Unexpected token ;

Az id-kat hash-el jelöljük css-ben ill. html-en belül az a tag-ekben is, ha leugró blokkot szeretnénk.

pl.:

<a href="#myId"></a>

<!-- valahol alul a kódban pedig -->

<section id="myId"></section>

<!-- TODO: comment -->

Commentek a kódban ahogy a fenti példában is látszik CSS-ben /* comment */ per csillag - csillag per közé kerülnek. HTML-ben pedig <!-- TODO: comment --> így néz ki.

Kódolási alapelvek, írott és íratlan szabályok

  • h1 csak egy lehet egy oldalon és azt követi a h2, h3, h4, h5, h6. Viszont, ha vannak cikkek az oldalon, ott is lehet h1.
  • ha nincs h2 akkor utána lentebb nem használhatunk h3-at, először h2-nek kell lennie valahol.
  • alt-nak mindig adjunk leíró szöveget, mert a felolvasó programok ezeket olvassák fel a látás sérült embereknek.
  • tag-et és tulajdonságot csak úgy használjunk, ha megnéztük a böngészőkompatibilitást. Azt itt könnyedén ellenőrizhetjük: https://caniuse.com/
  • ahol partial (részleges támogatottság) van használjunk olyan property-t ami minden esetet lefed, vagy használjunk olyat is. Ez pl Flexbox-nál szokott gond lenni.
  • 2000px-től nagyobb képeket ne használjunk desktopon se. Ill. tömörítsük a képeket. Tömörítésre ez kiváló: https://tinypng.com/
  • Mobilra és tabletre is külön méretet vágjunk be. Alap Gimp, vagy PhotoShop használatot tanuljuk meg.
  • képeknél ahol háttér típusú képeket használunk jpg vagy webp kiterjesztés legyen, ahol meg ikonok, logók vannak ott svg.
  • hosszabb szövegek félkövérré tételére a 'strong' vagy a 'b' tag-et használjuk. A 'b' -tag-et viszont, csak akkor, ha semmi más opció nincs. (Seo barát)

Akkor Sitebuilder vagyok, leszek?

Ha ezeket megértetted, akkor pörgess végig valami tutoriált, mellé találj egy szakmai mentort aki útba irányit, csinálj legalább pár ref oldalt, mellé codepen.io-n csinálj kis részfeladatokat, gyakorolj sokat és ha már megy a HTML, CSS3 (nativan), akkor mellé tanulj egy Flexbox-ot, vagy egy CSS grid-et, vagy mindkettőt, mellé jöhet egy Bootstrap, vagy valamilyen CSS keretrendszer megértése, mellé pedig a JS natívan.

Ezekkel már elmondhatod hogy ha alapszinten mennek, hogy sitebuilder vagy, és ha meg tanulsz mellé pár JS framework-ot, pl a Vue.js (kezdőknek én ezt ajánlom), és a Vue.js mellé majd TypeScriptet akkor elmondhatod hogy programozol és webet || szoftver felületet és funkcionalitást fejlesztesz.

Van akinek a TypeScript és társai soha nem lesz programozás, persze ezt valahol meg lehet érteni hiszen még se egy Assembly, meg nem egy C++, de ugy gondolom hogy a körtét ne is hasonlítsuk össze az almával. Mindegyik nyelvnek és területnek megvan a nehézsége és könnyedsége. És minden embernek megvan a saját tanulási görbéje. :)

Tutorial oldalak pl:

Eredeti cikk megjelenése itt érhető el: codepen post

Web alapok egyszerűen - A semmiből egy Sitebuilder szint? Tovább
Codepen projekt / Vue.js

Codepen projekt / Vue.js

See the Pen Realistic Iphone & case :) SCSS, Vue.js, Flexbox by Zsena (@Zsena) on CodePen.

Codepen projekt / Vue.js Tovább
Kódminőség: Általános szemantika az osztálynevekben

Kódminőség: Általános szemantika az osztálynevekben

“Think twice, code once”

5005070-637286297619941368-16x9.jpg

A CSS szabályok azok az utasítások, amelyek segítségével beállíthatjuk a weblapunk HTML elemeinek vizuális megjelenését, ezekhez szükségünk van valamilyen kiválasztásra, esetünkben most az Osztály alapú kiválasztásra.

Ezeket a ponttal (.) deklaráljuk. (hozzuk létre).

tipusszelektor .osztaly {tulajdonsag: ertek;}

Ha pedig több szelektorra (Type selector: h1) szeretnénk alkalmazni a stílust, akkor típus szelektor és class (Class Selector) csoportosítást kell végrehajtani, azaz vessszővel elválasztva felsorololjuk a kívánt szelektor class párosokat, ezzel átadva az adott stílusdeklarációt. pl.:

tipusszelektor .osztaly1, tipusszelektor .osztaly2 {tulajdonsag: ertek;}

Egy nagyobb projektben webfejlesztés során sok osztálynevet használunk, és ahogy a programozási nyelvekben az objektum osztályok nevei egyediek, értelmesek kellenek hogy legyenek, így itt is törekedni kell a szemantikusságra, értelmezehetőségre és arra, hogy az adott osztály neve irja le az adott element (html tag) tulajdonságát. Pl.

 <main class="content container">...</main>

Ez egy csomagoló elem amiben a fő content van, annak vannak property-jei. pl.:

main.content p {  color: #ddd; }

és:

 main.container {
  width: 80%;
  margin: auto;
  display: block;
}

Ezek a class nevek addig egyediek, amig nem emeljük be az adott projektet egy külsős projektbe, mert ott már előfordulhat névütközés, és akkor egymásra hatással lesznek a tulajdonságok. Ilyen esetekre javasolt a névtér csoportosítás, amikor egy adott egyedi classból hivatkozunk az összes többi class-ra a content-ben. pl.: Projekt weboldalának a neve VRT

<main class="vrt-content vrt-container">...</main>
  main.vrt-content .table {
  background-color: #ddd;
}

Viszont ha ezeket, mint egy library később is fel szeretnénk majd használni, másik projektben, ki lehet találni egy saját class nevet, ami a hozzánk tartozik. PL.: A weboldalam neve: geekrabbits.hu

<main class="gr-content gr-container">...</main>

Eleinte amikor tanultam a web alapjait, volt amikor percekig ültem egy blokk felett, hogy akkor milyen class nevet is adjak az adott HTML tag-nek.

Ilyenkor az a legjobb ha arra gondolunk hogy az adott elemünk mire kell nekünk. Általános programozásban pl. objektumorientált szemlélet mentén (OOP) a névtereket (namespace) is csoportosithatjuk és bővithetjük, és ott is pl felbontjuk az adott névtereket és elhelyezzük az objektum-osztályokat. Csak egy kis példa erre:

 namespace Kepernyok {
    class Felbontas { ... }
    class Szinmelyseg { ... }
 }

namespace Grafika {
    class Haromszog { ... }
    class Meret { ... }
 }

 Html-ben ugyanezt a logikát használjuk, amikor pl létre szeretnénk hozni az oldalon egy bal oldali menüt.

<aside class="sidebar">
 <nav class="sidebar-nav">
   <ul class="sidebar-navbar">
    <li class="sidebar-item">
       <a class="sidebar-nav-link" href="#">Text</a>
    </li>
    <li class="sidebar-item">
       <a class="sidebar-nav-link" href="#">Text</a>
    </li>
   </ul>
 </nav>
</aside>

Case-Sensitive (kis és nagybetű érzékenység)

A class és az id-kat azonositásra használjuk, ezért célszerű a beszédes nevekre törekedni, ill. az összetett szavakat class-ban és id-ban megkülönböztetni. pl: class: .nav-link, pl: id: #navLink

A HTML viszont nem case-sensitive, tehát nem fog hibát dobni, ha NaVlInK lesz a class nevünk. Viszont olvashatóság miatt ez borzalmas, :) de a HTML és a CSS együtt már case-sensitive.

Tehát ez hibás

<a href="#" class="NaVlInK">WARNING!</a>
a.naVlInK {color: red; background: yellow;}

ez pedig a jó:

<a href="#" class="NaVlInK">WARNING!</a>
a.NaVlInK {color: red; background: yellow;}

*Viszont ahogy fentebb is irtam, törekedjünk az olvashatóságra. *

Kódminőség, Kódolási konvenkciók (pl. naming conventions )

Amint fentebb is említettem ezek a megkötések inkább a magasabb színtű programozási nyelvekben fordulnak elő, de itt is vannak írott és íratlan szabályok amiket jobb bertartani, hogy minden hajszálunk megmaradjon a projekt végére. Tehát ne kezdődjön nagybetűvel, ne kezdődjön számmal, kötőjellel, használjunk angol neveket, hiszen angol az informatika közös nyelve, és kerüljük az ékezeteket etc..

De mi van a kötőjelekkel vagy az alsó aláhúzással? Ezeket használhatjuk, pl összetett szavaknál, vagy csoportoknál. Sok féle metodika van erre. PL. az egyik legelterjedtebb, amit pl az Angular is használ az SCSS fájljaiban (CSS továbbfejlesztése) az a BEM módszer.

A BEM alapvetése, hogy a felület összetartozó elemeit blokkokba csoportosítva összefogja. Erre a dupla aláhúzást határozza meg (__) a módszer.

pl.: HTML

<article class="article">
  <div class="article__title"></li>    
  <div class="article__lead"></li>
</article>
CSS
 .article {}
 .article__title {}
 .article__lead {}
SCSS
.article {
    []
    &__title {}
    &__lead {}
 }

ITT MINDENKI AZT HASZNÁLJA, AMI A SZÁMÁRA A LEGJOBB, KÖVETHETŐBB, VAGY AMIT ÉPP A PROJEKT MEGKÖVETEL. :)

Szakirodalom a témában:

Bem naming conventions

Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin

vagy ugyanez magyarul:

Tiszta kód - Az agilis szoftverfejlesztés kézikönyve (Clean Code) Könyv, Robert C. Martin

Kódminőség: Általános szemantika az osztálynevekben Tovább
My motivations

My motivations

My motivations


Hello Coder and Tech World!

I am Zsena ( Zsanett Tamás, 29 years ) and I encode. I don't say that I am a programmer because I don't feel totally myself as that. Why? Because, I have lesser knowledge than a programmer but more than an average person. 

How did I become an encoder?

I always wanted to create. Basically I dealt with cultural organisations because I am interested in arts. Somehow I was not satisfied with that and I knew I have to do something else.

During my HighSchool years, I had a strong feeling to study further in the IT field. I had more lessons about IT than other classes. Originally, I have not been accepted for the IT track, not even another tracks, because my points were too low. But I wasn't stupid. Only lazy and I wanted to show that I have more inside than one of my teacher thought in the primary school. 

He said that I never have any profession in my life. So that's when I decided that I will be the best student in the class. I learned a lot, I reached the best grades in the vocational school in a totally different field. I started my fresh year in a class, where the school girls have been already pregnant.

After 3 months, all the teachers talked about me. Then one day, the director of the school came to my class to see me whether I am that good what he has heard so the next day I could start my studies without any fear in that class, where I always wanted to study. He personally escorted me to the class and said to me that:

My motivations Tovább
Women who can do it... ^^

Women who can do it... ^^

Women who can do it... ^^

Recent studies show that only 0.3% of high school girls choose to pursue computer science in college -- even though 74% of middle school girls express interest in Science, Technology, Engineering and Math (STEM). That's a startling statistic. But with the support of companies like Intel, Twitter, GE, Google and others, Girls Who Code http://www.girlswhocode.com/ is trying to change that. The goal? To help close that gap by giving high school girls ages 13 -- 17 the opportunity to learn more about what engineering and technology careers have to offer, and by giving them the confidence to pursue their goals. We had the pleasure of working with our friends at the Intel Foundation to tell their story.
Women who can do it... ^^ Tovább
süti beállítások módosítása