ugrás a tartalomhoz

Mitől jó egy weboldal terv?

tiku I tikaszvince · 2010. Szep. 1. (Sze), 10.34

Mostanában egyre gyakrabban fordul elő, hogy kiszervezzük egy-egy oldal megjelenésének tervezését. Ilyen formában jónéhány emberrel kapcsolatba kerültünk. A tőlük kapott tervek – bizonyára tapasztalatlanságukból kifolyólag – csak egy dologban egyeztek: rengeteg nyitott kérdést hagytak, aminek a terv átadása után hosszas kommunikáció, és egy csomó „erre nem is gondoltam”, „nem is tudom”, „erre kérek még 2 napot” tartalmú levél lett az eredménye.

Az alábbiakban szeretném összefoglalni, hogy melyek azok a gyakori hibák, amiket a kezdő designerek rendszeresen elkövetnek, mik azok a kérdések, amik nyitva maradnak. Majd próbálok összeállítani egy ellenőrző listát, ami segíthet a tervezőknek, hogy az átadandó tervük – legalábbis sitebuild oldalról – teljes legyen.

A hibák

A legrosszabb eset, amikor az átadott terv összesen egy blog kezdőlapot ábrázoló JPEG kép. Ebből nem derül ki, hogyan kell kinéznie egy egyedi tartalmat megjelenítő lapnak. Nem derül ki, hogyan jelennek meg a hozzászólások, a tartalomba ágyazott képek, a hozzászólás űrlap, a galéria. Ráadásul a JPEG-ről a tömörítés miatt képtelenség lelopni a pontos színeket. A használt egzotikus betűtípusokról már nem is beszélve.

A kezdő dizájnerek mindig beleesnek abba a hibába, hogy csak a saját képernyőjükre tervezik meg az oldalt. Ilyenkor mindig felmerül a kérdés, hogy mi a helyzet, ha kisebb a felbontás, vagy csak egyszerűen nem teljes méretű ablakot használ a látogató? Nem gondolják végig, hogy mi történjen a sarokba rendezett háttérképpel, ha átméretezik az ablakot. Hogyan nyúlik az oldal ha sokkal kevesebb vagy sokkal több tartalmat kell megjeleníteni?

Az oldal fej és láb része (header, footer) mindig látszanak (fixed)? Ha kevés a tartalom, a láb rész „felcsúszhat” a tartalom alá, vagy az oldal magassága legalább akkora legyen, mint az ablaké, ebből adódóan footer legalább az ablak alján jelenjen meg? Fix szélességű az oldal? Jobbra, balra vagy középre igazodjon?

Az előfeltételek

Amikor megbízunk egy designert, akkor át szoktuk adni az oldal specifikációját, de legalább egy projekt leírást. Ha designer vagy, nyugodtan kérj ilyet! Minél részletesebb a specifikáció, annál kevesebb lesz a félreértés.

A specifikációból mindig kiderül, hogy mik azok a funkciók, amiket az oldal majd megvalósít. Mik azok az elemek, amikkel számolnod kell a megjelenés kialakításakor. Ha valamit hiányolsz (pl. kereső blokk, RSS, Twitter, Facebook stb. ikonok), kérdezz rá, hogy direkt maradt-e ki. Van olyan ügyfél, aki kifejezetten nem akar ilyeneket látni az oldalán, de lehet, hogy csak megfeledkezett róla a specifikáció írója.

Ha hiányzik a mockup (drótváz), kérdezz rá, hogy készült-e ilyen, vagy szabad kezet kapsz-e az elrendezés kialakításakor. Ha kaptál, mindenképp kövesd. Ha szerinted nem jó a kapott váz, akkor szakmai érvekkel indokold meg miért nem követted, miért nem lehet azt megvalósítani.

A betűk

A választott betűcsalád - lehetőség szerint - legyen „websafe”. Ha @font-face segítségével húzunk be betűket, legyen tisztázott a betűcsaládok jogi helyzete. Mindegyik fonthoz határozz meg helyettesítő családot (pl. 'Palatino Linotype', 'Book Antiqua', Palatino, serif), lásd még Linux betűtípusok.

Amitől a terv közel teljes lesz

Egy jól kidolgozott terv legalább 3-4 PNG formátumú látványtervből és egy szöveges összefoglalóból áll. A szöveges dokumentumban szerepelnek a használt színek RGB kódjai, a betűcsaládok neve, továbbá a betűméreteket és minden harmadik féltől származó alkatóelem megnevezése, lehetőség szerint azok elérhetősége (ikon set, stock photo, font stb.).

Amikor látványterveket készítesz a következőket tarsd szem előtt:

  1. Tartalom oldalakat tervezel! A terven jelenjenek meg:
    • hivatkozások (a hover és aktív állapotról se felejtkezz el)
    • címek (h1-6)
    • listák, felsorolások (több szintű listák)
    • táblázatok
    • tartalomba ágyazott képek (képaláírással és/vagy anélkül)
    • ha blogról van szó, hozzászólások megjelenése (név, dátum, avatar, van-e szálkezelés)
    • címkefelhő
    • hiba- és értesítő-üzenetek (pl. „hozzászólásod rögzítése közben hiba történt”, „Beállítások frissültek”)
  2. Tervezd meg az űrlap elemeket:
    • input és textarea elem (mi történik, ha belekattintok?)
    • jelölő négyzet (checkbox) és radio lista mindkét állapota
    • select elem (legördített állapot is)
    • gombok (input, button)
    • űrlaphoz és az űrlapelemekhez tartozó hibaüzenetek
  3. Tervezd meg a főoldalt
  4. Tervezd meg tartalom listákat:
    • keresési eredményeket megjelenítő oldal
    • címke, szerző, dátum alapján leválogatott tartalmak listája
    • döntsd el, hogy a listában megjelenjenek a megosztó gombok?
    • ha a tartalom több lapra törik, milyen lapozó legyen, az hogy jelenjen meg
  5. Tervezd meg a galériát:
    • az album listát
    • egy album hogyan jelenjen meg
    • határozd meg a megjelenítendő képek méreteit (bélyegképek, nagy képek stb.) ügyelve a méretarányok megtartására
 
1

jQuery themeroller

tiku I tikaszvince · 2010. Aug. 14. (Szo), 14.30
Ha a specifikációból kiderül, hogy az oldal használni fogja a jQuery UI-t akkor érdemes lehet a jQuery ThemeRoller-rel is eljátszadozni
23

igen, én szoktam

Crystal · 2010. Szep. 5. (V), 12.49
én minidg kérek jQuery UI témát a designertől, ha a projekt elején tudjuk hogy szükség lesz rá
2

par aprosag pluszban: -

ksgy · 2010. Szep. 1. (Sze), 11.58
par aprosag pluszban:

- pixelpontos igazitasok (shape-ek es szoveg eseten is)
- kovetkezetes meret hasznalat: pl gombok lehetoleg ne legyen egyik oldalon 150px masik oldalon 140px szeles - ha ezt mas nem indkolja
- ha olyan a design, ahol van pl lenyilo menu, az animalva legyen-e, vagy siman csak egyszeruen megjelenik
- ajax-os tartalom eseten "loading" allapotok


ps: jo a cikk, egy "vegre!" erzes fogott el, mikor olvastam :)
3

meg eleve ne 53, meg 151

Tyrael · 2010. Szep. 1. (Sze), 12.43
meg eleve ne 53, meg 151 pixeles elemekbol alljon a design...

amugy tenyleg hianypotlo cikk, lehetne folytatni, illetve megelozni: hogyan specifikaljunk egy project tervet, hogyan keszitsunk egy egy projecttervet, stb.

Tyrael
10

Igen, ez jó lenne! Hogy miket

Balázs András · 2010. Szep. 2. (Cs), 00.49
Igen, ez jó lenne! Hogy miket kell a megrendelőnek leírni, hogy a programozó dolgozni tudjon belőle és a végén a megrendelő se csalódjon, hogy nem azt kapja amit szeretett volna, noha a program teljesíti a specifikációban leírtakat!
4

css framework

duplabe · 2010. Szep. 1. (Sze), 13.16
elore le kell(ene) azt is tisztazni, hogy a sitebuilder hasznal-e valami css frameworkot. igy elkerulheto lenne, hogy az oldal mondjuk a css framework szerint 950 px szeles, a designer meg szul egy 987 px szeles tervet... eleve, igy meg lehet adni, hogy milyen meretekkel lehet gondolkozni az oldal elemeinek tervezesekor.
5

css framework

Poetro · 2010. Szep. 1. (Sze), 13.47
Erőteljesen nem használnék olyan keretrendszert, ami fixen megköti, milyen széles legyen az oldal. Pillanatnyilag nem is tudok ilyenről. Szerintem mindnek van generáló szkriptje, amiben be tudod állítani a szélességet, az oszlopok számát, a hézagokat stb. Amiben nem, az véleményem szerint eleve kuka.
6

grid

zila · 2010. Szep. 1. (Sze), 15.11
A design kezdete előtt tisztázni kell, hogy lesz-e valamilyen grid vagy sem. Ha igen, akkor a designt a használt gridre kell elkészíteni és sokkal egyszerűbb picit faragni a design-on, hogy 873 pixel helyet legyen 870 vagy éppen 875 pixel mint nem pontosan gridre készült terv alapján a sitebuild fázisban módosítani (mert akkor jönnek a designerek, "jogosan", hogy dehát ott 2 pixellel arrébb került az oldalsáv!)
8

en blueprintet hasznalok, ott

duplabe · 2010. Szep. 1. (Sze), 17.34
en blueprintet hasznalok, ott fix a szelesseg
9

blueprint

Poetro · 2010. Szep. 1. (Sze), 17.58
Én dolgoztam blueprint-tel és van online tool is, valamint Ruby kód is amivel le lehet generálni a CSS-t.
15

ezeket meg nem is lattam.

duplabe · 2010. Szep. 2. (Cs), 08.48
ezeket meg nem is lattam. koszi :)
7

Kezdő dizájnerek

yaanno · 2010. Szep. 1. (Sze), 17.33
Az "A kezdő dizájnerek" kifejezéssel kezdődő mondatod érvényes a dizájnerek többségére, azokra is, akik sok-sok éve foglalkoznak grafikus dizájjnal, esetleg interakcióval és egyebekkel is vegyesen. Ez nem szégyen, tanulható. A front end fejlesztő dolgozzon együtt és kommunikáljon a dizájnerrel és a projekt többi tagjával. A specifikáció ezt nem oldja meg.
13

a kommunikáció elmaradhatatlan

tiku I tikaszvince · 2010. Szep. 2. (Cs), 07.12
Nyilvánvaló, hogy nincs az a specifikáció, terv, produktum ami nem hagy nyitott kérdéseket. Az írás azon pár bekezdésében csak arra szerettem volna rámutatni, hogy mik azok a kérdések, amiket - nekem mint a terv kivitelezőjének - még az első kódsor megírása előtt fel kell tennem, mert egy statikus képről nem derül ki. Pl. egy rögzített fejléccel rendelkező layout kialakításakor más HTML szerkezet a praktikus mint egy rögzített szélességű, középre rendezetthez.

A specifikációnak nem az a dolga, hogy megkösse a grafikus kezét, hanem hogy legyen egy egyértelmű feladat leírás, hogy mik azok az "alkatrészek", amiket szeretnék látni a terven.

Az indok egyébként, amiért megszületett ez az írás, éppen az, hogy - szerintem - ezekre a kérdésekre a grafikusnak kellene gondolnia. Ezek olyan kérdések, amiket nem nekem kell eldöntenem a kivitelezés során. Az hogy a gyakorlott grafikusok sem gondolnak ilyenekre, elszomorító...
11

nagyon jól

nevemrock · 2010. Szep. 2. (Cs), 05.53
Nagyon jól összefoglaltad a dolgokat, köszi érte!

Most éppen egy olyan grafikán dolgozok, amit az ügyfél készítette és ragaszkodik hozzá. Mondanom sem kell mennyire gáz, de hajthatatlan. Készült neki egy felhasználóbarát, használható grafika, de az nem felelt meg :)..

jQueryUI olyan szinten át kellet alakítani (sokkal csúnyább lett, gagyi működéssel), még szerencse, hogy volt rá lehetőség.. Egyedi checkboxok, radió elemek, (optgroup..)select elemek.. kész!

Ezekkel az esetekkel mit kezdetsz?
12

ügyfél

tiku I tikaszvince · 2010. Szep. 2. (Cs), 06.47
igazság szerint ezt ügyfele válogatja. Az, hogy hogyan próbáljuk meg az ügyfelet eltávolítani a rossz ötletektől, nagyban függ az ügyfél hozzáállásától.

Ilyen kényes esetben szerintem célravezető lehet, ha még a munka megkezdése előtt határozott kritikát fogalmazol meg a szerinted kényes pontokkal szemben. Fontos, hogy mindent kritikát meg kell indokolni. Hozni kell néhány példát, ahol hangsúlyozni lehet, hogy miért nem a legjobb az a megvalósítás. Ugyanakkor egyből kell alternatívát is mutatni, ha lehet ne csak egyet.

Ha ez nem lenne elég meggyőző, akkor be lehet vonni a technikai érveket. Pl. egy ilyen mértékű input átalakítás csak JS-el valósítható meg. Ahol nincs JS, vagy ki van kapcsolva, ott nem így fog megjelenni, erőforrás igényes, stb.

mondjuk végső esetben még mindig lehet nemet mondani egy ilyen megbízásra
14

Szerintem mindig az ügyfél

virág · 2010. Szep. 2. (Cs), 07.42
Szerintem mindig az ügyfél makacssága és esetenként bizony-bizony butasága szokott a legnagyobb kerékkötő lenni ebben a témakörben, de ezt még lehet fokozni, mert az a legrosszabb, ha az ügyfél rossz és hozzá nem értő, de magukat szakemberként aposztrofáló tanácsadókkal rendelkezik :) Ha ez a negatív együttálás nincs, akkor szerintem minden megoldható és minden felesleges kör elkerülhető, vagy legalábbis minimalizálható, de amúgy...

Köszi, hasznos kis bejegyzés, jó kommentek is születtek :) körbe is küldtem a linket, hátha még megosztják mások is a tapasztalataikat.
16

Wireframe, mockup

Wabbitseason · 2010. Szep. 2. (Cs), 10.18
Príma cikk!

Annyit tennék hozzá, hogy felénk a drótváz, a tartalom elrendezése "wireframe" néven fut, míg "mockup" alatt már komplett látványtervet értünk, tehát mintha screenshot készült volna a már véglegesített oldalról.
17

a drotvaz a wireframe szo

Tyrael · 2010. Szep. 2. (Cs), 14.04
a drotvaz a wireframe szo szerinti forditasa.
http://en.wikipedia.org/wiki/File:Sphere-wireframe.png

mockup/prototipus eleg sok mindent jelenthet.
hallottam mar abban az ertelmeben a mockupot, amit te is mondtal, hogy egy "fake" kepernyoterv volt a mockup, de szoktak a prototipusnak abban az ertelmeben is hasznalni a mockupot, hogy nyomkodhato az oldal, tenyleges munka meg nem vegezheto vele, csak bemutatja a szoftver tervezett mukodeset (es/vagy esetleg a kepernyoelemek elrendezeset is, de itt meg nem szokott komolyabb design lenni).

Tyrael
18

wireframe

Wishmylove · 2010. Szep. 2. (Cs), 20.23
Egy nagy probléma van. Itthon az ügyfelek 90% nem tudja mi az a wireframe. Sőt, megfizetni sem akar ilyet miután megtudta. A Magyar webdesign kultúra, szinvonal a béka feneke alatt van, tehetségtelen emberek gyártanak szemetet olcsón.
19

nincs igazad

TIV · 2010. Szep. 2. (Cs), 20.40
nem feltétlen olcsón! a project terv/specifikációról egy hasonló írás szerintem is hiánypótló lenne! köszönjük, ez is remek volt!
20

cash

Wishmylove · 2010. Szep. 2. (Cs), 21.26
Magyarországon az ár dönt szinte mindig a web projektekben.
21

Igazából nem tudom kik

sajt · 2010. Szep. 3. (P), 00.35
Igazából nem tudom kik csinálják mostanában a weblabort (talán csak Török Gábort kivéve), de igen színvonalasak a cikkek. Volt itt egy cikk, arról, hogy felejtsük el a photoshop-ot, tervezzünk dizájnt CSS-ben + HTML-ben. Én ennek vagyok a híve.

Azonban leginkább a folyamatos eggyüttdolgozás híve vagyok. Az, hogy a dizájner odarak egy jpg-t, vagy ne adj isten, egy psd-t, és ezzel letudta a munkáját, az nem megoldás. Senki sem olyan vérprofi, hogy előre tudja pontosan, hogy milyen lesz a weboldal, ráadásul, ha egyszer elkészül, akkor se lesz kész, maximum éppen fizet a megrendelő.

Ez egy kicsit bővebb téma, majd egyszer írok róla, már régóta tervezem.
22

Re: kik csinálják

Török Gábor · 2010. Szep. 3. (P), 07.31
A Weblabort ti csináljátok, mi csak támogatunk ebben benneteket az eszközeinkkel.
24

Ó, áldott specifikáció!

sosana · 2010. Szep. 14. (K), 08.30
Kaptam már megrendelőtől papírra, találomra rajzolt drótvázat, Word-ben, Excel-ben készült grafikákat (jpg-vel már elkényeztetnek), kaptam már céges mappát, névjegykártyát, hogy arról szedjem le a logót és a színeket, stb. :) De itt legalább van valami amihez lehet igazodni. Az a legrosszabb, amikor nincs semmi, nincs elképzelés, de csináljam meg a látványtervet, ha lehet 6 változatban, hogy legyen miből választani. Bizakodó vagyok, hátha eljutunk egyszer a pontos specifikációhoz!
(A legviccesebb grafikai feladatomat ma is őrzöm: faxon érkezett egy kézzel firkált vázlat, rajta egy mackósajt forma, amihez a megjegyzés a következő: ez itt egy napkollektor, de mivel a nézeti rajz nem helyes, a grafikus javítsa! )
25

Ha már grid

Cooty13 · 2010. Szep. 14. (K), 10.20
Én a 960 Grid Systemet ajánlom figyelmébe mind a dizájnereknek mind a sitebuildereknek. Nagyon felxibilis, van hozzá WYSIWYG CSS/HTML generáló.
Egyébként itt is fix az oldal szélessége (960px), de szerintem ez egyáltalán nem baj.

Mellesleg azzal, mondjuk vitatkoznék, hogy a select és a checkbox legördülő/bejelölt állapotát külön meg kéne tervezni, mert ezek általában az oprendszer/böngésző stílusát követik és CSS-el csak nagyon minimálisan lehet őket testre szabni.

Lehet persze egyedi select-et és checkbox-ot gyártani HTML/CSS-el, de azért ez nem olyan életfontosságú kérdés, szerintem. - Az mondjuk igaz, hogy sok dizájner a formokat elhanyagolja, pedig fontos, hogy jól nézzek ki.
26

form formázás

tiku I tikaszvince · 2010. Szep. 14. (K), 11.07
az is lehet egy tervezői választás, hogy ne nyúljunk egyáltalán az űrlap elemekhez, hagyjuk, hogy a böngésző az alapértelmezett formában jelenítse meg. Személy szerint én ezt az irányt támogatom, mert cross-browser módon form elemeket formázni egy rémálom tud lenni.

De ha már egy terven formázottak az inputok és a submit gombok, akkor nem biztos, hogy az alapértelmezett select illik a legjobban a sorhoz. De az űrlap megtervezéséhez tartozik, hogy mi az alapértelmezett elrendezés, a beviteli mező és a címkéje hogy jelenik meg, egymás alatt, egymás mellett? ha egymás mellett, a címke jobbra vagy balra zár? a radio/checkbox címkéje a mező előtt vagy mögött jelenjen meg?
28

űrlap elrendezés

Török Gábor · 2010. Szep. 14. (K), 11.32
az űrlap megtervezéséhez tartozik, hogy mi az alapértelmezett elrendezés

Éppen akartam írni. Az űrlap kontrollok megjelenésénél sokkal fontosabb az űrlap elrendezésének meghatározása. Ez pedig talán nem is kéne, hogy a weboldal terv része legyen (kivéve, ha már a tervezési fázisban rögzítettek az űrlapok specifikációi és feladatai), ugyanis minden űrlap a funkciója szerint teljesen eltérő felépítésű lehet és kell is legyen. Erről a témáról nagyon sok tanulmány olvasható a neten, és nagyban meghatározza, hogy az űrlap eléri-e a célját: kitöltik-e.
27

Nem fix

Poetro · 2010. Szep. 14. (K), 11.08
Az oldal szélessége ebben a keretrendszerben sem fix, lehet más szélességű, oszlopszámú, térközű CSS-t is generálni, nem kell ragaszkodni a 960px-hez.

Mellesleg azzal, mondjuk vitatkoznék, hogy a select és a checkbox legördülő/bejelölt állapotát külön meg kéne tervezni, mert ezek általában az oprendszer/böngésző stílusát követik és CSS-el csak nagyon minimálisan lehet őket testre szabni.

Amennyiben nem a böngésző beépített elemét használjuk, hanem JavaScript-tel lecseréljük egy saját implementációra, akkor igenis fontos lehet megtervezni. Az egyik legismertebb talán ezek közül a Gmail fejlécében levő Továbbítás és társai legördülők.

Ha a webalkalmazásunk sok formot tartalmaz (ez szinte mindegyikre igaz) akkor gyakran fontos ezek a környezetbe történő legjobb integrálása.
29

Hmmm.

deidre · 2011. Aug. 30. (K), 20.22
Hát én nem vagyok ettől a cikktől annyira elájulva, sőt. A kedvencemet látom belőle visszaköszönni, azaz; "miért a designer a hibás, aki nem tervezte meg rendesen, és miért nem én, aki összerakom. Meg azért is ő a hibás, mert én nem tudom hogy a lekerekített doboz a 179. oldalon is lekerekített doboz, és a 10 px köz az mindig annyi."

De menjünk sorban.

A hibák.

A legelső és legfontosabb hiba az szokott lenni, hogy kapsz egy cégnevet, meg annyit, hogy "valamit dobj már össze ebből holnaputánra, hasonlítson egy portálra, meg jól nézzen ki, és legyen valami logó".
Ennyi. Sem a cégről/cég tevékenységéről, sem a meglevő arculatáról, sem a tartalmi blokkokról, sem a menükről ("hát lesz vagy 5-6, de csináld úgy, hogy 9 is kiférjen"), sem semmiről.
Aztán ebből tervezz csodálatosat. Mit is mondok, tervezz? Találgass, aztán amikor készen vagy, akkor jön a "nem erre gondoltunk, legyen teljesen más. Igen, persze, tudjuk mi is hogy ezt mondtuk, de akkor még nem így gondoltuk. Nem, felárat nem fizetünk, hogy képzeled? így is milyen drága."

Az ablakátmérezetésre tervezést nem tudom hogy képzeled, azt is a designer találja ki, hogy hogy nézzen ki akkor? Ő honnan tudja, te milyen technológiával fogod összerakni?
Vagy azt is ő határozza meg? Minek? úgyis a legolcsóbb külsőssel csináltatjátok meg, aki a lehető legegyszerűbb megoldásokat fogja használni. A legtöbb sitebuilder tapasztalataim szerint úgyis grafikus akar lenni (csak nem tud), és pénzkidobásnak érzi a grafikust. Tessék, itt a lehetőség, hogy kiéljétek magatokat. Ha nincs rá lehetőség, úgyis csináltok magatoknak, legfeljebb a végeredmény köszönőviszonyban sem lesz a tervekkel.

Az előfeltételek

"Ha valamit hiányolsz (pl. kereső blokk, RSS, Twitter, Facebook stb. ikonok), kérdezz rá, hogy direkt maradt-e ki. Van olyan ügyfél, aki kifejezetten nem akar ilyeneket látni az oldalán, de lehet, hogy csak megfeledkezett róla a specifikáció írója."

Nem baj, majd a módosításoknál észreveszi, és kifizeti, mint módosítást. Ne a designer végezze már el a teljes cég munkáját. Főleg, ha külsős, aki ugye feladatbonyolultság alapján van fizetve, és a specifikáció alapján adja az árajánlatot. Tessék szépen odafigyelni, nektek is. A másik sem szeret feleslegesen dolgozni.

Drótváz többnyire nincs. :)
És ha van, akkor sincs hozzá tartalom.
Minden típusú, random mennyiségű tartalomhoz nem lehet tervezni úgy, hogy tökéletesen nézzen ki.


A betűk

Mindegyik fonthoz határozz meg helyettesítő családot (pl. 'Palatino Linotype', 'Book Antiqua', Palatino, serif), lásd még Linux betűtípusok.

Minek? Most megjelenést tervezünk, ahol a felhasználói élmény segítése a cél, vagy odacsapdosunk valami mindegymilyen izét? Meg egyáltalán, tényleg minek? Verdana, arial, tahoma, georgia van mindenütt, a többit meg úgyis hazárdjáték használni.

És ha én megveszem a jogtiszta fontcsaládot és beletervezem, adjam el neked mert kifizeted? Vagy megveszed magadnak? Vagy hogy gondoltad a jogi helyzet tisztázását?


Amitől a terv közel teljes lesz

Egy jól kidolgozott terv legalább 3-4 PNG formátumú látványtervből és egy szöveges összefoglalóból áll. A szöveges dokumentumban szerepelnek a használt színek RGB kódjai, a betűcsaládok neve, továbbá a betűméreteket és minden harmadik féltől származó alkatóelem megnevezése lehetőség szerint azok elérhetősége (ikon set, stock photo, font stb.).

Akkor mi a fenének kéred el a psd-t? :) Abban ugyanis minden benne van. Jah hogy nehogy unatkozzak azért a tengersok pénzért, amit kifizettek?
Tanuld meg használni a ps-t, és nem lesz ilyen gondod, ráböksz, aztán ott van. Hidd el, egyszerűbb lesz mint egy 4 oldalas pdf-ből kiásni.

Hogyne, pusziért osztogatni fogom a méregdrága, és/vagy verejtékes munkával összeszedett/elkészített cuccaimat. (Bár néha önszántamból megteszem, de ezek speciális esetek).

A design ára a látványterv elkészítésének az ára, az a folyamat, amikor a semmiből létrehozol valamit, és azt az ügyfél és a kollégák minden hülyesége ellenére megtartod nézhető keretek között. És nem kapod meg hozzá grátisz a fél internetet. Különösen nem úgy, hogy ezt evidenciának veszed. Mert ne legyél pofátlan, azért.


Tartalom oldalakat tervezel!

Nem, nem tartalom oldalakat tervezek. Látványtervet. A tartalom oldalakat az ügyfél tervezi meg, aki tudja mihez akar weboldalt, tudja magáról hogy mit csinál, hogyan, és ebből mennyit akar megmutatni a külvilágnak. És ezt a rendelkezésemre bocsátja, előre. Amennyiben ezt nem teszi meg, jó eséllyel sok pénzt fog kifizetni, teljesen feleslegesen. Az én dolgom NEM a tartalom, hanem a tartalom tálalása.


Tervezd meg az űrlap elemeket:

Mi az öreg isten lópikulájának, ha egyszer nincs űrlap? Vagy hogy egyszer majd hátha lesz? Majd szólsz akkor, és megcsinálom. Igen, persze hogy pénzért.
Ha meg van, minek leírni külön?
Űrlap elemek különben is az a kategória, amivel a többség nem fárasztja magát, úgyis ahány böngésző, annyi féle képpen néz ki, berakja az alapértelmezettet, oszt csókolom.


Tervezd meg tartalom listákat:

Megint keverjük a sezlonyt a lóherével. Ha nincs keresési opció, minek a keresési lista?
Kért rá az ügyfél megosztási lehetőséget? Nem? Akkor nem jelenik meg a megosztó gomb, amúgy meg igen. Meg ne etessem őt is, meg téged is?


Tervezd meg a galériát:

Megint honnan veszed, hogy minden lapon lesz galéria?...


Összefoglalás

Szerintem te ezt belső körlevélnek szántad, egy adott, és az általatok használt keretrendszerbe, továbbá egy zárt céges környezetbe, ahol megvan hogy gyerekek, ezeket vettük meg, ebből tudtok gazdálkodni. Ott tényleg nem probléma az ajándékcsomagok osztogatása, de egy külsőstől ezt ne várd el, vagy szorozd fel néggyel a munkadíját.

Viszont etalonként lefektetni... hát irgumburgum.

Ha designt rendelsz, többnyire azért teszed, mert valami egyedit szeretnél, ami az adott lap lehetőségeihez és céljaihoz van optimalizálva, nem egy sablonkaptafára készült, tizenkettőegytucat izét.

Ahhoz viszont ez a leírás már necces.
30

Re: Hmmm.

tiku I tikaszvince · 2011. Aug. 31. (Sze), 08.13
A legelső és legfontosabb hiba az szokott lenni, hogy kapsz egy cégnevet, […] Ennyi. Sem a cégről/cég tevékenységéről, sem a meglevő arculatáról, sem a tartalmi blokkokról…

Úgy tűnik átsiklottál az "Előfeltételek" részen. Ott épp azt írtam le, hogy senki nem érdemli meg, hogy tisztességes dokumentáció nélkül kelljen dolgoznia. A dizájnernek számára a specifikáció azt mondja meg, hogy mik azok a funkciók, amiket a weblap majd meg fog valósítani. Ezek azok a pontok, amiket meg kell terveznie ahhoz, hogy a végeredmény egy számára, számodra is vállalható produktum legyen.

Az ablakátmérezetésre tervezést nem tudom hogy képzeled, azt is a designer találja ki, hogy hogy nézzen ki akkor? Ő honnan tudja, te milyen technológiával fogod összerakni?

Rengetegszer találkoztam azzal a problémával, hogy kitaláltam a dizájner helyett valamit. Aztán szólt, hogy annak máshogy kell működnie vagy kinéznie, és eshettem neki mégegyszer annak, ami csak egy ember számára volt egyértelmű. Sarkítva: ezeket a dizájnernek kitalálni plusz fél óra, de a sitebuild folyamatát akár napokkal is lerövidítheti.

Ha nincs rá lehetőség, úgyis csináltok magatoknak, legfeljebb a végeredmény köszönőviszonyban sem lesz a tervekkel.

Szerintem, ha egy projektben már fut dizájnerre, akkor az a dizájner igenis követelje meg, hogy a megvalósítás során a kivitelező tartsa magát a tervekhez.

Az előfeltételek rész arról szól, hogy mik azok a dolgok, amiket dizájnerként jogosan kérhetsz a megbízódtól, még azelőtt, hogy akár a gépet bekapcsolnád. Feltételezem, hogy szeretnél minőséget kiadni a kezed közül. Ismerem azt a szenvedést, amikor utólag, hatalmas homlokcsapkodások közepette kell utólag begyógyítani egy tervbe pl néhény social funkciót (FB like, twitter share). Ennek általában az a kimenete, hogy valahogy oda tesszük a dizájner nélkül, de végeredmény ocsmány. A végén minden résztvevő letagadja, hogy bármi köze lenne a projekthez. Nem tetszik az ügyfélnek, mert az oldal csak egy összecsapott vacak. Rossz a fejlesztőnek, mert látja hogy nem jó. Rossz a dizájnernek, mert a tervének ilyetén megerőszakolása már régen nem az a minőség, amit vállalni lehetne.

Nem értem, milyen tartalmat vársz a drótvázhoz. A wireframe azt mondja meg, kb milyen szerkezetűnek szeretnénk látni az oldalt. A változó tartalom hosszra, pedig szerintem jó ha felkészül a dizájner. Nem kell, tökéletesen kinéznie minden szöveg mennyiséggel. De jó, ha látom, hogyan képzeled el pl a footer elhelyezkedését, ha csak egy sornyi a tartalom, vagy ha egy kisebb regény van egy oldalon.

A betűkkel kapcsolatban, sokszor hallom azt dizájnerektől grafikusoktól, hogy már hányingerük van, ha meglátják az általad is említett "elcsépelt" betűvel operáló oldalakat. Ha te csak ezekkel dolgozol, akkor is az Arial mögé fogom írni hogy sans-serif, mert semmi nem garantálja, hogy tényleg van mindenütt Arial.

És ha én megveszem a jogtiszta fontcsaládot és beletervezem, adjam el neked mert kifizeted? Vagy megveszed magadnak? Vagy hogy gondoltad a jogi helyzet tisztázását?

Pontosan így. Tedd fel a kérdést a megbízónak, hogy hajlandó-e fontokra pénzt áldozni. Ha hajlandó, akkor nyugodtan tervezd bele. Csak ne felejtsd el megírni a terv mellé, hogy pontosan mi az a betűtípus.

Akkor mi a fenének kéred el a psd-t?

Én nem kérem el a PSD-t, mert nem tudok vele mit kezdeni. Nálam nincs PS telepítve. Miért fizessek egy valag pénzt egy programért, amit gyakorlatilag csak képnézegetésre használok (meg rakjak alá hardvert is, hogy mellette még dolgozni is tudjak). Arról nem beszélve, hogy én pl linux desktopot használok, amin PS meg sem mozdul. Épp azért szoktam PNG-ket és szöveges dokumentumot (nekem tökéletes a TXT-is nincs szükségem PDF-re) kérni, mert a PSD-ben olyan dolgok is lehetnek, amiket a dizájner nem szívesen ad ki. Ha elolvasod még egyszer azt a mondatot, akkor fel fog tűnni, hogy nem a fizetős alkatrészeket, hanem azok elérhetőségét kérem.

Úgy olvasom ki a soraid közül, hogy neked még nem volt szerencséd olyan projekten dolgozni, ahol minden résztvevőnek az lett volna a célja, hogy a készített oldal a lehető legjobb minőségű legyen, és nem az, hogy "adjuk át, oszt az ügyfél meg fizessen". Nyílván a galériát csak akkor kell megtervezned, hogyha a specifikáció megemlíti. Űrlap elemeket pedig már szinte minden oldal használ, elég csak ha a következőkre gondolsz: bejelentkezés, keresés, hozzászólás.

Szerk:
A többiek hozzászólásaiból is kiderül, hogy a lényeg az, hogy az ügyfél, a projekt gazda, a fejlesztő, a dizájner, a sitebuilder, magyarul mindenki, aki részt vesz a projektben, segítse egymást, dolgozzon egymás keze alá. Ennek az egyetlen hathatós módja a bizalom, és a folyamatos kommunikáció. Ha ezek közül bárki is beáll a megnemértett művész pozíciójába, és azt várja, hogy majd a többi látatlanul megérti a gondolatait, akkor annak a munkának nem lesz jó vége.
31

Uh. Egyszer dolgoztam én egy

deejayy · 2011. Aug. 31. (Sze), 09.49
Uh. Egyszer dolgoztam én egy meg nem értett művésszel, és amikor megemlítettem (több tíz dolog között), hogy nem biztos, hogy szerencsés, ha ugyanaz a gomb minden oldalon más stílusban jelenik meg (pl. egyiken kerek, egyiken fényes, egyiken fekete betű, másikon fehér, etc), akkor meg én volt a bunkó, hogy ne szóljak bele, "minden úgy jó, ahogy van".

Ezzel el volt intézve. Meg persze több munka sem volt vele.

Mondjuk lehet, hogy a tizedik pont felsorolása után már elvesztettem én is a türelmem, de akkor is: nem egymásért dolgozunk, hanem az ügyfélért.
34

Off: javaslat

Max Logan · 2011. Aug. 31. (Sze), 10.51
Azt gondolom, hogy érdemes lenne létrehozni egy olyan irányadó fogalomdefiníciót, hogy mégis mi alatt mit értünk ma a magyar webfejlesztő szakmában.

Mert ahogyan a meg nem értett művész kifejezés, valamint a DTP világból a WEB felé orientálódó grafikusok példája mutatja, sokan nincsenek tisztában a "játékszabályokkal".

Definiálni kellene, hogy ma itthon a web-es fejlesztések kapcsán mit értünk webdesigner alatt (nem egyértelmű pl. hogy ő grafikus, vagy egy egyszemélyes mindenes fejlesztő), ő milyen képességekkel kell, hogy rendelkezzen, ha még nem az, de elég jó grafikus és érdeklik a WEB-es világbeli munkák, akkor hogyan képezze át magát stb. Ugyanaz minden területen, backend, frontend fejlesztő (és akkor itt jó lenne végre kiűzni a sitebuilder kifejezést a köznyelvből), stb.

Ezt közösségi munka révén olyan szintre fel lehetne fejleszteni, hogy itt a Weblaboron elérhető legyen és mint hivatkozási alap szolgálhasson különböző élethelyzetekben (mint pl. amikor valaki álláshirdetést ad fel és hivatkozhat erre a doksira).

Ötlet, vélemény?
32

off: ha muszáj, a .psd-k egy

H.Z. v2 · 2011. Aug. 31. (Sze), 10.31
off: ha muszáj, a .psd-k egy részét gimp-ből is meg lehet nézni.
33

Megnézni

Poetro · 2011. Aug. 31. (Sze), 10.50
Megnézni meg lehet, csak nem fog úgy kinézni mint PS-ben. Ami nekem bejött, mivel magam se használok PS-t, hogy IrfanView-ban mentek belőle egy PNG-t, és azzal dolgozok. Ami meg átlátszóan kell, azt pedig elkérem a dizájnertől PNG-ben.
35

Azért írtam, hogy "egy

H.Z. v2 · 2011. Aug. 31. (Sze), 10.58
Azért írtam, hogy "egy részét" :-)
Van ami ugyanúgy néz ki (tény: 4-5 éves, ráadásul fotós tapasztalat)
36

személyes tapasztalat

tiku I tikaszvince · 2011. Aug. 31. (Sze), 12.02
Személyes tapasztalatom szerint, ha a dizájner n számú effektet (ahol n > 0) használt akár egy rétegen is, akkor már GIMP nem tudja megjeleníteni a PSD-t. És akkor még nem is említettük a könyvtárba szervezett rétegeket.

A tapasztalatom egyébként azt mutatja, hogy a fentebb is említett 3-5 PNG formátumú látványtervből, ha kell, GIMP segítségével, szinte bárki ki tudja vágni a szükséges részeket. Ha meg nem boldogul, akkor még mindig meg lehet kérni a dizájnert, hogy pl. azt a színátmenetes részt, szöveg nélkül vágja ki és küldje el.
37

off: erre is ki lehetne térni

Max Logan · 2011. Aug. 31. (Sze), 14.56
Én pl. erre is kitérnék a korábban tett javaslatom alapján elkészülő műben, hogy kinek a feladata a slice-olás. Én pl. úgy gondolom, hogy ez a frontend fejlesztő feladata, aki a HTML, CSS kódot előállítja, mert ő ismeri a lehetőségeket és tudja, hogy mit akar csinálni. És itt jön az, hogy a grafikus is legyen része az aktív munkának, akinek meg nem árt némi UX designeri ismeret, stb.

És végül ott tartunk, hogy érdemes definiálni, hogy mégis mi a fent csinálunk. Én azt látom, hogy egy kisebb vagy közepes honlap igazán korrekt kivitelezése is csapatmunkát kíván meg. Persze lehet ezt egyedül, max. pár emberes honlapkészítő csapatként csináni, de ez a tevékenység semmivel sem kisebb munka -- ha éppen nem nagyobb --, mint a hagyományos értelemben vett szoftverfejlesztés.

Így pedig jó lenne deklarálni, hogy ki mit ért honlapkészítés alatt, mert én most már 5-6 évnyi aktív ismeretgyűjtés után azt modnom, hogy komoly szoftverfejlesztési munka (melynek igen komolyan a részét képezi a tervezés) és ezen túlmenően csapatmunka.

Az, hogy ez nem így él a hétköznapi emberek fejében sajnálatos, de jó lenne, ha ezen végre változtatának a szakmabeliek és elmagyaráznák az embereknek, hogy mi a valós helyzet. Meg tud tanulni egy 5 éves gyerek is úszni, de hogy belőle világbajnok úszó legyen az igen komoly (csapat)munka eredménye.
38

Kiváló - megrendelőként

Dietrich · 2015. Május. 18. (H), 06.25
Így négy év távlatából is kiváló cikk, jó hozzászólások!

De mivel sokan ekézitek a megrendelőket, meg hiányoljátok a WEB-es kultúráját, csak a gyorsan-olcsón szemléletet látjátok benne, hadd írjak erre valamit:

Kizárólak ti (fejlesztők, designerek, stb) vagytok a felelősek ezért!

Ki mondja meg a megrendelőnek, aki nem szakember, hogy minek mi a menete, mi kell hozzá, mi az ára? Miért háborodtok fel azon, hogy ezt mi nem tudjuk?

Tessék elmondani neki, tessék minden fronton hirdetni, hogy a weblapok kialakításához ez-meg-ez kell!

Csináljatok oktatási anyagot, oktassátok mindenhol ingyen!

Legyen szoftver, ami ingyen oktatja a tudnivalókat a megrendelésekhez!

Jaaaaaa.....de ilyet ki csináljon ingyen? Na igen...

Akkor viszont csitu! F@szok vagyunk, mert nem tudjuk megrendelőként, hogy pixel, meg, dot, meg javascript, meg PS...te ti is azok vagytok, mert nem mondjátok el nekünk, hogy ezt-meg-ezt kellene tudnunk! És akkor ennyit a "kultúráról" mindkét oldalon.

Na üdv!