5 Pet Peeves Designers har med utvecklare (och hur man undviker dem)
Katter och hundar. Kain och Abel. Designers och utvecklare. Dessa är bara några av de stora historiska ansikts-offerna.
Designers och utvecklare verkar ofta komma från olika planeter och har helt olika hjärnor.
Utvecklare vill att en webbplats ska fungera rätt, designers vill att det ska se rätt ut.
Även om dessa mål har en hel del överlappning (och förstås stereotypiserar jag lite), kommer skillnaderna ofta ner till konstruktörens och utvecklarens förväntningar om framgång.
Att hantera förväntningarna är en fråga om kommunikation: göra poäng tydligt på andra sidan, hitta en gemensam grund och komma överens om mål.
Okej, så kanske det inte är så lätt, men det är viktigt för båda sidor att åtminstone försöka förstå varandra .
I ett försök att främja godvilja mellan designers och utvecklare kommer jag att dela med några pet peeves jag har stött på och utforska de problem som leder till dem och deras lösningar.
Peeve # 1: "Varför kan inte utvecklaren bara se ut som kompisen?"
Du skapar en snygg design och lämnar komplikationen till din utvecklare, men när du får webbplatsen tillbaka ser det ut som ett lapptäcke av vad du designade.
Problem
Kompis är inte webbsidor; de är inte en blandning av HTML, CSS och JavaScript-kod. Photoshop, Fireworks och Illustrator kan göra många saker som är omöjliga (eller i alla fall vildt opraktiska) på webben, vilket ofta innebär att utvecklarna måste skala ner designen.
Lösning
Prata med din utvecklare när du designar, inte bara efteråt. Fråga dem om en effekt du använder är lätt att åstadkomma eller om ett bättre alternativ finns. När du lär dig mer om webbutveckling kan du också bättre skilja skillnaden mellan när din design är opraktisk och när utvecklaren bara slår av sig.
Peeve # 2: "Färgerna är alla fel!"
Du väljer inte färger godtyckligt, men utvecklare verkar tro att "nära är nära nog".
Problem
Jag vet inte om det här är sant för alla utvecklare, men jag har en gång arbetat med en utvecklare som var rödgrön färgblind (han var en stor fan av vår innehållsansvarig, som skickade alla hennes e-postmeddelanden i rosa text på en limegrön bakgrund). Att vara färgblind hindrade honom dock inte från att vara en kick-ass-utvecklare.
Lösning
Om du vill att färgerna ska vara rätt, stavar du ut alla färgvärden på sidan. Lita inte på din utvecklare att eyeball färgen eller för att prova färgerna i Photoshop.
Du måste också tänka på att problemet kanske inte är med utvecklaren utan med dig. Färgerna ser annorlunda ut på en Mac och i CMYK (om du råkar oavsiktligt aktivera det färgutrymmet). Kontrollera att dokumentets färgläge och -säkerhet är inställda på generell RGB som standard.
Peeve # 3: "Har utvecklare även vet vad" vitt utrymme " betyder?"
Du har lämnat gott om andningsrum runt element för att skapa en flytande öga och förbättra läsbarheten, men utvecklaren stämmer samman och säger: "Det är det enda sättet det passar alla."
Problem
Jag klagade en gång till en utvecklare att han inte lämnade något utrymme mellan gränsen för 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 den. "Medan de flesta utvecklare inte är så kalla, har de inte blivit utbildade i den fina konsten att blanda positiva och negativa utrymmen för att styra besökarens öga runt designen.
Lösning
Om du verkligen vill att dina mönster ska vara så exakta som möjligt, ge inte bara designern en kompis och förvänta dem att räkna ut avståndet. Ange de exakta bredderna, höjderna och längderna i ett designspecifikationsdokument. Detta fungerar som en ritning som du och utvecklaren överens om hur saker ska fördelas.
Definiera i alla fall allmänna regler för marginaler och vaddering. Till exempel "Alla moduler måste ha minst 10 pixlar av vaddering mellan innehållet och gränsen."
Peeve # 4: "Utvecklaren kan aldrig få mina mönster att se lika ut i olika webbläsare."
Du tittar på webbplatsen i Firefox och det ser bra ut, men när du växlar till Internet Explorer faller det i bitar.
Problem
Du måste vara sympatisk för utvecklingen av utvecklare när det gäller att göra mönster ser konsekvent ut över webbläsare. Varje webbläsare har sina egna quirks med avstånd. Sakerna blir bättre (speciellt med Internet Explorer 6 långsam död), men att få dem att spela helt fint med varandra är fortfarande svårt.
Lösning
Jag tillåter i allmänhet några pixlar av wiggle-rum i mina konstruktioner för att rymma problem med cross-browser, men det hjälper till att veta vad dessa problem är när du utformar, så att du kan hjälpa utvecklaren att undvika dem.
Var inte rädd för att peka ut webbläsareproblem till utvecklaren och förvänta dig att de ska åtgärdas. Men att lösa några av dem kan kräva att du anpassar din design.
Peeve # 5: "Det här tar lång tid?"
Ingenting är mer deprimerande än att bränna midnattoljan på dubbeltid för att få din del av ett projekt gjort på schema, bara för att få tillbaka en utveckling LOE (Effektivitetsnivå) som sätter projektets utgivningsdatum tillbaka en månad från slutet av evigheten .
Problem
I en klassisk episod av Star Trek: The Next Generation förklarar Scotty fakta om det tekniska livet till Geordi La Forge: "Du sa inte till honom [Kapten Picard] hur länge det verkligen skulle ta det? Åh, laddie. Du har mycket att lära dig om du vill att folk ska tänka på dig som en mirakelarbetare. "Vissa utvecklare tycker om designers på samma sätt som Scotty tycker om Starfleet Captains.
Lösning
Utvecklare vet att de kommer att stöta på oförutsedda problem och så tenderar att grovt kasta sina uppskattningar. Detta gör att de ser väldigt bra ut om de får sitt slut gjort mycket tidigare än beräknat. Haggle med utvecklaren ner till en rimlig tidslinje och håll dem till den. När du lär dig en utvecklare kommer du förhoppningsvis att hitta din egen väg att vara en "mirakelarbetare".
Special Bonus Peeve: "Utvecklare förstår bara inte designers."
Eller värre:
"Utvecklaren tycker att de är designer!"
Det är dåligt nog när utvecklare verkar helt enkelt vägra att se designers synvinkel, men den meningsskiljaktigheten kan vanligtvis förmedlas (vanligtvis av en bra projektledare). Men när utvecklaren tror att de vet mer om design än designern, kan temprarna flamma.
Problem
Jag har haft att göra med mer än en utvecklare som läste en artikel av Jakob Nielsen och ville sedan föreläsa mig om bra designpraxis mitt i ett möte. Detta visar inte bara respektlöshet för designern men saktar ner projektet eftersom debatten följer.
Lösning
Att arbeta med know-it-all-utvecklare är knepigt, och sättet att hantera dessa situationer beror på storleken på det ego du hanterar. I allmänhet tycker jag att det är bäst att helt enkelt lyssna på vad de har att säga och då, om de har en poäng, erkänner den och fortsätter. Undvik att argumentera med dem om möjligt .
Ofta är deras klagomål om en design "regel" som har brutits. Var inte rädd för att erkänna att du bröt en regel - det är det som innovativa designers gör - men se till att du kan motivera varför du bröt den .
När jag befinner mig i den här situationen tänker jag tillbaka till mina anmälningsdagar i designskolan när jag var tvungen att försvara mitt arbete mot en ganska brutal kritik. Dessa sessioner var ofta ego-blåmärken, men de lärde mig hur man snabbt försvarar mina beslut samtidigt som jag håller mig cool.
Det kan tyckas förödmjukande att ständigt motivera dina beslut, men ju mer du visar "metoden i din galenskap", desto mer kommer du att finna att dina kollegor värdesätter och litar på din dom .
Skriven uteslutande för WDD av Jason Cranford Teague .
Vilka husdjur har du med utvecklare? Vi skulle gärna veta mer om detta, var vänlig dela med dig av dina kommentarer nedan.