witola.com

Att gå över min morgon blogg rullar jag kom över denna utmärkta artikel skriven i Webdesigner Depot med Jason Cranford Teague .

Jag har under längst tid haft designa för webben, men fram till för två år sedan faktiskt gjorde hoppa in i kodning och front-end utveckling. Det intressanta är att jag har funnit det vara lite av en kamp i att som designer jag använder ena sidan av hjärnan och som utvecklare använder jag den andra.

Mentalt är detta beskatta, som designer jag vill att det ska se rätt och som utvecklare Jag vill att hemsidan ska fungera rätt. Överbrygga denna klyfta och kommer till en gyllene medelväg är jobbigt, men jag tycker mig vara en bättre råvara att resa för sysselsättningen. I de flesta fall människor är antingen det ena eller det andra. Den ena är design samt roliga och balans, där den andra är logiskt, teknisk och ibland frustrerande. Hoppas du njuter av artikeln, det gjorde jag.

Favorithatobjekt # 1: "Varför kan inte utvecklaren bara att det ser ut kompet?"

Du skapar en snygg design och handen från Comp till utvecklare, men när du får plats tillbaka, ser det ut som ett lapptäcke av vad du utformade.

Utgåva
Comps inte webbsidor, de är inte en blandning av HTML, CSS och JavaScript-kod. Photoshop, Fireworks och Illustrator kan göra en massa saker som är omöjliga (eller åtminstone vilt opraktiskt) på nätet, vilket ofta innebär att utvecklare kommer att skala ner designen.

Lösning
Prata med din utvecklare när du designar, inte bara efteråt. Fråga dem om en effekt som du använder blir lätt att utföra, eller om ett bättre alternativ finns. Också, som du lär dig mer om webbutveckling, kommer du att bättre kunna skilja mellan när din design är opraktiskt och när utvecklaren är bara slacking av.

Favorithatobjekt # 2: "Färgerna är helt fel!"

Du väljer inte färger godtyckligt, men utvecklarna verkar tro att "nära är nära nog."

Utgåva
Jag vet inte om detta är sant för alla utvecklare, men jag en gång arbetade med en utvecklare som var röd-grön färgblind (han var ett stort fan av vårt innehåll chef, som skickade alla hennes mejl i rosa text på en lime-grön bakgrund). Däremot har är färgblinda inte stoppa honom från att vara en kick-ass utvecklare.

Lösning
Om du vill att färgerna ska höger, sedan redogöra alla färgvärden på sidan. Lita inte på dina utvecklare att ögongloben färgen värden eller ta prov på färgerna i Photoshop.

Du måste också anse att problemet inte kan vara med exploatören men med dig. Färgerna ser olika ut på en Mac och i CMYK (om du råkar av misstag göra det möjligt färgrymd). Se till att ditt dokument färgläge och bevis är inställda på generiska RGB som standard.

Favorithatobjekt # 3: "Vill utvecklarna ens vet vad" white space "betyder?"

Du har lämnat gott om andrum runt element för att skapa en väg vätska öga och förbättra läsbarheten, men utvecklaren CRAMs allt tillsammans, berättar: "Det är det enda sätt det kommer alla att passa."

Utgåva
Jag klagade en gång för en utvecklare att han lämnade något utrymme mellan gränsen till en modul och dess innehåll, vilket gör det verkligen svårt för de flesta att läsa. Han svarade: "Jag bryr mig inte om andra människor. Jag kan läsa det. "Medan de flesta utvecklare är inte riktigt så känslolöst, har de inte fått utbildning i konsten att blanda positiva och negativa utrymmen att styra besökarens öga kring design.

Lösning
Om du verkligen vill att din design ska vara så exakt som möjligt, inte bara ger konstruktören en comp och förväntar sig att räkna ut avståndet. Ange exakta bredder, höjder och längder i en konstruktionsspecifikationer dokument. Detta fungerar som en plan som du och exploatören komma överens om hur saker ska vara placerade.

Åtminstone, definiera allmänna regler för marginaler och utfyllnad. Till exempel "Alla moduler måste ha minst 10 pixlar av utfyllnad mellan innehållet och gränsen."

Favorithatobjekt # 4: "Utvecklaren kan aldrig få min design för att se likadan ut i olika webbläsare."

Man tittar på webbplatsen i Firefox och det ser bra ut, men när du växlar till Internet Explorer den faller i bitar.

Utgåva
Du måste vara välvilligt inställda till den svåra situationen för utvecklare när det gäller att göra modeller ser likartad i webbläsare. Varje webbläsare har sina egna egenheter med avstånd. Saker blir bättre (speciellt med den långsamma döden av Internet Explorer 6), men att få dem alla att helt spela trevliga med varandra är fortfarande svårt.

Lösning
Jag tillåter generellt några pixlar med svängrum i mina konstruktioner för att tillgodose olika webbläsare frågor, men det hjälper att veta vad dessa frågor samtidigt som du skapar, så att du kan hjälpa utvecklaren undvika dem.

Var inte rädd för att påpeka olika webbläsare problem för utvecklare och förväntar sig att de rättas till. Men att lösa några av dem kan kräva att du justera din design.

Favorithatobjekt # 5: "Det här kommer att ta hur lång tid?"

Ingenting är mer deprimerande än att bränna Midnight Oil på dubbel-tid att få din del av ett projekt görs på schemat, bara för att få tillbaka en utveckling Loe (omfattningen av insatserna) som sätter datumet projektet släppa tillbaka en månad från slutet av evigheten .

Utgåva
I en klassisk episod av Star Trek: The Next Generation, förklarar Scotty fakta om tekniska liv till Geordi La Forge: "Du har inte berätta för honom [Kapten Picard] hur lång tid det egentligen skulle ta, eller hur? Åh, grabben. Du har mycket att lära om du vill att folk ska tänka på dig som en undergörare. "Vissa utvecklare tänka på formgivare på samma sätt som Scotty tänker på Starfleet kaptener.

Lösning
Utvecklare vet att de kommer stöta på oförutsedda problem och så brukar grovt pad sina beräkningar. Detta gör också att de ser riktigt bra om de får sitt slut gjort mycket tidigare än beräknat. Köpslår med byggherren ner till en rimlig tidsplan och sedan hålla dem till det. När du lär känna en utvecklare, hittar du förhoppningsvis ditt eget sätt att vara en "undergörare".

Special Bonus favorithatobjekt: "Utvecklare helt enkelt inte förstår formgivare."

Eller ännu värre:
"Utvecklaren tycker att de är designer!"
Det är illa nog när utvecklarna verkar helt enkelt vägrar att se designerns synvinkel, men det meningsskiljaktighet kan vanligtvis förmedlas (oftast genom en bra projektledare). Men när utvecklare tror att de vet mer om design än formgivaren, humöret kan blossa.

Utgåva
Jag har haft att göra med mer än en utvecklare som läst en artikel av Jakob Nielsen och sedan ville föreläsa för mig om god design praxis i mitten av ett möte. Detta visar inte bara brist på respekt för konstruktören men fördröjer projektet som debatten följer.

Lösning
Arbeta med know-it-all utvecklare är knepigt, och sättet att hantera dessa situationer beror på storleken på egot du arbetar med. Generellt tycker jag det är bäst att helt enkelt lyssna på vad de har att säga och sedan, om de har en poäng, erkänner det och gå vidare. Undvik att argumentera med dem om möjligt.

Ofta deras klagomål handlar om en design "regel" som är bruten. Var inte rädd för att erkänna att du bröt en regel, det är vad innovativa designers gör-men se till att du kan motivera varför du bröt den.

När jag befinner mig i denna situation, tror jag tillbaka till min recension dagar i design skolan, när jag var tvungen att försvara mitt arbete mot några ganska brutal kritik. Dessa sessioner var ofta ego-blåmärken, men de lärde mig att snabbt försvara mitt beslut och samtidigt hålla mig cool.

Det kan tyckas förödmjukande att hela tiden måste motivera ditt beslut, men ju mer du visar "metoden i din galenskap," ju mer hittar du att dina kollegor värde och litar på ditt omdöme.