Monthly Archive for december, 2008

Kunsten at lave et nyhedsbrev

Hvordan sikrer vi fra Creuna at vores kunders nyhedsbreve samt eget, kommer ud til kunden og bliver set som forventet. Lidt om hvad frontenderne hos Creuna kæmper med, og hvordan vi sikrer vores resultat bedst muligt.
Først en lille liste med de mest nødvendige, tekniske, dele i et nyhedsbrev.
 
  • Links
    Overalt på nettet bør man skrive beskrivende linktekster, så ”Klik her” dur altså ikke. En god linktekst er en tekst hvor læseren helt nøjagtigt ved hvad man kommer ind til ved, at klikke her, det er desuden godt for søgemaskiner at have beskrivende links. Hvilket leder mig til næste punkt.
  • ”Kan du ikke se nyhedsbrevet – skal du klikke her”
    Hvorfor er det så vigtigt at give læserne mulighed for at se nyhedsbrevet i deres vanlige browser fremfor i deres mailklient? Det største problem indenfor nyhedsbreve er netop hvorledes nyhedsbrevet bliver gengivet i ens indbakke. Hvis det skulle ske at nyhedsbrevet ikke fik loadet billederne eller teksten korrekt, så har du givet læserne den mulighed at de kan se nyhedsbrevet i en internet browser. Samtidig sikrer du dig et godt indeks over dine nyhedsbreve og giver desuden søgemaskinerne mulighed for at finde dine nyhedsbreve og indeksere dem i deres søgninger fremover.
  • Tilmeld / afmeld nyhedsbrev
    Først og fremmest er det lovpligtigt at have denne funktion. Derudover beroliger det læserne om at du yder service og viser din respekt for modtagerne. Det skal naturligvis ikke være det første blikfang man som læser ser, men det skal i den grad heller ikke gemmes langt væk. Det kan virke underligt at have – ”Tilmeld nyhedsbrev” stående i et iforvejen udsendt nyhedsbrev, men det sker at folk der har modtaget nyhedsbrevet videresender det, og den person der får et videresendt nyhedsbrev, skal naturligvis have den nemmeste mulighed for at tilmelde sig til fremtidige nyhedsbreve.

Hvilket format?

Der er forskellige metoder, i hvilket du kan udsende dit nyhedsbrev. Skal du have mange store flotte bileder og baggrundsfarver mm? Eller er ren tekst som i en standard mail helt fint for dig.

Hos Creuna udsender vi alle vores nyhedsbreve opsat i HTML. Vi ser ikke nogle problemer iforhold til ensartetheden, hvis man har kendskab til markup delen så er det faktisk nemmere at sætte op. Det eneste man skal være opmærksom på er hvordan mailklienterne har tendens til at gengive ens HTML på forskellige måde.

En anden mulighed, som vi ikke anbefaler, er at sende i PDF. Det betyder at man kan sammensætte sit nyhedsbrev på meget kort tid og alle vil se det lige præcis som da man designede det. Problemet er at man skal udsende en vedhæftet fil, og at folk bliver nødt til at have en PDF reader installleret. Det med at udsende vedhæftede filer til folk, som ikke nødvendigvis stoler på dig fuldtud, hænger som regel sammen med en blokkeret mail og dermed intet læst nyhedsbrev.

Apple udsender nyhedsbreve hvor næsten alt er et stort billede, det betyder at de ikke skal være opmærksomme på hvordan forskellige mailklienter gengiver deres tekst, og de har mulighed for at sætte baggrunde og andet avanceret grafik på brevet. Ulempen er dog at tiden det tager at loade mailen er væsentlig længere end hvis det var små billeder og noget tekst. Det tager også væsentlig flere ressourcer at lave sådan en form for nyhedsbrev, det kræver en grafiker til at sætte op. Med vores løsninger i HTML og et CMS til at styrer layoutet, vil næsten alle i firmaet på ingen tid kunne sammensætte et nyhedsbrev, når først elementerne er lavet.

Tilbage til HTML, som er hvad Creuna foretrækker.
Med HTML sikrer du at brugeren ved blot at åbne mailen lynhurtigt kan danne sig et overblik over nyhederne, samt skabe blikfang med flotte billeder, farver og skriftstørrelser. Selvom det bør være indholdet der bærer nyhedsbrevet, så gør det jo ikke noget at danne en harmonisk tryghed når læserne læser dit nyhedsbrev, og samtidig lade dem vide de er velkomne.

Ulemperne ved opsætning af sine nyhedsbreve i HTML er, at det i højere grad tager længere tid. Fordi folk bruger mange forskellige mailklienter, og at mailklienterne har hver deres måde at fortolke HTML’en på, skal nyhedsbrevet sikres en rimelig garanti for at alle læsere vil kunne se nogenlunde det samme. Fra nyhedsbrevet bliver designet og man får dannet sig et godt visuelt design som fanger ens læsere, til at få det sat op og få det ud i præcis de samme miljøer, kan være ret så vanskeligt. Samme problematik er desuden gældende ved hjemmeside-opsætninger, hvor de forskellige browsere opfatter ens kode opsætning på forskellige måder.

Som nævnt tidligere giver HTML-nyhedsbrevet også den mulighed for at have alle ens nyhedsbreve listet på ens hjemmeside med samme design som det udsendte og implementeret i resten af hjemmesidens design. Men den måske vigtigste effekt ved at have dem listet på denne måde, er at søgemaskinerne dermed får mulighed for at indeksere dem.

Lidt teknisk forklaring på hvordan vi sikrer at alle kan se det.

Hvis man holder sig til HTML 3.2 fortolker mailklienterne bedst muligt ens layout. Derudover skal man glemme alt om CSS og holde sig til de gammeldags HTML metoder. For at bestemme fonten skal man bruge de gamle <font face=”Arial” size=”5” color=”#000000”> tags. Layoutet sætter man op i tables og benytter align til at centrere. Padding og margin som man kender fra CSS kan ikke benyttes. Derfor må man bruge line-height og spacer images. Dvs. der hvor man skal bruge afstand mellem to linjer kan man sætte et 1×1px blankt billede, som kun har til formål at sørge for at td’en man sætter den i bliver udfyldt ens i alle klienter. Det er yderst vigtigt at angive højde og bredde såvidt muligt på alle billeder og gerne også på alle td’er.

Til slut når alt er sat op, så man i en browser kan se det giver god mening, SKAL det testes i så mange mailklienter som muligt. I Mozzilas Thunderbird (mailklient) kan man udsende ens HTML, og så bør man sende til: Thunderbird, Outlook, Yahoo, Gmail og Lotus Notes. Hvis brevet ser næsten ens ud i dem alle, så er man ret godt sikret for at ens læsere vil se det samme.

Geeks hygger og laver forretning

Det der for mange år siden åbenbart var en biograf, og for 30 minutter siden var Creuna Stockholms flotte kontormiljø, er lige nu fyldt med en imponerende mængde lyd- og lysudstyr og Boeing-747-lignende rækker af stole. Andreas “roddaren” Fredriksson (a.k.a CTO) ser endelig tilfreds ud. Action.

Stemningen er god når Robert Nyman og Christian Heilmann hilser de 150+ geeks velkomne til årets sidste Geek Meet. Evangelisten og Nerd’en Heilmann lægger ud med en præsentation om web page performance, hvilket jo for dem af jer der følger med i blogsfæren de sidste år har været meget højt op på Yahoo’s agenda.

Indholdet er godt, selv om meget af det han fortæller ikke er så frygtelig nyt for os i Creuna, men Christian kommer med nogle rigtig gode opsummeringer, som godt kan tåle at blive genopfrisket:

  • Det er ikke forkert med store HTML/CSS/JS-filer, bare vi husker at slå Gzip til på serveren.
  • Det er heller ikke forkert med <script> tags eller flash, men det er vigtig at vi overvejer hvor, og hvordan, vi pakker dem ind i vores HTML-side.
  • Rigtig mange <img> tags er også helt fint. Husk dog at tænke over hvis der virkelig er behov for at alle bliver loadet hvis brugeren kun ser de øverste 600 pixels?

Christian nævner også den klassiske tilgang til at minimere eksterne javascript- eller css-filer ved at angive bede serveren om en samlet fil i stedet for. Men pas på med hvordan vi gør det:

<script type="text/javascript" src="/pack.ashx?files=config,base,effects,validation,widgets"></script>

Dette kan give problemer, da mange browsere har valgt at følge W3Cs URI-standard, der siger at en url med query-parametere skal som udgangspunkt ikke gemmes i den lokale cache.

<script type="text/javascript" src="/pack/config/base/effects/validation/widgets"></script>

Alternativet, en almindelig fil-sti. I eksemplet ovenfor styrer MVC-controlleren ”pack” håndtering af URL’en. Noget for URL-arkitekten?

Pause. Pizza. Og pils.

Ny præsentation af Hr. Heilmann – Playing with the Web.

Det er her jeg får min store eye-opener. Christian, viser meget kode og det er i bund og grund meget teknisk (cURL, PHP, YUI, Greasemonkey, BOSS osv). Det er dog ikke det tekniske der er budskabet, men et af de vigtigste elementerne i O’Reillys tidlige definition af Web 2.0, nemlig ”Play”.

“Never stop to fiddle, tweak and poke at the things people offer you on the web”

Jo mere Christian taler om det, desto mere læner jeg ubevidst mig frem mod scenen. Han viser eksempler på hvor nemt det nu er at kombinere en site med en anden, måske pimp’e løsningen op vha nogle services, og oven i det, faktisk have mulighed at nærmest gøre det 100% clients-side.

Det var jo sådan det var, den gang i 90’erne, hvor Internet var nyt, og alt var muligt. Nu er det bare endnu nemmere da alle værktøjer er der, online, ready-to-use.

Det stiller godt nok krav. I rollen som konsulent kan jeg ikke altid tillade mig at lege med teknikken – hvem betaler for den tid? Spørgsmålet er hvis jeg kan tillade mig at ikke gøre det? Kan vores kunder tillade sig at ikke investere tid i det?

Forskellen fra de glade amatører i 90’erne er at legepladsen ikke længere er for nogle få udvalgte, men for alle, også ikke-tekniker. Og det vi kan opnå ikke længere er personlig opmærksomhed og street-cred, men faktisk hard core forretning.

Det stiller krav, og rejser spørgsmålet hvis vi geeks tillader os at være innovative nok?

 

PS. Du kender vel værktøjerne Smush.it!, JSLint (Warning: JSLint will hurt your feelings…), Hammerhead og YSlow, ikke også?

Christian Heilmann live fra Stockholm kl. 18:30

Vores kolleger i Stockholm inviterer i aften til GeekMeet. I aften går Christian Heilmann på – Christian arbejder som International Developer Evangelist hos Yahoo og er det er en stor ting, at kunne byde ham velkommen som taler til Creuna GeekMeet.

Du kan ikke nå til Stockholm inden kl. 18:30, så sikke et held at Creuna Sverige sender GeekMeet live her på kanalen. Kl. 18:30 nu i aften d. 4 december!

Når dingenoter bliver til service

Der foregår en interessant udvikling hos en række af de helt store markante elektronik producenter.

Nokia proklamerede sidste år at de vil være et service firma og har for at følge det op lanceret en række spændende produkter som Ovi, Comes with music og Smarthome platformen

Apple har til dels allerede haft success på samme måde med at kombinere service som itunes med nogle lækre produkter som Ipod’en. Måske har de faktisk gjort det så godt at de har det problem at folk ikke køber nye ipod’s Det betyder at Apple i højere grad kommer til at fokusere enten på helt nye produkter eller øge indtjeningen på deres eksisterende services.

Den samme tendens gør sig gældende i en lang række andre brancher hvor firmaer som traditionelt var produktorienterede i langt højere grad baserer deres forretning på services. Det er for eksempel interessant at se hvordan Toyota, Citroen og Peugeot kan lancere den samme bil og så differentiere sig i forhold til hinanden på service.

Alt dette er der en lang række grunde til, som i sig selv er interessante, men konsekvenserne er langt mere interessante. Bevægelsen fra produktorientering til service har en række konsekvenser for et firmas forhold til deres kunder. Som for eksempel:

- Firmaets ydelse er en dialog med kunden. Jeg kan ikke forhandle om min kaffe skal være kaffe hos starbucks, men kan jeg forvente at de smiler og kommer ned med koppen? Det betyder at et service firma i en vis grad afgiver noget magt om definitionen på hvad de leverer til kunden. Så når Nokia leverer Ovi kan de ikke på samme måde kontrollere hvad det skal bruges til som de kunne definere hvad min telefon skal kunne.

- Firmaerne er prisgivet kundens oplevelse. En service bliver først til i det øjeblik kunden benytter sig af den. Et hotel ophold er ikke en ting jeg kan tage med hjem, men en oplevelse som er baseret på mine behov, som kan være alt fra ‘et sted at sove’ til ‘afslappende luksus’, mine personlige erfaringer og hvad jeg har hørt om stedet og så den faktiske oplevelse jeg har på hotellet.

Man kunne være så fræk at sige at firmaets vigtigste parameter i fremtiden udelukkende vil være baseret på interaktion med kunden og kvaliteten af den interaktion kan opgøres i hvor sandsynligt det er kunden vil anbefale firmaet. Noget som Frederick Reichfeld redegør for i denne artikel i Harvard Business Review

Det ville da være fedt hvis det var så nemt: Lav noget der skaber en så fed oplevelse hos dine kunder så de gider anbefale dig…

Service Design Konferencen i Amsterdam

Service Design er et fag der udvikler sig kraftigt i øjeblikket. Jeg har i længere tid fulgt især de ting som sker omkring Service Design Network
Så mine forventinger var tårnhøje da min gode kollega Niels og jeg tog afsted til Amsterdam til Service Design konferencen i Amsterdam.

Vi var med i to dage, den første med en række oplæg fra pionerer inden for service design som Birgit Mager fra Service design instituttet i Köln og folk fra en række agencies som Live|Work og IDEO.
Det var især fedt at folk præsenterede rigtige cases med konkrete erfaringer. F.eks. præsenterede Østrigske MobilKom en række af de initiativer omkring hvordan de øgede kundetilfredsheden og ikke mindst hvordan de målte og evaluerede effekten af deres tiltag.
Craig La Rosa fra Amerikanske Continuum viste hvordan man kan redefinere købet af forlovelses ringe og hvordan man får tappet blod. Det er ret vildt hvor langt man kommer når man arbejder metodisk og strategisk med design og ikke bare dykker ned i det enkelte medies muligheder.

Fra den første dag fik jeg ikke blog indtrykket af en design retning som ikke blot omhandler et specifikt problem område (service) men som også har en holdning og en attitude. F.eks. var det tydeligt at det er vigtigt at sørge for at forankre design i hele organisationen, at man hellere arbejder med åbne processer end lukkede top-down ekspert drevne processer og at innovation ikke har noget som helst med gode ideer at gøre, det handler om process.

Den anden dag på konferencen var i workshoppens tegn (jeg havde valgt Adding Values to commodities) hvilket var superfedt, så Hvis nogen har brug for det vildeste koncept for et livscyklus forløb for hundemad kan de bare henvende sig til undertegnede…

(Jeg opdaterer denne post når der er et link til de enkelte taleres oplæg)