ugrás a tartalomhoz

Használható PSD-k

Hidvégi Gábor · 2012. Feb. 17. (P), 01.13

Sok helyen nem a grafikusok végzik a HTML elkészítését, emiatt szükség lehet arra, hogy olyan formában adják át a látványtervet a sitebuilderek részére, ami jó esetben szükségtelenné teszi az utólagos kommunikációt, mert minden egyértelmű benne, továbbá könnyebbé teszi a munkát, ha fél év múlva kell elővennünk az anyagot. Ehhez szeretnék segítséget nyújtani, bemutatva jó és rossz példákat (a szakmában kvázi-szabvánnyá vált Photoshopon keresztül, de az elvek természetesen más szoftverre is alkalmazhatóak), továbbá várom a nyájas olvasók további javaslatait. A felsoroltak jórésze sokak számára magától értetődő lehet, de ne felejtkezzünk el azokról, akik nemrég csöppentek bele a szakmába, és még nincs meg a megfelelő gyakorlatuk.

Nevezéktan és fájlok

Hogyan nevezzük el jól a látványterveinket? Egy volt grafikus kollegámat állítottam egyszer falhoz, hogy a szerveren miért /projektnev/projektnev_oldalnev.psd mintával mentik a fájlokat, hisz nagyfokú redundancia fedezhető fel benne. A válasz teljesen logikus volt: egyrészt azért, mert a (régebbi) Photoshopokban a korábban megnyitott fájlok listájában csak a fájlnév szerepel, és ha két munkában is fooldal.psd nevet adtunk kezdőlapunknak, akkor ha újból meg szeretnénk nyitni az egyiket, találgatunk kell, melyik volt az. Emellett akkor is hasznos, ha a projektnév szerepel a psd nevében, ha továbbküldjük bárkinek (pl. az ügyfélnek, a projektmenedzsernek stb.), akkor ő is később könnyebben be tudja azonosítani a tartalmát, miután lementette a gépére.

A nevezéktannal kapcsolatban még egy apróság van, ami bosszúságot okozhat, mégpedig az ékezetes betűk és szóközök a fájlnévben, mert sajnos minden operációs rendszerben máshogy oldották meg ezt a problémát. Még csak a XXI. században vagyunk, ezért célszerű csak az angol ábécé betűit használni, elválasztásként pedig kötőjelet vagy aláhúzást (és ez a szabály érvényes bármely, szerverre feltöltött állományra, például dokumentációra is).

A Photoshop fájlformátuma minden újabb verziónál változik, és előfordulhat, hogy a szoftver korábbi változata nem képes helyesen beolvasni a legutóbbival készített psd-inket. Szerencsére mentéskor felajánlja, hogy maximalizálja a kompatibilitást, és ha ez nem jár hátránnyal, az Edit, Preferences, File Handling ablakban a Maximize PSD and PSB File Compatibility-nél válasszuk az Always lehetőséget. Ugyanebben a dialógusablakban győződjünk meg róla, hogy az Image Previews-nál az Always Save-et adtuk-e meg, mert bár így valamennyivel nagyobb lesz a fájlunk, de egy egyszerű képnézegető programmal is meg lehet nézni, és nem kell a jóval erőforrásigényesebb Photoshop megnyitását megvárni, ha valaki át szeretné pörgetni a kapott látványterveket.

Nagyban segíti a sitebuilder munkáját, ha az alapinformációkat leírjuk egy levélben, vagy egy kis txt-ben csatoljuk a grafikák mellé. Ilyenek például a folyószövegekben használt betűtípusok, betűméretek és színek, sorok közti távolság, elemek közti távolságok, alapelvek („ez és ez a doboz minden oldal tetején jelenjen meg, nem tettem be minden psd-be”), az egyes elemek „over” állapotai stb.

Érdemes a munka kezdetekor egy könyvtárba a felhasznált extra betűtípusokat is bemásolni, hogy átadás után ne kelljen őket külön-külön keresgetni. Mielőtt elkezdünk dolgozni velük, érdemes a fontokat alaposan átnézni, hogy megvan-e bennük minden betű (nemrég találkoztam eggyel, ahol például hiányzott a 7-es karakter), valamint azt is, hogy a magyar ékezetek benne vannak-e (külföldi oldalról letöltött ingyenes betűkészletben valószínűleg nincsenek), mert ha nem, akkor a módosításokat valószínűleg magunknak kell elvégezni a megfelelő szoftver segítségével.

Rétegek

A 2003-ban megjelent Photoshop CS a mi szemszögünkből egyik legfontosabb újítása volt az egymásba ágyazható layerset-ek lehetősége, mindenkit bátorítok, hogy éljen vele. Ahogy a kész weboldalon, úgy a psd-ben is érdemes az oldalt különböző szekciókra, fejlécre, láblécre, tartalomra stb. bontani, ez a mi munkánkat is jelentősen megkönnyíti; a layerset-eknek a könnyű beazonosítás végett mindenképp adjunk nevet. Ez amiatt fontos, hogy a látványterv szétvágásakor ilyen egységenként lehessen ki-be kapcsolni a láthatóságot, mert sokszor szükség van arra, hogy egy bizonyos réteget (például egy háttérképet) könnyen meg lehessen találni, ami enélkül meglehetősen nehézkes. Ha van időnk, akár az egyes rétegeknek is adhatunk nevet, ami akkor hasznos, ha például a psd-ben lévő termékképek között kell megtalálni a nekünk megfelelőt.

Az egyes elemek „over” állapotáról se felejtkezzünk el, ha lehet, ezeket tegyük külön layerset-be, hogy egyszerre lehessen ki-be kapcsolni, mert így könnyebb megtalálni, mi az, ami változik. Sőt, érdemes rááldozni az időt, és a több állapottal rendelkező, általános elemeket (gombok, címek és társaik) egy külön psd-be menteni, mert ezzel is gyorsabban készülhet el az oldal, valamint a későbbi karbantartás is könnyebbé válik.

Arra ügyeljünk, hogy legalább az eredeti fájlban ne vonjunk össze rétegeket (a többibe bekerülhetnek képként bizonyos nem változó elemek, például a fejléc vagy a lábléc, mert így kevesebb erőforrásra lesz szüksége a Photoshopnak, és gyorsabb lesz a munka), s így nem kell a sitebuildernek azon gondolkodnia, hogyan tudja reprodukálni azt, amit mi elképzeltünk, de lehetőleg HTML elemekből, és nem képként.

Dolgozzunk pontosan és következetesen! Első munkahelyemen a frontendes kollegákba beleverték, hogy minden HTML-t úgy kell elkészíteni, ahogy a grafikus megálmodta, mert minden pixelnek megvan a maga szerepe. Ehhez viszont ügyelni kell arra, hogy ha egy doboznak öt pixeles keretet adtunk, akkor az összes látványterven ugyanannyi legyen, mert ha jön a projektmenedzser, összehasonlítja a psd-t a böngészővel, és ott eltérést talál, mert a sitebuilder a grafikához híven hét pixelt használt egy helyen, akkor jön az egymásramutogatás. Ugyanez igaz a betűméretekre és színekre is, ráadásul, ha fél év múlva elő kell szednünk egy új kérés miatt a munkát, mi sem fogunk már emlékezni, hogy melyik volt az eredeti elképzelésünk.

Tartalom és forma

A legtöbb dizájner elköveti azt a hibát, hogy amikor a tartalom különböző dobozokból áll, akkor az egymás mellett lévőket ugyanolyan magasra veszi. Ez a látványterven nagyon jól néz ki, csak sajnos átadás után azonnal borul a bili, amikor az ügyfél kétsoros címeket tölt fel, és az egyik dobozunk magasabb lesz, mint a másik. A helyzetet csak bonyolíthatja, ha az elem háttere egy szép színátmenetet és-vagy egyéb grafikát tartalmaz, ami nagyon nem jól néz ki, ha nyúlik a tartalom. Éppen emiatt fontos, mindig úgy készítsük el a grafikát, hogy gondoljunk az ilyen esetekre, hogy rögtön az elején kiderüljön, szép-e, megfelelő-e az eredeti elképzelésünk.

Vegyük figyelembe, hogy a sitebuildereknek nem kell profi módon érteniük a Photoshophoz, tudásuk sokszor kimerül a kijelölés–kivágás–beillesztés parancsokban, és ez így is van rendjén. Amikor dolgozunk, gondoljuk át, hogy az adott elképzelést ő tudja-e reprodukálni. Jó példa erre az, amikor van egy képünk, aminek van egy lekerekített vagy letört sarka, akkor ez utóbbi grafikai effektus legyen külön rétegen, hogy alatta a képet könnyen ki lehessen cserélni, és ne egyben kelljen az egészet kivágni.

Ha az oldal háttere egy ismétlődő amorf alakzat, akkor mindenképp mellékeljük a mintát, mert nincs annál szemgyilkosabb feladat, mint amikor egy ilyen képen kell megtalálni az eredeti alakzatot. A helyzetet már csak azzal fokozhatjuk, ha az oldalon alacsony a kontraszt, például fekete alapon sötét betűk, ilyenkor ne csodálkozzunk, ha édesanyánk sűrű csuklási rohamokról panaszkodik, nem csak a HTML munkálatok során, hanem az élesítes után is.

Hogyan dolgozzunk?

Befejezésként két, egymásnak valamennyire ellentmondó gondolatot szeretnék megosztani.

Joó Ádám webes tipográfiáról szóló előadásának egyik mondanivalója, hogy ismerjük meg alaposan azt a médiumot, amire tervezünk. Ez azt jelenti, hogy legyünk tisztában a webes szabványokkal, a különböző böngészők lehetőségeivel, valamint a hardverrel, amin az oldalunkat a látogatók meg fogják nézni, és ezeket a szempontokat vegyük figyelembe a látványterv készítésekor. Ha fontos a mobileszközökön való megjelenés, ahol a letöltés lassú, drága, és a feldolgozási sebesség is hagy kívánnivalót maga után, akkor a funkcionalitás valószínűleg fontosabb lesz, mint a látványos megjelenés, ha idősebbek vagy fogyatékkal élők a célcsoport, akkor ne kilenc pixeles betűtípust használjunk és így tovább.

A hatékony és jó munkához viszont fontos tisztában lenni a határokkal. Amikor egy új weboldalon kezdünk el dolgozni, nyugodtan engedjük el a fantáziánkat, felejtsük el, hogy mit tudunk a technológiáról, mire képesek a browserek, mik az aktuális divatirányzatok, és valósítsuk meg azt, amit számunkra a feladat jelent. Ha elkészültünk, menjünk oda a sitebuilderhez, és mondjuk meg neki, hogy pixelre pontosan ezt szeretnénk látni az elkészült site-on, nem érdekelnek a kifogásai. Engedményeket akkor tegyünk, ha már vért izzad, és tizedik nekifutásra sem sikerült megoldania egy problémát. A végeredmény? Mi kreatívabbak leszünk, kollegáink tapasztaltabbak, az internet pedig gazdagabb.

 
1

Jó cikk, mondjuk én szívesen

inf3rno · 2012. Feb. 17. (P), 02.35
Jó cikk, mondjuk én szívesen láttam volna képeket is, ha már PSD-ről van szó :-) (Nekem az a jellemzőm, hogy példákból sokkal könnyebben tanulok...)
5

Képek

Hidvégi Gábor · 2012. Feb. 17. (P), 08.53
Sajnos nem nagyon jutott eszembe épkézláb ötlet.
2

A 2003-ban megjelent

Poetro · 2012. Feb. 17. (P), 03.14
A 2003-ban megjelent Photoshop CS a mi szemszögünkből egyik legfontosabb újítása volt az egymásba ágyazható layerset-ek lehetősége, mindenkit bátorítok, hogy éljen vele.

Én azért inkább kerülném, mert más programokban gondot okozhat, és nem mindenkinek van meg a Photoshop. Azaz ha csak GIMP vagy más hasonló jellegű szerkesztő van meg valakinek, akkor érdemesebb inkább csak sima rétegeket használni, nehogy valami probléma legyen, mondjuk nem látszik valami emiatt, vagy egyesülnek a rétegek. És szerintem nem minden fejlesztő rendelkezik Photoshop-pal, nekem a tavalyi évig kellett várnom, hogy összejöjjön az a "felesleges" 220eHUF amibe kerül. Addig én GIMP-et illetve Paint.NET-et használtam a PSD fájlok olvasására.
3

Ha hosszú távú befektetésnek

inf3rno · 2012. Feb. 17. (P), 04.24
Ha hosszú távú befektetésnek tekinted, akkor egyáltalán nem felesleges... Egyébként a GIMP-hez képest milyen plussz az, amiért megéri megvenni? (nem mintha elkezdenék designerkedni, csak érdekel a különbség, ami megér ennyi pénzt...)
4

Talán amiatt éri megvenni,

Hidvégi Gábor · 2012. Feb. 17. (P), 08.26
Talán amiatt éri megvenni, hogy ne legyenek kompatibilitási problémák. Szerintem túlárazott esetünkben program, ráadásul mint sitebuilder a kijelölés-másolás-beillesztés műveleteknél nem nagyon használ többet az ember.
6

Photoshop Elements

Max Logan · 2012. Feb. 17. (P), 10.37
Nem tudom, hogy milyen komolyabb dolgokat használnak ki manapság a webdesignerek, amit a Photoshop tud, azonban az Elements nem. Mert ha nem sokat, vagy megoldható az adott dolog raszterizálása, akkor a sitebuildernek már bőven elég lehet a Photoshop Elements, mely nagyságrendekkel kevesebbe kerül.
8

Photoshop Elements (10)

Hidvégi Gábor · 2012. Feb. 17. (P), 11.42
Kipróbáltam, gond nélkül megnyitja a Photoshop CS 5.5 által készített fájlokat, egyetlen dolgot nem tud: a Layerseteket nem lehet vele kinyitni-bezárni, ilyenkor azt ajánlja fel, hogy a benne levő rétegeket összevonja.

Bár ez szerintem körülményesebbé teszi a munkát, de ha meg lehet egyezni a grafikussal, hogy layersetek nélkül dolgozzon, akkor szerintem a sitebuildernek bőven elég ez a harmincezer forintos program.
9

Színek

Max Logan · 2012. Feb. 17. (P), 12.03
A mappa végülis csak egy egységbe fogja -- jó, ennél azért azt hiszem komolyabb lehetőségeket rejt magában a feature -- a layer-eket, de ettől függetlenül a sorrendnek ott is stimmelnie kell. Így szerintem kiváltható a mappába rendezés a layer palettán való színek beállításával. Minden szín egy-egy mappát helyettesít.
7

The Photoshop Etiquette Manifesto for Web Designers

Wabbitseason · 2012. Feb. 17. (P), 11.25
Hátha valaki még nem ismeri:

The Photoshop Etiquette Manifesto for Web Designers

A cikk témájához kapcsolódó kiáltvány illusztrációkkal, pontokba szedve.
10

Grafikusok

Gixx · 2012. Feb. 17. (P), 12.55
Nekem még van pár hozzáfűznivalóm, főleg a következetesség részhez:

- szögletes dobozok tervezésekor Antialias = OFF legyen, mert akkor az esetleges bordereket CSS-sel is meg lehet oldani pixelpontosan

- alakzatok elhelyezésekor használjanak segédvonalakat Shift lenyomásával, hogy biztosan pixelre helyeződjön minden, mert számomra az egyik legidegesítőbb a "fél pixel"-re helyezett elem. Igen, van ilyen. Hurrá.

- 5-0 szabály. Minden méret 5-re vagy 0-ra végződjön. Az irritáció magasfoka, amikor pl. 263x221-es képekből kell galériát összerakni. Számold ki fejben, hogy a képek között (jóesetben következetesen) 7px távolságot hagyva, 1px-es borderrel a 3. sor 4. képe hova kerül.
Border-es kép/doboz esetében "box-sizing: border-box;" elvet követve (vagyis a borderrel együtt számolt mérete) legyen alkalmazva az 5-0 szabály. A margin és a padding mindig következetesen 5-0 (esetleg margin+border vagy border+padding is összevonható), és lehetőleg a sormagasság is. Kivétel a betűméret, mert a sormagasság már úgyis befoglalja egy adott helyre.

- a betűméreteket mindig pixelben ellenőrizzék, mert szép meg jó a pt, csakhogy más a PS-ben és más a böngészőben. 14,27px-es betűvel meg nem lehet dolgozni. Van, ami támogatja, van, ami nem, van ami simán csak elcseszi. Pixel legyen és kerek szám. És élsímítás nélkül. Vagy legalábbis max rendszerszintű élsímítással.

- gradiensek használatakor (főleg radial esetén) csak a lényeg legyen ott, ne a forntendesnek kelljen keresni a plecsni "végét".

- gradiensek NE csússzanak egymásba

- az árnyékok manapság már kevésbé szivatósak, hála a css3 támogatottság térnyerésének, de azért lehetőleg kerüljék el a több színen (neadjisten gradiensen) áthaladó, lekerekített dobozokhoz odarittyentett árnyékokat. És semmiképp ne szivassák az embert két árnyék "nem" keresztezésével (vagyis amikor keresztezi egymást két árnyék, de nincs duplázódás, hanem olyan, mintha egyben lenne).

- ne tervezzenek olyat, amit csak --webkit vagy --moz kapcsolóval lehet csak megcsinálni.

- ne vigyék túlzásba az űrlapok egyediesítését.

- ne tervezzenek 1920*1080-as egyedi hátteret. Amelyik háttér nem oldható meg maximum 300*300 pixelből, az kuka.
11

Szerintem

Hidvégi Gábor · 2012. Feb. 17. (P), 13.11
Az általad leírtak többségét minden gond nélkül meg lehet oldani több-kevesebb munkával, és mivel nem az a cél, hogy a sitebuilder kényelmét keressék a grafikusok, nem ajánlanám ezeket senkinek.
12

Én ajánlanám :P

Gixx · 2012. Feb. 17. (P), 13.44
A következetesség a kerek egész iránti törekvés és a globális harmónia jegyében én viszont mindenképp ajánlom :)

Mert ha ezek nincsenek meg, (főleg a félpixel, az antialias border meg a nem egész betűméretek), akkor ne pampogjon pixelpontosság miatt se grafikus, se PM.
15

Off

Hidvégi Gábor · 2012. Feb. 17. (P), 15.18
A következetesség a kerek egész iránti törekvés és a globális harmónia jegyében én viszont mindenképp ajánlom :)
Én pedig ajánlom a figyelmedbe a következő reklámot: A company of dreamers : )
17

Re off

zzrek · 2012. Feb. 17. (P), 20.58
Jó reklám, de csak reklám. Érzelmekre hat, az igazságtartalma nem lényeges. Ha az autógyár álmodozókból állna és nem komoly mérnökökből, akkor az első gurulás után nem maradna a kocsiból por se.
Ha a tervező/grafikus/designer, aki a kocsit megrajzolja, nem lenne egészen pontosan tisztában vele, hogy mit lehet és mit nem, akkor virágcsokor, kiscica, női mell, vagy bicepsz alakú kocsikat tervezne ;-)
19

Kiscica, női mell és virágcsokor

RedPoppy · 2012. Feb. 19. (V), 20.55
Már régóta jelenlévő elem a tervezésben, hogy - a te példádnál maradva - pl. az autókat állatokra emlékeztető formákkal csinálják meg. Pontosan azért, hogy érzelmileg lehessen kötődni hozzájuk.
De ez mindenben jelen van, csak a többség nem veszi észre, és a hatása megmarad tudatalatti szinten.
13

Szerintem

zzrek · 2012. Feb. 17. (P), 13.51
Szerintem meg jó, ha a munka mennyisége arányban van az elkészült mű értékével, ezért jó, ha a tervező tudja, hogy mit lehet egyszerűen és hatékonyan megoldani a böngészőkben és mit nem. Ezernyi olyan elem lehet, amit "majdnem úgy" könnyen meg lehet oldani, de "tökéletesen úgy" pedig macerás, nem optimális -- pedig a végén látványban alig van különbség (és nem is biztos, hogy az egyszerűen megoldott a csúnyább)
Szerintem nem igényes az a tervező, aki nem tájékozódik arról, hogy a terve mennyire optimálisan valósítható meg a végleges környezetben. (És ezt minden területre érvényesnek érzem, nem csak az informatikára: az építőipartól a ruhatervezésig, a hadiipartól a cukrászatig stb.)
14

1, a grafikus nagyjából

Hidvégi Gábor · 2012. Feb. 17. (P), 14.07
1, a grafikus nagyjából tisztában van a büdzsével vagy a rendelkezésre álló idővel, alacsony költségvetésnél valószínűleg nem fog túl bonyolult látványtervet készíteni

2, szerintem ezt úgy kell felfogni, hogy egy összetett grafikai elem megvalósításánál szükség esetén mindig lehet engedményeket tenni, míg akkor, ha eleve úgy tervezte meg a grafikus, hogy az lebegett a szeme előtt, mit lehet és mit nem, akkor valószínűleg sokkal alacsonyabb színvonalú munkát ad ki a kezéből. Magyarul: sokból lehet engedni, kevésből már nem.
16

Nem alacsonyabb színvonalú

zzrek · 2012. Feb. 17. (P), 20.49
Nem nevezném alacsonyabb színvonalú munkának azt, ha valaki képes, igénye van rá és tapasztalt abban, hogy a munkája során a körülményekhez alkalmazkodjon.
Más szóval: ha a grafikus igényes, a tudása kiterjed a technikai lehetőségekre, akkor a munkája értékesebb, a projekt számára hasznosabb, vagyis magasabb színvonalú.
Még tovább menve: hasznos, ha ő maga, a grafikai szakértő/designer/művész/tervező lesz képes eldönteni hogy a terve mennyire reális és meddig mehet el --- és épp ettől lesz a lehető legszínvonalasabb a grafikai megoldás.

Ellenben ha nem ért hozzá, nem érdekli, kényes és nem igényes, nem lát tovább a szűken értelmezett eszközeinél, akkor nem is lehet a munkája olyan színvonalas.
Ha ilyen esetben "valószínűleg alacsonyabb színvonalú" munkát ad ki a kezéből, akkor azt nem azért teszi, mert az lebeg a szeme előtt, hogy mit lehet és mit nem, hanem azért, mert "amit lehet" annak a lehetőségeit nem ismeri eléggé, és ezért nem elég bátran használja ki (nem elég tapasztalt a munkája egy fontos elemében).

Nem azt mondom, hogy egy grafikusnak mindent tudnia kell a technológiáról, de minél többet tud, annál jobb. A technológia fejlődése hoz ráadásul egy csomó trendet, amiben úttörő csak akkor lehet, ha ezeket a lehetőségeket idejekorán megismeri.
21

tvábbá:)

RedPoppy · 2012. Feb. 19. (V), 21.08
... és nemutolsó sorban könnyebb is a munkája, ha a körülményekhez igazodik. De ha nem megy, akkor nem megy. Vagy közöljük a megrendelővel, hogy nem vagy hajlandó megcsinálni neki, mert blődség, és elküljük a Bugris Bt.-hez aki hajlandó neki kiscicás animgifekkel telirakni az oldalát, vagy megcsináljuk.
Az első esetben másnak fog fizetni és nem nekünk, a másodikban meg legfeljebb nem tesszük ki referenciának, de nem csúszik a fizu.

Lehet választani, ki melyiket szeretné.
20

Ez tetszett.

RedPoppy · 2012. Feb. 19. (V), 21.04
Viszont, egyvalamibe belekötnék; "- ne tervezzenek 1920*1080-as egyedi hátteret. Amelyik háttér nem oldható meg maximum 300*300 pixelből, az kuka."

Akár tetszik neked (vagy nekem), a grafikus elsősorban az ügyfél ízlésének megfelelő látványtervet csinál. Ha az ügyfél semmibe nyúló pusztát szeretne lófejkoponya sziluettekkel és lila lepkékkel, akkor a grafikus néhány felesleges kör magyarázat után olyat fog neki legyártani, mert szintén ha tetszik, ha nem alapon, a cég a kifizetett projektekből él.

Tehát vegyük már tudomásul, hogy nem minden problémát a grafkusra kell kenni (egyáltalán, semmilyen problémát nem kell másra kenni, kérdezni és kommunikálni kell - tudom, ezt már mondtam ma), hanem ha az ügyfél olyat akar, akkor olyan lesz. És nem, a grafikus nem óvónéni, hogy mindenről elmagyarázgassa egyesével, hogy ez most miért hülyeség, akkor sem, ha tisztában van a technikai lehetőségekkel.

Annyira lelkes mindenki, amikor a problémákat másokra kell hárítani, de amikor egy kis kreativitást kéne felmutatni, egyből mély és néma csend lesz. Ki érti ezt.
18

"A legtöbb dizájner elköveti

RedPoppy · 2012. Feb. 19. (V), 20.52
"A legtöbb dizájner elköveti azt a hibát, hogy amikor a tartalom különböző dobozokból áll, akkor az egymás mellett lévőket ugyanolyan magasra veszi. Ez a látványterven nagyon jól néz ki, csak sajnos átadás után azonnal borul a bili"

A designer dolga a látványterv elfogadtatása. Akkor kap pénzt érte. Ti ezt nem tudtátok?

A többit illetően, talán megfelelően meg kellene fizetni az embereket. De amikor egyesek abszolút korrektnek tartják a 15000 forintos számlás árat egy layoutért (nem akarok neveket írni, de az itt rendszeresen publikálók közül is van olyan), akkor nem kell csodálkozni, hogy azt kapsz, amit. Nem kicseszés, csak automatikusan csökken a prjektre rászánható időkeret. :)

Értem hogy ez téged mint sitebuildert nem vigasztal, de erről a főnökséggel kell egyeztetni. Édeaanyákat meg nem illik felemlegetni, főleg olyankor nem, amikor jóval praktikusabb szólni a grafikusnak, hogy figyelj, ezt másképp kellene.

Csak ehhez persze meg kellene tanulni kommunikálni.
22

A designer dolga a

Hidvégi Gábor · 2012. Feb. 19. (V), 21.09
A designer dolga a látványterv elfogadtatása.
Részben.

talán megfelelően meg kellene fizetni az embereket
A "legtöbb dizájner"-nek részhalmaza a "jól fizetett dizájner" csoport is, szóval nem csak ettől függ.

egyesek abszolút korrektnek tartják a 15000 forintos számlás árat egy layoutért
Szerintem a programozók és a sitebuilderek is küzdenek hasonló problémákkal.

Csak ehhez persze meg kellene tanulni kommunikálni.
Ha a hegy nem megy Mohamedhez...
23

Ha a hegy nem megy Mohamedhez...

RedPoppy · 2012. Feb. 19. (V), 21.14
"Ha a hegy nem megy Mohamedhez..."

Ezt konkrétan hogyan? :)

Ha neked vsn problémád, hívogassalak fel hetente háromszor, hogy figyelj, nincs-e valami problémád?

Szvsz nem csak részben. Ha neverending sztorivá alakul az egyeztetés, az senkinek nem hasznos, mert megy az idő, és csúszik a pénz. Sok megrendelőnek NEM LEHET elmagyarázni, hogy ezt miért nem lehetséges megoldani, ő már látott olyat, és kész.

Érdemes néha összehasonlítani az elsőkörös látványterveket a végeredménnyel.

A jólfizetettség meg relatív.
Amiket itt leírtatok, az cca. 4-5 óra utómunkát jelentene alsó hangon is. Namost, ez olyan 75000/látványterv árnál gond nélkül belefér. Viszont a többség már a felénél is húzza a száját. Persze lehet, hogy egyszerűen én válogatom rossz helyről az ügyfélkörömet. :)
25

Ha a hegy nem megy

Hidvégi Gábor · 2012. Feb. 19. (V), 21.21
Ha a hegy nem megy Mohamedhez...
Itt arra gondoltam, hogy ha a sitebuilderek nem mondják el a nyűgjeiket, akkor a grafikusok bátorítsák őket erre. Nem kell heti háromszor, az elején le kell tisztázni mindent, ki-mit-hogyan szeretne, aztán ahhoz tartsa magát mindenki.
Ez a cikk többek között azért született, hogy közvetlenebb kapcsolatot teremtsen a két szakma között.

Amiket itt leírtatok, az cca. 4-5 óra utómunkát jelentene alsó hangon is.
Ha nem fér bele, akkor nem fér bele. De ha mégis, akkor szerintem mindkét fél nyer vele.
28

De ha mégis, akkor szerintem mindkét fél nyer vele. De ha mégis

RedPoppy · 2012. Feb. 19. (V), 21.26
Ha nem fér bele, akkor nem fér bele. De ha mégis, akkor szerintem mindkét fél nyer vele.


Persze, nem is azt vitattam, hogy nem ez lenne az ideális. Ez lenne, de néha ez nincs átfedésben a lehetőségekkel. :)
24

ezt itt hogy?

RedPoppy · 2012. Feb. 19. (V), 21.18
Hogy lehet ilyen idézőjelet csinálni?
26

Formázás

Hidvégi Gábor · 2012. Feb. 19. (V), 21.22
"A hozzászólás szövege" beviteli mező alatt van pár formázási lehetőség.
27

jé tényleg

RedPoppy · 2012. Feb. 19. (V), 21.23
Megvan, köszi. :)
29

Kedves grafikus, designer

Mac08 · 2012. Feb. 22. (Sze), 17.46
Kedves grafikus, designer kollégáknak jelezném, mint programozó és builder, hogy PS helyett a webgrafikára a FireWorks-t használják, mert ahhoz az van kitalálva :-P
30

Hát...

SneakySnail · 2012. Feb. 24. (P), 15.51
Hát.. szerintem te sem örülnél, ha valaki meg akarná mondani neked, hogy akkor mostantól csak az XY programban írhatsz kódot, mert ahhoz van kitalálva :)

A PS, mivel pixel alapon (is) számol, mondhatni ugyanúgy arra van kitalálva [az egyéb alkalmazási területek mellett]. Arról nem is beszélve, hogy a szakma 95%-a feltehetően nem fog a kedvedért átszokni :)

(Mondom ezt, mint grafikus és sitebuilder)
31

Fireworks

RedPoppy · 2012. Feb. 25. (Szo), 13.19
Mint grafikus, javasolnám, hogy maradj a programozásnál és a sitebuildnél. Ha meg úgy gondolod hogy jobban csinálnád, csináld (sokan gondoljátok úgy, aztán valamiért szinte mindenki értékelhetetlen eredményt rak le, amikor megpróbálja).
32

Nyugi

Hidvégi Gábor · 2012. Feb. 25. (Szo), 13.37
Nem kell mindent a személyed elleni támadásnak venni.
33

:)

RedPoppy · 2012. Feb. 25. (Szo), 23.52
A szakmám elleni támadásnak vettem. Merthogy véleményem szerint az volt... de ha fel tud hozni érveket amellett, hogy miért akarja megszabni egy teljesen más területnek hogy miért az ő elképzelései szerinti programokkal dolgozzon, amikor ennek a gyakorlattól a józan észig (a végeredmény minőségét is beleértve) minden ellentmond, akkor szívesen visszavonom.

Kevésbé finoman fogalmazva, nagyon unom már, hogy mindenki abba akar beleugatni amit én csinálok, ahelyett hogy a saját munkájával foglalná el magát. (Ezt moderáld kérlek, ha túl erős ide.)

Volt olyan drága kollégám, aki hangosan énekelgette a monitorát nézve egy nyitott irodában mi a gondja a psd-mmel ("mi a f*sz ez a sz*r", stb). Amikor odamentem hozzá, hogy na akkor most meg mondjad nekem, és ne a hátam mögött mindenki másnak hogy mi bajod van, akkor hirtelen mély csend lett.

Nem tudom mennyire gondoltál bele ennél a cikknél hogy milyen mély ellentétek vannak néhol a stebuild és a grafika között, és biztosan nincsenek mindenhol, meg irányelvnek teljesen jók, de. És ott az a "de".
34

Nézzük meg közelebbről a kérdéskört

Max Logan · 2012. Feb. 26. (V), 00.34
Adott a WEB, ahol bő 10 évvel ezelőtt még nem igazán voltak parasztvakítós grafikai megoldások, leszámítva talán az animált GIF-et, de az egy egészen más történet.

Fejlődött a számtech világ, ezzel együtt a vizualitás is, melynek eredményeképpen 2000 után már majd' csak a parasztvakításról szóltak/szólnak a dolgok – akár WEB, akár gamer, akár más területeken.

A Photoshop ipari szabvánnyá nőtte ki magát a WEB-es grafikai területén is, de valljuk be, nagyon nem erre tervezték. Mert amennyire tudom a Photoshop egy professzionális képszerkesztő alkalmazás. De éppen ennél fogva, a WEB-es grafikai igényeket is ki tudja elégíteni.

A probléma tehát meglátásom szerint ott van, hogy a 2000-es években megindult a parasztvakítás – mely többek között a Flash-nek (is) köszönhető – így tehát az önmegvalósítási kényszerben szenvedő grafikusok a profizmusukat fitogtatandó Photoshop-pal dolgoznak és olyan grafikákat csinálnak, amitől hanyat vágja magát a látogató.

A kérdés csak az, hogy erre van-e szükség? Az utóbbi évek terendjét figyelve, valamint a UX design központi kérdéssé való emelkedése okán megkérdőjelezhető. Nem mondom, vannak olyan micro és brand site-ok, ahol jól jön a csicsa, de általánosságban nem ebbe az irányba kellene menni.

És akkor elérkeztünk oda, hogy az Adobe kiadta a Fireworks nevű programot. Őszintén megmondom, hogy nem ismerem a program történetét, de azokból a morzsányi infókból, amiket 20 mp-es keresgélés után találtam, úgy látom, hogy az Adobe ad szakembereknek egy programot, amit éppen a WEB-es grafikai megoldásokhoz terveztek.

Ennek következtében az Adobe a Fireworks-öt ajánlja a webdesignereknek, nem pedig a Photoshop-ot.

Nézzük meg a kérdést egy másik szemszögből. Adott a grafikus és adott a frontend fejlesztő. Ha ők nem egy cégen belül dolgoznak, akkor mindkét félnek meg kell vennie azt a grafikai alkalmazást, mely a munkájához kell. A grafikus ha nem csak WEB-es grafikákkal foglalkozik, nagy valószínűséggel Photoshop-ot használ, melynek ára itthon kb. 265.000 Ft.

A frontend fejlesztőnek csak a slice-olás miatt és esetleges egyéb műveletek (WEB-re publikált fotók optimalizálása) kell a grafikai program, nem használja ki a Photoshop hatalmas tudását. Ennek okán ő nem akar 265.000 Ft-ot fizetni egy olyan programért, amit nem használ ki. Adott neki egy célszoftver, mely itthoni áron kb. 115.000 Ft-ba kerül. A frontend fejlesztő nem fog megvenni egy olyan szoftvert 230%-os áron, amit nem is használ ki, ha ott van neki egy számára fejlesztett célszoftver.

Tehát a fentiekből kiindulva, ha valaki dedikáltan WEB-es designokat készít, akkor megveszi a Fireworks-öt, majd a frontend fejlesztő is megveszi e szoftvert, így minden gond nélkül tudnak együtt dolgozni.

Ha a grafikus nem csak WEB-es design-okat gyárt, akkor megveszi a számára fontos alkalmazásokat (pl. Photoshop vagy Illustrator), de nem erőlteti rá ezeket egy olyan partnerére, akinek semmi, de semmi szüksége nincsen rá.

Én így látom a kérdéskört...
36

kis javítás

Arnold Layne · 2012. Feb. 26. (V), 13.14
És akkor elérkeztünk oda, hogy az Adobe kiadta a Fireworks nevű programot.

Nem egészen, mert megvette. Lyánykori nevén Macromedia Fireworks volt.
37

Valóban

Max Logan · 2012. Feb. 26. (V), 13.31
Ahogyan a Flash és még több program (pl. Dreamweaver) is a Macromedia keze nyomán látott napvilágot, azonban az utóbbi években (a 2005-ös akvizíciótól kezdődően) az Adobe „futtatja” őket.
38

Photoshop Elements

Hidvégi Gábor · 2012. Feb. 26. (V), 14.34
Kompromisszumokkal a sitebuilderek a Photoshop Elements-et is használhatják a munkájukhoz.
39

Valóban

Max Logan · 2012. Feb. 26. (V), 14.59
Ahogyan fentebb említve is vagyon, megoldás lehet Photoshop helyett a Photoshop elements. Viszont ha van az adott feladatra tervezett szoftver, akkor miért ne az lenne az ipari szabvány?!

De ha mindenképpen ragaszkodunk egy általános grafikai programhoz, akkor már inkább legyen Photoshop helyett GIMP, mert ugye ingyenes, no meg platformfüggetlen megoldás.
40

Bár nem ismerem a designerek és sitebuilderek munkáját...

H.Z. v2 · 2012. Feb. 26. (V), 15.13
... de attól tartok, a gimp és a PS Elements nem igazán alkalmas professzionális felhasználásra.
Gimpről hallottam már, hogy komolyabb feladatra is használták, viszont nem derült ki a hírekből, hogy mennyi szívás volt vele.
Kicsit belekontárkodtam a fotózásba, nekem bőven elég volt a 2.0-s PS Elements is (2003-ban kaptam az EOS 300D mellé "ajándékba"), de a gimp-et már nem tudtam használhatóvá tenni.
Hiányoztak belőle olyan lehetőségek, mint pl. a módosító rétegek (v. csak azok mentése?), néha kellett volna 16bites TIFF, ezt sem a PSElements, sem a gimp nem tudja, tán még ma sem stb.
De úgy általánosságban is érződik a gimpről, hogy ingyenes szoftver (szuvenire nyihuhu effekt ;) )

---
PS Elementsből valahol a 4.0-s verzió környékén akadtam el, az alig tudott többet, mint az általam használt 2.0-s, csak volt benne valami katalogizáló funkció, meg egy RAW->JPEG konverter, ha jól emlékszem.
42

Re

Max Logan · 2012. Feb. 26. (V), 15.51
Én úgy gondolom, hogy alapvetően két munkafázisra lehet bontani a webdesign készítést. Az egyik az art grafikusi a másik pedig a webdesigneri fázis.

Előbbi munkafázisban dolgozzon a grafikus azzal, amivel akar. Volt rá számos példa a múltban, hogy 3D-ben terveztek meg grafikákat és azokat használták fel a webdesignban. De ez cseppet sem érdekli a frontend fejlesztőt.

Miért is nem? Azért, mert neki ezek a grafikai elemek csak raszterizált formában jelennek meg a designban.

Tehát ha vesszük a második munkafázist, amikor a layout kerül kialakításra, akkor ott már semmi olyan ördöngősségre nincsen szükség, amihez ne lenne elegendő pl. a GIMP, a Photoshop Elements vagy az éppen erre a célra dedikált Fireworks.

Mondom, egy hiper-szuper brand/micro site egy egészen más kérdéskör, de ott is külön kategóriát, munkafázist kell, hogy jelentsen az art jellegű grafikák elkészítése.

Gondoljunk csak bele, hogy miről is szól a webdesign készítés. Adott egy HTML, CSS alapokon megalkotott layout, melyben mindenhol téglalapokkal dolgozunk. Ergó a webdesign is úgy lesz slice-olva, hogy négyzet vagy téglalap alakú elemeket kapunk.

Látva a CSS3 képességeit (és feltételezve, hogy a következő 5-10 évben ez lesz az alkalmazott technológia), egyre inkább csak sablonokat fognak tervezni a grafikusok és a lényegi megjelenítés CSS alapon lesz megoldva. A UX design fog inkább előtérbe kerülni, mint az art grafikusi képességek. A web nagyobb részben egyébként sem ez utóbbiról szól...
43

Még CSS2-vel is

Pepita · 2012. Feb. 27. (H), 20.29
Látva a CSS3 képességeit (és feltételezve, hogy a következő 5-10 évben ...
Szerintem HTML4-CSS2 párosban is mellőzni kellett volna a 10000 öszze-vissza-vágott képdarabbal történő "dizájnolást" (=gányolást), ezek eredménye mára a milliónyi fixméretű honlap, se mobilon, se WXGA(+)-n nem néznek ki még közel sem normálisnak. Viszont elhitették a megrendelőkkel, hogy a net micsoda varázslatokat tud, pedig szó sincs róla. Szerintem a design-ba annyit szabad erőltetni, amennyi mindennel együtt elfér 200 kbyte-ban, és egy boxnak nincs amiatt +4-6 div-je, hogy a menő keretezést képes legyen megjeleníteni.

Egy eléggé anarchista elképzelés: ha a designer helyből HTML-CSS formában adja tovább a részét... Tudom, mese habbal, de akkor aztán nincs vita a szoftverek terén sem...
44

Akkoriban fix méretű

Hidvégi Gábor · 2012. Feb. 27. (H), 20.47
Akkoriban fix méretű honlapokra volt igény, mára ez megváltozott; szerintem most meg az a hibás elképzelés, hogy ugyanaz a html szolgálja ki a nagy- és a kisfelbontású klienseket.

mindennel együtt elfér 200 kbyte-ban
Ezzel nem értek egyet, egy alkotó embert szerintem csak okkal lehet korlátozni, mert csak elveszti a kreativitását. Szükség van a művészekre, akik megkérdőjelezik az aktuális divatot.
45

Persze,

Pepita · 2012. Feb. 27. (H), 21.01
csak a művész ne az xy cég kezdőoldalán mutassa be művészetét, hanem pl. a "galéria" lapon. Tehát ott, ahol a Júzer számít a komolyabb adatforgalomra. Sok helyen azért "nincs mobilinternet", mert van, csak pl. a régi modemes sebességű. Na, ha Júzer ilyen helyen van, már ne is láthassa a cég oldalát! Ezt vitatom.

Ja, a HTML szerintem vígan lehet ugyanaz, CSS kell más a mobilnak. Miért adnánk más tartalmat a másik megjelenítőnek? (Persze esetleges feleslege sidebox, de az csak display: none.)
46

A grafikán spórolnál, a

Hidvégi Gábor · 2012. Feb. 28. (K), 00.26
A grafikán spórolnál, a tartalmon akkor miért nem? Teljesen mást kell szerintem kiküldeni egy mobilra, mint egy 24 hüvelykes képernyőre, pont most van erről a témáról egy blogmark.
47

Más...

Max Logan · 2012. Feb. 28. (K), 01.10
Az az igazság, hogy ma teljesen mást értünk WEB alatt, mint amikor elindult a történet. Ennek következtében már évek óta specializálódott formában kellene ehhez a történethoz hozzáálni.

Úgy látom, hogy még csak mostanában indult meg ez a specializálódás a szolgáltató cégek részéről és még évek telnek el, mire a piacon úgy általánosságban látszani fog, hogy tudják annak kezelni a fejlesztők a WEB-et, amivé vált...
48

Attól függ.

Pepita · 2012. Feb. 28. (K), 01.44
- Ha tartalmon szöveges tartalmat értünk, akkor egyértelmű, nem? U. azt kiírhatom a mobilra is, persze nem u.akkora betűkkel (csak relatíve akkora). Lehet kevésbé fontos tartalmat eltüntetni (itt pl. a sidebox-ot), de kár azért a kb. 500 byte-ért külön "tartalomkezelni" a mobileszközt, sima css.
- Grafika, képek: itt kell spórolni, mert itt lehet is (design felől), és érdemes is. Persze, amikor egy tartalom lényege maga a kép, akkor nem szabad lespórolni, de lehetőleg minél kisebb (még élvezhető) méretben kiküldeni. (Ezen a spec. téren igazat adok a más eszköz -> más HTML-nek, de túlnyomó többségben a képelemek simán elhagyhatók.)
- A 24"-es monitort aki u.olyan közelről nézi, mint a 15"-est, annak baj van a látásával (vagy lesz, vagy a feje hibás). Nem a centikkel kell foglalkozni a monitorok esetében, hanem a pixelekkel. Ezért nem (sem) szabad pixelben betűméreteket megadni. (És ahol csak lehet: boxméretet sem.)

Eltértünk a tárgytól; nem először derül ki, hogy ezekről a dolgokról másképp gondolkodunk. De ezek inkább nézőpontbeli különbségek, ráadásul addig tart, míg a T. Megrendelő nem kér mást...
49

Koncepcionális különbség

Max Logan · 2012. Feb. 28. (K), 02.11
Én azt gondolom, hogy attól, hogy egy mobil képes WEB-es tartalmak megjelenítésére még közel sem ugyanazt akarom, mint amit desktopon.

Többek között erre értettem az előző kommentemben a specializálódást.

Egy iPhone-on, egy iPad-en és egy desktop böngészőben teljesen más élményt várok el. Egy mobilra nagyon nem kell pl. a csicsa, ott nagyjából az lenne a célravezető, ha nagyon minimál (ami Apple mértékkel már ugye egészen mást jelent) formában kapnám A tartalmat.

És innentől válik az egyébként is komplex WEB-es project egy nagyon komoly, összetett történetté. Én úgy látom, hogy ma Magyországon még igen kicsi az a réteg, aki fel tudja fogni ennek az egésznek a komplexitását és megérti, hogy miért is lenne jó, ha lenne teljesen más megjelenése mondjuk mobilon, iPad-en (tablet) és desktop-on a céges site-nak; nem beszélve a szolgáltatásokról.

Én úgy gondolom, hogy a webfejlesztés egyre inkább abba az irányba tolódik, vagy kellene, hogy tolódjon, hogy nem csak kérünk egy fejlesztést, meg időközönként utánkövetés van, meg újabb módosítások/fejlesztések, hanem lényegében az internet alapú megoldásai egy cégnek teljes mértékben outsource-olt megoldást jelentenek. Ekkor tud hosszú távon úgy működni az az online gépezet, ahogyan annak mindig is kellett volna működnie.

Csak ehhez kell(ene) egyfajta érettség a cégek részéről, mely jelen pillanatban nem nagyon van meg.

Itthon a vállalkozói szféra önmagában le van maradva, nem kicsit, nagyon, nemhogy IT és online vonalon...

Ezen persze lehet és kell is változtatni, de ehhoz első körben a szolgáltató cégeknek kell felmutatni egy igen korrekt szolgáltatási csomagot.
51

Szerintem ugyanazt

Pepita · 2012. Feb. 29. (Sze), 01.01
Szerintem ugyanazt mondod te is mint én, csak másképp. Árnyalatnyi a különbség, és inkább megfogalmazásban.

Nem u.azt akarod mobilon - design-ban - én sem, de "szövegben" közel ugyanazt.

Egy mobilra nagyon nem kell pl. a csicsa - pont ezt mondtam én is. De a "teljesen más megjelenés" <> "más tartalom".

A tartalom lényegi része viszont hasznos, ha u.az minden eszközön, u.is mi van, ha Júzer otthon a PC-n mutatja asszonynak, amit hazafele mobilon látott? Ciki, ha nagyon más van ott...
52

Re

Max Logan · 2012. Feb. 29. (Sze), 02.30
Az adathalmaz mindenhol ugyanaz, viszont az adatok elérésének hogyanja lehet jelentősen más. Egy mobil egészen más, mint egy desktop böngésző. Nem úgy akarom használni a mobilos változatot, mint a desktop változatot. Nem olyan navigációs megoldásokat akarok látni, stb, stb.

Röviden és tömören: ugyanazt az adathalmazt egy teljesen más felhasználói élménnyel akarnám elérni. Ez pedig jelentősen túlmutat azon, hogy design, vagy minimál megjelenítés. Itt tervezésbeli, működésbeli különbségekről beszélünk, melyek a platformok különbözőségéből fakadnak.

Egy telefont nem ott és nem úgy használunk, mint egy tablet-et és messzemenőkig nem úgy, mint egy asztali számítógépet...
50

Lendvai Norbert mindent

Hidvégi Gábor · 2012. Feb. 28. (K), 09.01
Lendvai Norbert mindent leírt, amit szerettem volna : )
nem először derül ki, hogy ezekről a dolgokról másképp gondolkodunk
Szerintem ezzel nincs gond, mert szerintem a vélemények ütköztetésétől mindannyian csiszolódunk.
41

Ha nem végzel kreatív munkát,

Hidvégi Gábor · 2012. Feb. 26. (V), 15.48
Ha nem végzel kreatív munkát, akkor sitebuild-re a PS Elements alkalmas, kipróbáltam.
35

Ezeket az érveket ugyanígy,

Hidvégi Gábor · 2012. Feb. 26. (V), 08.48
Ezeket az érveket ugyanígy, kulturáltan is leírhattad volna neki, mennyivel más lett volna a végeredmény.

mindenki abba akar beleugatni amit én csinálok
Ezt ne így fogd fel. Mindenki csak a véleményét mondja el, amire vagy figyelsz, vagy pedig ignorálod, a döntés mindig nálad van.

A cikkben olyan dolgokat szedtem össze, amikről úgy gondolom, hogy a munkádat nem nehezítik (ha beépül a napi gyakorlatba, akkor nem is lassítják), és nemcsak a sitebuilder, hanem te is rengeteget nyerhetsz vele, mert kezelhetőbbé, és később karbantarthatóbbá válnak a psd-id.

Tudom, hogy vannak ellentétek a sitebuild és a grafika között, épp ezért is igyekeztem a legtöbb helyen úgy fogalmazni, hogy "hasznos lehet" vagy "érdemes", tehát én csak ajánlok mindent, nem megmondok vagy kritizálok.