Webdesign régen és ma – időutazások a „régmúltba” képgalériával

Mindigis szokásom volt a különféle dizájnok gyűjtögetése, és kifejezetten megütköztem, mikor a napokban valahogy kezembe került egy-egy “cd”, melyekre 2000-es és a 2010-es idők webdesignjait archiváltam le. Ezek mai szemmel szinte nevetségesnek hatnak, és semmilyen szempontból nem tűnnek elfogadhatónak…
De kis visszatekintéssel élnék, hogy annakidején miért ilyenek voltak a honlapok.

A legfontosabb körülmény ezek helyes megítélésére annak tudomásul vétele, hogy nem létezett a több képernyőre alkalmas megjelenítés, és így a honlapoknak csak egy méretet, az 1024-es pixelméretet kellett tudniuk. Ekkor maguk a böngészők nem ismerték a “tól-ig” kódokat, de erre nem is nagyon volt szükség, mivel csak kevés nagy méretű monitor volt használatban, és ezek is inkább csak ott, ahol mindenképpen fontos volt a nagy megjelenítés. Az én első monitorom egy homályos képű Samsung volt, melynek a képátlója 14 col volt (!), és a képernyője még enyhén domborodott… Régi szép idők…

 

Hírportálok és magazinok a 2000-es évekből

 

Az első weblapokat HTML-ben készítettük el, én jellemző módon Dreaweavert használtam, ami akármilyen különös, de még mindíg használható, olyannyira, hogy ha responsive portál terveket kell készíteni nagyobb tételben, akkor képes olyan kódot is megjeleníteni, ami egész konfortos szerkesztést tesz lehetővé. (2018-ban foglalkoztam ezzel.)
Tehát a weblapok nem voltak reszponzívak, csak egy méretben mutatkoztak meg, és így kell ezeket a honlap dizánokat szemlélni.
Nem voltak egyedi betűtípusok, a honlap a kliens gép font könyvtárából használta a betűtípusokat – jellemző módon minden szöveg Arial-lal, Times-szal, Georgia-val, és Verdana-val jelent meg. Nem volt sticky menü, és ha fix menüt akartunk, akkor frame-eket használtunk. Ilyenkor a tartalom frame-nek önálló gördítő csúszkája volt, mely csúszkát pár évvel később már át tudtunk színezni…

Ugyanakkor meg kell jegyezni, hogy ezek a honlapok abban az időben ZSENIÁLISAK VOLTAK. Nehéz ezt belátni, mert ma már nevetségesnek hatnak, de így volt. Aki benne volt, emléxik rá. Olyannyira, hogy igencsak kapaszkodnom kellett, hogy hasonlókat szerkesszek.

Tanulságos visszatekinteni a számítástechnika “hőskorába”.

 

Céges honlapok a 2000-es évekből

 

 

 

Képnagyítás frak­tálos eszkö­zökkel – Reshade Tool

Visszatérő problémánk, hogy kisebb felbontású képeket kell használnunk. A programozók régóta kísérleteznek azzal, hogy a pixeles részletek ne lépcsősen nagyítódjanak fel, és az utóbbi időbe egyre több ilyen eljárásra bukkanhatunk. 

Ha egyszerűen Photoshoppal nagyítjuk ezeket a képeket, akkor előfordulhat, hogy a kép vonalai elhomályosodnak. Ennek kiküszöbölésére kínál lehetőséget a Reshade kis méretű ingyenes képszerkesztő eszköz. Ez a tool nagyjából a duplájára képes minőségromlás nélkül képeket felnagyítani, ami az esetünkben általában elég is lehet. A Reshade zajszűrője is jó, attól tartok, hogy ebben is megveri a Photoshopot.
Ezzel a módszerrel már léteznek fizetős pluginok is a PS-hez, de miért fizessünk, ha ez a szoftver ingyen letölthető az internetről…

Az ingyenes eszköz itt tölthető le: https://www.reshade.net/

Képet nagyít >>>

Shoprenter oldalakhoz responsive html kód

A kérdés az, hogy hogyan fogjunk hozzá? Nos a Shoprenter kissé kényeskedik, mikor “testidegen” kóddal akarunk működő elemeket beletenni. Így jártam pl. az oldal felső, kezdőtraktusára behelyezendő sliderrel is, melyet responsive html-el készült érkező oldalam tetejére szerettem volna betenni.

Rákerestem a “free html slider”-re, és a következő ígéretes oldalra bukkantam: (bocsánat, ide valaki vírusokat helyezett el, így le kellett vennem). Ezen negyven slider kód volt felsorakoztatva, fel volt tüntetve mindnél a kinézete is, volt hozzá demo megtekintési lehetőség, sőt volt alattuk letöltés gomb is.

Elsőként azzal szembesültem, hogy bár ezek a sliderek saját kategóriájukban mind jók, csak jelentős részük vagy furcsa működésű volt, mert ideoda lötyögött és pulzált, míg más meg jellemzően oldalközépi slider volt, és nem olyan amit a lap tetejére szoktunk tenni. Az oldalak tetejére most 2023-ban inkább fullwidth slidereket teszünk navigáló nyilai vannak jobb és bal oldalon. Ennélfogva az oldalon feltüntetett sliderek háromnegyede eleve kiesett, és csak 10 maradt versenyben oldalam elkészítéséhez.

Csak két megoldás volt működőképes

10-et sorban próbáltam ki, és végül csak két megoldás volt működőképes a Shoprenter kódkörnyezetében. Tehát csak kettő.
Ez itt tekinthető meg: https://qmsmedicosmetics.hu/anti-aging

Ugyanerre később felirat is került.

Itt nézhető meg: https://qmsmedicosmetics.hu/qms-borapolasi-rutin
A megoldás az volt a felirat elhelyezésére, hogy a slider keret méretét a “háttérkép” határozza meg, ami megadja a div alsó és felső pontjait, és ehhez képest kell függőlegesen középre tenni a szövegboxot.

Ha te kedves olvasó szintén a Shoprenterre akarsz hasonló slidert készíteni, akkor bányászd ki a kódból.
De mielőtt ezt kibányásznád, lejjebb a testimonial slidernek (úgy mellékesen) kicsit talán jobb a kódja.
Nézd meg azért azt is.

Képek lementése akkor is, ha ez tiltva van

Ha egy kép letöltése tiltva van valamilyen webes eljárással, akkor ennek ellenére is le lehet menteni. Az már nagyjából mindenkinek nyilvánvaló, hogy az un. “képkimetszővel” a képernyőn megjelenő képet le lehet menteni (képlopó programok), de sok más megoldás is rendelkezésünkre áll.

 

EGÉRREL KÖNYVTÁRBA KIHÚZÁS

Messze ez a legegyszerűbb képletöltési módszer, csak előtte meg kell nyissuk azt a könyvtárunkat, melybe a képet bele akarjuk menteni. Ez olyankor működik, ha a jobb kattintás is engedélyezett az adott weboldalon.

SAVE AS

Azt már kevesebben tudják, hogy a képek mentésére az egyszerű “save as” mentés is akár megfelelő lehet. A mentés másként-re, vagy jelen esetben a mentés utasításra ugyanis a böngészők nagyjából helyesen mentik le számítógépünkre az éppen megjelenített webodalt, történetesen az összes képernyőre kirakott file-okkal és az oldal szerkezezetével együtt. A könyvtárunkba lementett fileok mennyisége ugyanakkor nagy számú is lehet, ahonnan néha nehézkes kibogarászni a nekünk szükséges képet.
Egy kivétel van, a Drive, ott sajnos nem működik a “save” és a “save as” utasítás, és ha ott van tiltva a kép letöltése, akkor tényleg csak a képernyőkép lopás marad.

F12 BILLENTYŰVEL

A profik viszont azt csinálják, hogy F12 diagnosztikai módot nyomnak, mire egy önálló kisablakban bejön az oldal szerkezete, csak sajnos egyes programozók ezt is képesek úgy agyonbonyolítani, hogy képtelenség lesz megtalálni a képet a kódrengetegben. Ilyenkor általában css háttérként töltődik be a kép, tehát magában az oldalkódban meg sem találhatnánk.
A legtökéletesebben viszont a Smart Slider WP plugin rejti el a képet, ott még a 10-edik nekirugaszkodásra sem tudtam a képet meglelni kódszinten. Az meg azért lehet kellemetlen, mert a kép fölött a lapozókon felirat is meg van jelenítve a különféle üzenetek átadása érdekében, így a képernyőlopással a képen a feliratok is látszanának. Néha tehát a save-as marad utolsó megoldásnak.

De persze a save-as “letiltásával” is próbálkoznak a szakemberek, ugyanis ha a Flickr-ről akarunk saveas-olni, akkor akár egy percig is eltarthat a mentés… Gondolom ilyesfajta cél lebeg az oldal üzemeltetői részéről.

A képek képernyőről lelopásához én személy szerint Snagit-ot használok, melyek még scrollozva is tudnak menteni weboldalakat teljes függőleges magasságukban, viszont nekem ez inkább csak kivételként sikerült ezzel a programmal (régebben). Pedig hát ez lett volna nekem az igazi főnyeremény, mivel szokásom komplett weblapokat is screenelni.

 

Érdemes-e responsive html kóddal “Corporate” siteot készíteni?

Röviden: nem. Kicsit részletesebben: nagyon nem. Nagyjából 2012 környékén eldöntöttem, hogy leiskolázok mindenkit, és ország-s-világnak megmutatom hogy ha az ember rátermett, szorgalmas, és végtelen elkötelezettséggel rendelkezik, akkor képes megcsinálni a világ leggyorsabb ‘corporate stílusú’ html weblapját.

A célom az volt, hogy ha elkészülök, megmérem a különféle online mérőkkel, melyek számokkal is bizonyítják oldalam hihetletlen tempóját, annak 1000%-os minőségét, és azontúl csak ilyen módon fogok siteokat készíteni.

Nos igencsak csalódnom kellett… Ugyanis a mérések közepesen jónak mérték oldalamat annak ellenére, hogy valóban a legkevesebb teljesítményt csökkentő eljárást alkalmaztam. Legalábbis azt hittem…

Mi volt az ok? Nos az online eszközök két lassító eljárást említettek, egyik a főoldali slider szkriptje volt, a másik az awesome font integrációja. Mindemellett a nem minify-olt css-ek is a mérések szerint “lassulást” okoztak.

Csakhogy… Csakhogy a honlap minden aloldala 0,5 másodperc alatt töltődött be. Egy hús-vér ember számára a weblap hasított, de a mérések mégsem minősítették kimagaslóan gyorsra oldalam.

Mi ebből a tanulság?

Hogy felesleges túldimenzionálni a sebességet, és főleg a méréseket. Ha oldalunk 3 másodperc alatt megjelenik, akkor ezt az időt még a látogatók kivárják. Könnyű úgy rekordsebességű weboldalt felépíteni, ha abban nicsenek sliderek, szkriptek, interaktív elemek, mert akkor lesz egy jó mérési eredményekkel rendelkező gyökér oldalunk. Egy hulladék, fosadék honlap, amit a készítőjén kívül mindenki utálni fog. És persze egy honlapnak nem az a feladata, hogy a programozó demózza a szaktudását. Az a feladata, hogy a látogatók szeressék. Legjobb ha az optimumra törekszünk, oldalunk legyen igényes, de ne túl lassú

Itt nézheted meg a 2012-ben “barkácsolt”, de azóta kissé elavultnak tűnő oldalaimat. A teljesség igénye nélkül.

 

A HTML OLDALAK SZERINTEM HASÍTANAK… NEM ÚGY A MÉRŐESZKÖZÖK SZERINT…

 

 

 

 

Egyedi Woocommerce termékoldalak szerkesztése

Szeretném leszögezni, hogy csak különleges esetben érdemes a hagyományos termék aloldal formai elrendezésével szakítani, és pl. dizájn oldalt fabrikálni egy Woocommerce shopból. Amikor a sample oldalakat bekattintjátok ez első pillanatban jó ötletnek tűnhet.

 

Egyedi Woo oldal elrendezések:
Sample1> , Sample2> , Sample3>

Viszont a termék shop főoldalának szerkesztése közben súlyos problémával kell számolni. Ugyanis egy terméknek csak egy kiemelt termékképe lehet, és ha ez a termékkép egy-egy dizájn oldalon lapos, míg más terméknek meg sztenderd négyzetes formájú, akkor ezek egy termék listázásnál nem kerülhetnek egymás után.
Mégmáshogy elmagyarázom. Ha egy “kerti bútor garnitúra” képe extralapos, és egy “napernyő” képe négyzetes, akkor ezek a listákban nem kerülhetnek egymás mellé pl. egy főoldalon, tehát már a termékek feltöltésénél előre el kell dönteni, hogy hány képarányt használunk, és hogy ezek milyen listákat alkotnak. Ettől a munka kísértetiesen nehézzé válik, sőt már az első kapavágások megtétele is rengeteg időt felemészt.

Ha valaki ezzel kísérletezik, akkor esetleg kipróbálhatja, hátha meg lehet css stílussal croppolni a termék aloldal főképét laposra, és úgy ez a laposnak látszó kép is lehetne eredetileg négyzetes, – amit a kód vág meg alul és felül. Ilyenkor a listákban a teljes négyzetes kép látszhatna, míg a termék aloldalon ugyanannak a képnek csak a középső vízsintes szelete jelenne meg.

A harmadik megoldás a főoldal esetén már-már az őrülettel határos… mert lehet esetleg olyan shop főoldalt is készíteni, amiben nem autolistázott módon sorakoznak fel egymás után a termékek, hanem egyedi szerkesztésben, de az a gondolat, hogy egy shop főoldal page-szerkesztővel készüljön el engem jeges borzongással tölt el… (Elementorral, LiveComposerrel… stb-vel.) Erre én nem vesztegetnék időt.

Így néz ki, ha a termékképek némelyike lapos, míg más termékek képei négyzetesek. Roppant nehéz elkerülni, hogy ezek egymás után következzenek, és csak saját csoportokat alkossanak.

https://webdesigner-grafikus.hu/…/Kerti-Butor-Vasar_minta_weblap-1200px.jpg

Hogyan készítsünk hírportált, avagy a tökéletes html

Hogyan készítsünk hírportált, avagy a tökéletes html

Először azt a címet akartam adni ennek a cikknek, hogy “a hírportál készítés nehézségei – a tökéletes html”, de végül a fenti mellett döntöttem.
Jobb úgy nyitni arra a kérdésre, hogy “hogyan készítsünk hírportált”, hogy NE készítsünk hírportált. Mert ne fogjunk bele ilyen őrültségbe!

Képgaléria Html site terveimről (csak jpg-k)

 

Ne fogjunk bele ilyen őrültségbe! Tudom miről beszélek, tizenvalahány portál tervet készítettem el responsive html-ben… Nem csak az a probléma, hogy nehéz ezeket kivitelezni, és a demóimat is kb. egy hétig készítettem, és vért izzadtam minddel, de ráadásul nincs magyarba’ olyan urambocsá’ írástudó közösség, aki ezeket a portálokat tartalmakkal tudná és akarná ellátni.

 

HTML FORMÁTUM:
Három Html-es responsive portál tervet itt tudsz megnézni

 

 

De hogy egy kis szakmaiság is legyen e posztban, az első nehézség az volt, hogy a szélek mentén álljanak a szövegek. Még annak is nehéz megérteni, aki ilyesmivel foglalkozik, de megpróbálom érzékeltetni miről is van szó. Ha van három oszlopunk, és közöttük pl. 40 pixel köz van, akkor ahhoz, hogy a lap szélén jobb és bal oldalon a tartalmak az oldalszélhez ütközzenek, ehhez ki kell minusz marginolni a két szélét. Érthetetlen? Mondom másképpen? Az ugye nem lesz jó, ha középen az oszlopok között 40 px távolság lesz, de a szélek mentén jobb és bal oldalon a lapszélnél csak 20 pixel… Mert az nem lesz jó. Érthetetlen? Igen az, mert ezt csak csinálva érti meg az ember, ha csinálja, akkor nem fognak mínusznarginolás nélkül illeszkedni az elemek.

De nem kell ezt megérteni… inkább nem kell portált fejleszteni. Készen kell venni ilyesmit… Vagy Elementorral és Bloglentorral (!) kell készíteni egyet. Inkább. Annak sokkal több értelme van, mert ha már úgysem fogja senki tartalommal megtölteni, legalább nem került iszonytató összegekbe, és mérhetetlen mennyiségű munkaórába.

 

Vektoros ábrák használata Photoshopban

De miért is ajánlatos néha vektoros ábrákat használni Photoshopban? Mivel a vektoros kitöltésű objektumok korlátlanul transzformálhatók, összenyomhatók akár 32 pixelig is, és onnan minőség romlás nélkül nagyíthatók vissza nagy méretűvé. Ugyanakkor roppant sajnálatos, hogy a PS korábbi verziói nem tudnak görbéket importálni, bár meglehet, hogy Adobe Illustratorban kopizott görbe gond nélkül beilleszthető a görbék rétegek egyikére. (Gyengébbek kedvéért ott kell keresni, ahol a rétegek, csatornák, GÖRBÉK taláhatók.)

Évek óta a vektoros logókat saját módszerrel illesztem be Photoshopba.
A módszerem a következő.

1.

Megnyitom a logót/vektoros ábrát Photoshopban nagy felbontásban, lehetőleg fekete / átlátszó formátumban, de minimum 4.000 pixellel.

2.

Utána CTRL + (Layerre kattintással) kijelölöm az átlátszóságot, majd a palettákon átkattintok a Görbékre, és ott létrehozok egy Munkagörbét a paletták jobb fölső apró nyilára kattintva.

3.

Összenyomom az adott képet kb 1.000 pixelre.

4.

Átmegyek a PS-ban arra a képre, amire rá akarom helyezni a logót, és ott megteszem az első lépést arra, hogy egy új vektoros réteg keletkezzen. Ehhez létrehozok egy új réteget (pl. legfelül), majd erre a rétegre ráteszek egyetlen egy darab pontot, mintha egy görbe rajzolását kezdeném el.

5.

Utána visszamegyek az 1.000 pixelre összenyomott vektoros görbét tartalmazó szerkesztett képre, és annak görbéjét bal egérgombbal megragadom, és áthúzom a másik PS képre, melyen az a “vektormaszk” layer látható melyen laraktam az első pontot.

 

Magyarázat az eljárásomra:
Elviekben jól működhet az is, hogy a megnyitott logó görbéjéből készítünk kitöltött vektormaszkot, csak ez a régebbi PS-ekben nem volt megbízható, és az átméretezési probléma ott is fennállt, ugyanis sokkal nagyobb felbontásból érdemes vektorizálni a logót, hogy végleges helyén síma legyen, ne töredezett.
Ugyanakkor az lenne a legjobb, ha a PS végre megoldaná, hogy a Görbék layerére is vágólapról be lehessen illeszteni vektorokat, és nem kellene azzal vacakolni, hogy bitmapból készítünk görbéket.

De persze lehet, hogy a 2023-as PS ezt már tudja is. Talán. Nem zárnám ki.
Sőt, tudhatja a 2022-es is.

Html kód WordPress site aloldalakon

Html kód WordPress site aloldalakon

Beilleszthető-e egyszerű html a wordpress oldalakba? Nos igen, elég egyszerűen beilleszthető, ugyanakkor az adott html oldal megjelenítését szolgáló css berakása már nehézkesebb lehet.

 

HOGY RAKJUNK BE HTML KÓDOT A WORDPRESS-BE?

Nyissunk egy új oldalt, mentsük a megfelelő néven, majd váltsunk át a szövegszerkesztő jobb sarkában látható “html” nézetre. Ekkor vált a szerkesztő ablak, és beilleszthetjük a html kódunkat.

De ilyenkor még két hiány meg fog mutatkozni a megjelenített oldalunkon, 1. nincsenek benne a képek, és szét van zilálódva a kinézet, mivel 2. hiányoznak a stílusleírók.
A html-t átböngészve kikereshetjük a képlinkeket, és egyrészt azokat át kell írni úgy, hogy a site saját könyvtárára hivatkozzanak, másrészt e képeket fel is kell tölteni. (nagyon ajánlott ezt megtenni.)
Elsőként töltsük fel a hiányzó képeket. Minden képnek megmutatja a WP a linkjét a médiatárban, ezt másoljuk ki, és illesszük be a html-ben a “régi” link helyére felülírva a kép megörökölt elérési útvonalát. Ha ezekkel megvagyunk, akkor a css-t kell beintegrálnunk az oldalunkba.
Ehhez én Add Custom Css plugint használok, mely lehetővé teszi azt is, hogy oldalanként is különböző css-ekkel működtessük a site tartalmait. Az itt található MINTÁK esetén a korábbi site-om összes css-ét össze kellett másolnom egymás után, ami kicsit kellemetlen volt, mivel vagy 10 css-t is használtam a korábbi weblaphoz.

 

 

A WP-be ágyazott Html minta oldalak itt nézhetők meg:

https://webdesigner-grafikus.hu/wp-be-szerkesztett-html-e-f/ https://webdesigner-grafikus.hu/wp-be-szerkesztett-html-kieg/ https://webdesigner-grafikus.hu/wp-be-szerkesztett-html-h/ https://webdesigner-grafikus.hu/wp-be-szerkesztett-html-mf/

 

 

MENNYIRE GYORS A WORDPRESS HTML-EKKEL?

A WP nagyon gyors ha puszta html-eket teszünk oldalainkba, de inkább csak úgy, ha nem oldalanként tesszük be a stílusleírókat, hanem ha ezeket a site globális stílusleírójába szerkesztjük be.

 

Utóirat:
A profik inkább “XYZ Html” plugint használjanak. Az ilyen kódot shortcode-dal tudjuk betenni több oldalunkba is!

 

 

Retusálni kötelező, legalábbis egyes területeken

Retusálni kötelező, legalábbis egyes területeken

Egyáltalán nem tudatosul sem a közönség köreiben, sem a grafikusok között, hogy bizonyos területeken lényegében kötelező a retusálás.

Ilyenkor általában a környezetet cseréljük ki, eltüntetjük a figyelemelterelő részleteket, és alkalmasint megszépítjük a képen szereplő személyeket. Ha a képen nincsenek emberek, akkor betesszük őket kivágott formátumban a képen szereplő “enteriőrbe”, és színüket a képhez igazítjuk. Ha arcuk nem megfelelő az adott reklámkampányhoz, akkor azt is “kijavítjuk”.
De persze nem csak a retusálás egyre inkább alapvető igény, de a 3D-s modellezés is, és az ilyen tárgyfotók esetén a környezet általánosan retusálás eredménye.

Saját retusálási munkák.


A RETUS KORLÁTAI
Ugyanakkor vannak erős korlátai is ennek a tevékenységnek. Egyrészről az, hogy a beillesztett képrészlet PERSPEKTÍVÁBAN, és MEGVILÁGÍTÁSBAN is bele kell símuljon abba a környezetbe, ahová beszerkesztenénk. Előfordulhat, -és elő is fordul az,- hogy egy avatottabb személőnek kitűnik, hogy a beillesztett ember vagy tárgy méreteiben túl nagy, vagy túl kicsi, amit a horizonthoz való viszonya jelez. A megvilágítás nem megfelelő iránya is valószerűtlenné tehet egy beillesztett embert egy adott környezetbe, ilyenkor az “objektum” önárnyéka van többnyire rossz oldalon.

A másik probléma az, ha napfényes környezetbe szeretnénk műtermi fénnyel megvilágított tárgyat tenni, mert ezt jól megoldani lényegében képtelenség, ugyanis egy műfényes tárgyat retussal napfényessé tenni gyakorlati képtelenség Photoshopban.
Minőségi retusálásra meg csak az adja a fejét, aki a Photoshop (grayscale) maszkolási megoldását és a layerműveleteket is ismeri. Meg még sokminden mást is.

 

Retus a nagyvilágból.