Bästa tipsen för en lyckad leverans

En viktigt del i varje leverantörs och beställares vardag är att utbyta material som den andra ska använda. Här är mina bästa tips för att få en snygg och lyckad leverans.

Som teknikbyrå är vi oftast beroende av att andra byråer skickar oss grafisk design, färdiga bilder för ikoner och bakgrunder men också flashar och xml-filer. För att minimera strul, och dyra men onödiga misstag så finns det några saker för varje typ av partner i ett projektsamarbete att tänka på. Här är några vanliga problem som ofta uppstår och undviker man dom här problemen är ett bra resultat nästan garanterat.

Leveranser av bildmaterial och design

Det är alltför vanligt att man som slutresultat får en tillplattad bild som inte går att plocka element från och där fontval är upp till utvecklaren att gissa.

GIF-formatet hör till 90-talet, speciellt om den inte animeras. Genom att välja 8-bitars PNG så är det enkelt att senare gå över till full färg och full transparens utan att behöva ändra i koden överallt.

Vi gillar PSD, ge oss en PSD-fil så kan vi själv plocka ut delar, vi kan välja en text och se vilket teckensnitt och vilken storlek texten är gjord i. Vi kan dessutom enkelt plocka ut element från bilden utan att behöva be en designer om en utklippt ikon. Självklart så blir vi glada om nån annan skapar ikoner men bara om dom är sparade i PNG och är transparanta på rätt ställen.

Ordning och reda på leveranserna. Ofta får vi flera leveranser på sidor där gemensamma element är ändrade. Det är lätt att man plockar element från den filen man just nu arbetar i och ska man hålla koll på vilken av dom dussin filerna som har rätt sidomeny är det lätt att det blir fel.

När vi får en ny leverans på en befintlig design, speciellt om den redan är delvis implementerad så är det bra för oss att veta vad som är nytt i den leveransen, t.ex att högermenyn har fått en annan skuggning. Detta gör det lättare för oss att veta att om vi påbörjat /Utveckling av den så måste den utvecklaren utgå från det nya materialet.

Gärna en enda fil med allt än 100 filer där olika versioner av menyer och andra gemensama element finns. För att hålla ordning på filen utan att duplicera menylager för varje sida använd gärna ”Layer Comps”. Layer Comps dök upp i Photoshop CS2 och bygger på att man i Photoshop kan skapa en namngiven komposition när man väljer vilka lager som ska vara vara synliga per komposition. Man kan t.ex. ha en komposition som heter ”Förstasidan oinloggad” där inloggningsrutan visas. Döp gärna alla lager snyggt också eftersom när man plockar ut designen så vill man ofta dölja textboxar och knappar.

Leverans av Flash

Jag använder ordet Flash här men det gäller såklart också Silverlight och andra pluginlösningar också.

Ofta är det webbredaktörer som lägger in material och vi försöker då bygga mallar och verktyg där man laddar upp och fyller i egenskaper för t.ex flashar som ska visas. Genom att bygga flasharna så att dom konfigureras med XML och som bara kräver en enda parameter (som givetvis är sökvägen till XML-filen) så blir det enkelt för oss att byta flash/XML direkt utan att behöva skriva ny specialiserad kod för varje flash.

Om nåt går snett i flashen, t.ex att den inte hittar xml filen eller om den i filen förväntar sig ett värde av en viss typ så ge nån typ av felmeddelande och inte bara en blank Flash.

Om det är möjligt av licensskäl, skicka med källkoden till flashen. Förutom att det hjälper oss att felsöka så är det ännu viktigare när vi långt senare får i uppdrag att ändra nån del i sajten som påverkar flashen. Det har hänt flera gånger att det inte går att få tag i de som gjort flashen från början och ingen längre kan hitta källkoden - då måste hela flashen skrivas om av någon annan.

Tänk på filstorleken och prestandan! En häftig flash på 1mb kanske känns smidigt när man surfar lokalt med sin quadcore-processor men när man har lite långsammare uppkoppling och den där flashen tar 10 sekunder att ladda och går ryckigt är det inte alls lika roligt. Glöm inte att testa på sämre uppkoppling och långsammare datorer – och även med wmode transparent om flashen ska visas så, eftersom det sänker prestandan.

Testa flashen i en ”riktig” miljö, d.v.s. på en webserver där flashen inte ligger direkt i roten utan längre ner i sökvägen. Det är ganska vanligt att flashutvecklare testar lokalt i en HTML-fil och missar då knepigheter som relativa sökvägar och diverse rättighetsproblem. Anta inte heller att det är ok att lägga saker i roten av sajten, det orsakar både en rörig struktur och stor risk för konflikter.

Leverans av dokumentation för API:er som t.ex webservices och XML

Det är ganska vanligt att främst äldre API:er har dokumentation som inte längre är helt aktuell och ibland helt felaktig, se till att hålla dokumentationen aktuell i samband med att API:t ändras.

Exempelkod är nästan viktigare än dokumentation. Kod kan man köra och enkelt verifiera att API:t fortfarande fungerar som det ska. Om kodexemplet inte fungerar så är det lätt att säga till leverantören att detta är fel och då är det lätt för dem att felsöka också. Om exempelkoden fungerar men våran kod inte fungerar så har vi nått att jämföra med. Att jämföra sin kod med en dokumentation som dessutom kan vara fel är inte alls lika hjälpsamt.

Om det finns speciella krav på parametrarna, t.ex att strängen som heter id måste vara formaterad som en guid eller bara innehålla siffror eller nästan vanligare att telefonnummer måste innehålla landskod, bör detta finnas dokumenterat och givetvis med som ett exempel i koden.

Om ert företag har som affärsidé att tillhandahålla API-lösningar så se till att det finns bra exempel i alla vanliga språk så får ni inte bara mindre supportsamtal utan också möjlighet att förbättra API:t genom att göra det mer kompatibelt med omvärlden.

Att ta emot en leverans

Det finns förstås också saker man som mottagare måste tänka på för att avsändaren ska bli nöjd. En av dom viktigaste är att testa det levererade materialet direkt och inte först när det är panik, ingen gillar att sitta på julafton och lösa problem som borde upptäckts flera månader tidigare. Testa ordentligt så att du kan lämna en detaljerad felrapport, ”det fungerar inte” är inte godtagbart som felbeskrivning.

Tänk på att den som levererat materialet ofta är beroende av sina egna samarbetspartners också. En ändring som behöver göras kan ofta gå igenom flera företag och flera personer på varje företag. Genom att snabbt skicka tillbaka ändringsfrågor istället för att vänta några dagar/veckor så är chansen större att alla är på plats och har projektet i färskt minne.

Även om leverantören har som jobb att lösa problem så är det bara människor ändå och ibland kan det kännas som att allt man gör är fel. Säg gärna nåt positivt mitt allt tråkigt så kan du rädda dagen istället för att bli den där typen som bara kommer med problem. Ett tack för hjälpen när allt är klart gör att nästa gång du ringer så får du en glad person i andra änden som gärna hjälper till. Det är förstås trist att det är fel, men om båda känner att dom hjälps åt för att lösa problemet blir det en mer positiv stämning.

Slutord

Att leverera materialet på ett mer strukturerat sätt kan öka arbetsbördan något men kommer också ge nöjdare samarbetspartners, färre supportsamtal och ett bättre samarbete både externt och internt.

Tommy Söderström
2010-04-22