Monthly Archives: április 2023

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.

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.

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…

Html site kezdőlap>

Html site – Termék gyűjtőoldal>

Html site – Termék oldal>

Html site – Vegyes tartalmú oldal>

Html site – Vegyes oldal>

Html site – Vegyes termék oldal>

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

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.

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ő.

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

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.

Összenyomom az adott képet kb 1.000 pixelre.

Á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.

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.