HEJO MAIL -

Karolina Samuelsson 1986-07-17

Examensarbete

HEJO MAIL - HTML och CSS för email

Abstrakt

”HEJO MAIL – HTML och CSS för email” handlar precis som titeln antyder om användandet av HTML och CSS för att utforma e-postmeddelanden och är en undersökning över vilka standarder som finns eller åtminstone borde finnas. Viktiga fraser vid informationssökningen har varit ”Html Email”, ”Email Standards” och

”Email Programming”. Resultatet är tänkt att appliceras på HEJO MAIL, som är en applikation för utskick av nyhets- och informationsbrev som idag inte fungerar fullt ut.

Resultatet är något förvånande då standarder specifikt för email saknas och har ersatts med rekommendationer, resultatet innefattar en sammanställning av rekommendationer från tre olika källor som valts ut. Dessa rekommendationer har även testats för att verifiera att det faktiskt fungerar med hjälp av 11 stycken testmail. Diskussionen innehåller ett förslag på en praktisk lösning med modultänk för HEJO MAIL samt ett försök att sammanfatta arbetet och återknyta till frågeställningarna.

Abstract

"HEJO MAIL - HTML and CSS for email" is like the title suggests a thesis about the use of HTML and CSS to design electronic mail and what standards there are to be applied, or at least should be. Key phrases in the search for information have been

"HTML Email", "Email Standards" and "Email Programming". The results are intended to be applied on HEJO MAIL, which is an application for sending news and

information letters via email that is not working properly.

The result is somewhat surprising since standards specific for email do not exist and have been replaced with general recommendations, the result consists of a compilation of recommendations from three different sources that have been selected. These recommendations have also been tested to verify that they are actually functioning by the creation of 11 emails for testing. The discussion part of the thesis includes a suggestion of a practical solution with modular structure for HEJO MAIL and an attempt to summarize the work and the questions of issue.

Förord

Arbetet har utförts som ett avslutande examensarbete, den sista pusselbiten, för högskoleprogrammet Webbprogrammering vid nuvarande Linnéuniversitetet (tidigare Högskolan i Kalmar). Idén till det här arbetet kommer ifrån företaget HEJO Interactive som har en tjänst, HEJO MAIL, för utskick av nyhets- och informationsbrev som idag inte fungerar helt tillfredställande.

När arbetet påbörjades fanns någon slags föreställning om att jag snabbt och lätt skulle leta upp standarder för email i en välskriven bok, sammanställa detta och sedan snabbt hoppa på implementering av tjänsten – det är ju så det brukar gå till! Man är ovan vid att den research man gör faktiskt får ta tid och räknas, oftast brukar det vara effektiv implementationstid som räknas och syns utåt så det var en viktig lärdom jag fick med mig. Så här efteråt känns ändå resultatet som det bästa av allt - att jag har skapat en rejäl teoretisk grund att stå på, kommit fram till resultat som faktiskt går att bevisa och som är pålitliga, resultat som jag med stolthet kan presentera för min uppdragsgivare.

Jag skulle slutligen vilja rikta ett stort tack till Johan Henriksson och Robert Nilsson på HEJO Interactive för att de gett mig den här möjligheten och för att de tagit sig tid och varit ett gott stöd under projekttiden. Jag skulle även vilja tacka Daniel Toll som varit min handledare vid Linnéuniversitetet och som kommit med uppmuntrande och hjälpsamma kommentarer, främst vad gäller utformandet av rapporten. Ett sista tack går till de personer i min omgivning; familj, vänner och kurskamrater som stundtals fått stå ut med mitt inofficiella gnäll.

Innehållsförteckning

1. Introduktion ... 1

2. Bakgrund ... 2

2.1 Verksamhetsbeskrivning... 2

2.2 Teoretisk bakgrund ... 2

2.2.1 HTML ... 2

2.2.2 CSS ... 3

2.2.3 Emailklienter ... 4

2.3 Avgränsningar... 4

3. Mål... 5

4. Genomförande ... 6

4.1 Metod ... 6

4.2 Metoddiskussion ... 7

5. Resultat... 9

5.1 Rekommendationer... 9

5.1.1 Email Standards Project ... 9

5.1.2 Campaign Monitor ... 12

5.1.3 Mail Chimp ... 13

5.2 Tester... 15

5.2.1 Testmail 1 ... 18

5.2.2 Testmail 2 ... 24

5.2.3 Testmail 3 ... 25

5.2.4 Exempelmail 1 ... 26

5.2.5 Exempelmail 1.1 ... 26

5.2.6 Testmail 4 ... 28

5.2.7 Testmail 4.1 ... 29

5.2.8 Testmail 5 – 5.1 ... 29

5.2.9 Testmail 6 ... 32

5.2.10 Exempelmail 2 ... 33

6. Diskussion ... 34

6.1.1 Återkoppling till frågeställningar ... 34

6.1.2 Framtida utveckling ... 37 7. Källförteckning ... 38

7.1 Elektroniska källor ... 38

1. Introduktion

Arbetet är till stor del en teoretisk undersökning av hur HTML och CSS bör kombineras och utformas för att ge ett gott resultat vid utformandet av email och tolkning i emailklienterna. I nuläget ser resultatet ut som man tänkt sig i webbläsaren men inte när det senare tolkas av den specifika emailklient som användaren har och dessa problem har alltså sin grund i den HTML- och CSS-kod som är själva kärnan i mailet. Tanken var därför att försöka hitta vilka standarder som gäller för utformandet av email vilket visade sig vara lättare sagt än gjort. Efter att resultaten sammanställts har de även testats genom ett flertal testmail för att försöka göra dem mer pålitliga än andra resultat man kan hitta via internet, till exempel. Detta borde göra resultatet intressant även för andra utvecklare av email.

Ett grundläggande syfte med arbetet, från högskolans sida, är att få chans att pröva de kunskaper man tillgodogjort sig under två års utbildning inom webbprogrammering och HTML och CSS för webben är en av grundstenarna i utbildningen. De har varit inblandat i stora delar av densamme, ända sedan starten. En undersökning av andra användningsområden utöver ren webbutveckling kändes därför klart intressant och givande.

2. Bakgrund

I följande avsnitt beskrivs problemområdet mer ingående. Vad har arbetet för utgångsläge och var kommer fokus att ligga? Avsnittet innehåller även en kortare teoretisk bakgrund med viktiga begrepp inom arbetet.

2.1 Verksamhetsbeskrivning

HEJO MAIL är en existerande tjänst som är tänkt att användas för att göra utskick av nyhets- eller informationsbrev. Man riktar sig till medelstora företag och föreningar som har tillräckligt god ekonomi för att engagera sig i marknadsföring men som inte vill anlita en reklambyrå. Målet är en enkel och lättanvänd tjänst som ska underlätta för användaren att göra större utskick till sina kunder.

Man använder sig idag av en editor inbyggd i tjänsten där användaren själv kan lägga in den text de vill ha med, ändra färg och skapa rubriker och de kan även lägga till bilder.

Det finns en funktion för att förhandsgranska, den här delen stämmer mycket bra överens med de kommandon användaren skrivit in i editorn.

Bakom scenen förvandlas dessa kommandon och val till HTML-kod med inline CSS som blir själva kärnan i mailet man vill skicka iväg och det är här man stött på problem, vissa mailklienter tolkar inte den genererade koden på önskvärt sätt.

Problemet rör i första hand placeringen av bilder och text som inte följer de direktiv som användaren gett vilket i sin tur innebär en negativ upplevelse. Självklart vill man på HEJO Interactive försöka komma till rätta med det här problemet för att kunna erbjuda tjänsten till sina kunder.

2.2 Teoretisk bakgrund

2.2.1 HTML

HTML står för Hyper Text Markup Language och är det dominerande språket för en standardiserad kodning av till exempel webbsidor. Tanken med denna standard är att man ska kunna strukturera upp sina HTML-dokument med hjälp av olika element, såkallade ”taggar”. HTML är alltså inget programmeringsspråk utan snarare ett märkningsspråk (eng. markup language). HTML taggar anger till exempel hur texten

man skrivit är indelad i stycken, rubriker, om det finns några länkar eller bilder och så vidare.

Det finns även taggar som har med presentation att göra som kan ändra färg på texten eller göra den fetmarkerad men dessa taggar anses föråldrade och man bör undvika att använda dem överhuvudtaget och istället använda sig av CSS.

HTML finns i vad som skulle kunna ses som flera olika versioner där olika taggar används och tillåts på olika sätt. I dagsläget är den mest använda versionen HTML 4.0 som i sin tur kan delas in i tre Dokumenttyps Definitioner - ”DTD” (eng. Document Type Definition) - Frameset, Transitional och Strict som används för att validera dina HTML-dokument. I dessa definitioner som man refererar till i HTML-dokumenten finns det specificerat vilka taggar som är okej att använda och hur.

(Källa: W3Schools – HTML)

2.2.2 CSS

CSS står för Cascading Style Sheets. Medan HTML koden har hand om själva strukturen av de dokument man skriver används CSS för att styra presentationen. Man kan med hjälp av CSS bestämma vilken positionering, bredd eller färg ett visst element ska ha.

Det finns tre olika sätt för användning av såkallade stilmallar (eng. stylesheets):

1. Man kopplar koden direkt på elementet i stil med <p style=”color: red;”>, detta kallas att använda sig av inline CSS. Detta sätt anses dock vara på utgående eftersom det är svårt att underhålla och skapar tunga HTML-dokument.

2. Man använder sig av ”STYLE”-taggen som placeras inom HTML-dokumentets

”HEAD”-sektion enligt <style type=”text/css”>---Stildefinitioner---</style>.

Elementen anropas sedan via sin typ, sitt id eller en klass till exempel kommandot ”p { color:red; }” skulle medföra att all text inom ”P”-taggar färgas röd. Detta sätt kallas inbäddad (eng. embedded) CSS.

3. Man länkar till ett externt CSS-dokument genom en ”LINK”-tagg enligt <link href=”myexternalstylesheet.css” rel=”stylesheet” type=”text/css”/> Strukturen på detta dokument liknar till stor grad det som i ovan nämnda punkt placeras inom

”STYLE”-taggen där man alltså kopplar egenskaper till element via typ, id eller klass.

Detta sätt brukar anses som det mest optimala eftersom ett och samma dokument går

att applicera på flera HTML-dokument samtidigt, det påverkar inte heller laddningen av HTML-strukturen eftersom dessa skiljs åt.

(Källa: W3Schools – CSS)

2.2.3 Emailklienter

En emailklient är ett verktyg för att hantera, läsa och formatera email. Det finns olika typer av klienter och denna rapport kommer fokusera och skilja på två av dessa:

Plattforms- och webbaserade. De webbaserade klienterna kan endast nås via en webbläsare och ingen installation av några särskilda program behövs på datorn vilket medför att man kan logga in och nå sina email från i princip vilken dator man vill. Med plattformsbaserade klienter avses å andra sidan de emailklienter som mer liknar ett program som installeras direkt på datorn och går att nå utan att behöva gå vägen via en webbläsare, det som görs är dock oftast att man kopplar en webbaserad klient till den plattformsbaserade klient man installerat.

2.3 Avgränsningar

Arbetet kommer i huvudsak inriktas på att undersöka hur den HTML- och CSS-kod som ett email består av bör se ut för att kunna tolkas och presenteras korrekt av de mest använda mailklienterna. En sådan begränsning grundar sig i att kunden vill ha ett utförligt och pålitligt resultat och en stabil lösning samt att arbetet endast sträcker sig över dryga 10 veckor. Arbetet kommer att inriktas på de mest använda emailklienterna efter önskemål från HEJO Interactive.

Det vore även önskvärt att hitta förslag på hur detta resultat skulle kunna användas rent praktiskt även om det inte finns tid för en implementation av en sådan lösning.

3. Mål

Målet med projektarbetet är alltså att hitta en fungerande lösning vad gäller utskick av nyhets- och informationsbrev.

De frågeställningar arbetet ämnar besvara är:

 Finns det någon gemensam standard för HTML och CSS i email?

o Vilka rekommendationer finns det?

 Fungerar dessa standarder eller rekommendationer som förväntat i emailklienterna?

 Hur skulle detta kunna användas rent praktiskt?

4. Genomförande

Under denna rubrik beskrivs hur arbetet bedrivits, hur informationssökningarna gått till och kapitlet avslutas med en metoddiskussion gällande för- och nackdelar med de tillvägagångssätt och metoder som tillämpats.

4.1 Metod

Stora delar av det tio veckor långa arbetet har varit förlagt på HEJO Interactives kontor i Alingsås på fasta kontorstider. På kontoret har det även funnits tillgång till ständig kundkontakt och feedback samt möjligheter till backup och säkerhetskopior av arbetet via företagets servrar.

Som projektmodell har en variant baserad på Unified Process (hädanefter kallad UP) använts. UP är en iterativ utvecklingsmodell som innebär att man arbetar i iterationer, i det här fallet veckovis indelade perioder, som alla innefattar de fem olika delarna;

Analys/Design, Krav, Implementation, Test, Leverans. Man arbetar alltså kontinuerligt med att t.ex. uppdatera vilka krav som finns på projektet, ingenting är ristat i sten. UP är även indelat i fyra större faser; Inception, Elaboration, Construction och Transition med olika fokus på olika delmoment, Inception innehåller t.ex. större andel Krav eller Analys än vad Construction gör som har större fokus på implementation.

En av de mest krävande delarna i arbetet har varit rapporten. Den har tillägnats mycket tid och har uppdaterats kontinuerligt under arbetet. Till en början skedde uppdateringarna mer sällan i och med att mycket material inte var klart. Ett stort steg framåt kom i och med att resultatdelen utvecklades.

Stora delar av arbetet har varit teoretiskt och inriktat på att hitta information för att kunna försöka besvara de frågeställningar som arbetet varit inriktat på. Sökningen har varit indelad i två delar: Del ett inriktades på att försöka hitta vetenskapliga artiklar och litteratur inom området. Sökningar efter artiklar gjordes främst genom sökningar i databasen DiVA som finns tillgänglig genom Linneuniversitetet. Litteratursökningar gjordes genom den svenska bibliotekstjänsten Libris samt via den onlinebaserade boktjänsten Ebrary. Då detta resultat inte gav önskat utfall inleddes del två av sökningarna som var något mer informell och skedde via internet och sökmotorer.

Sökfraser som använts flitigt har varit ”Html Email”, ”Email Standards” och ”Email Programming”. Här fanns resultat i form av artiklar, bloggposter och guider.

För att öka pålitligheten i resultatet bestämdes att informationen som hittades inte enbart skulle sammanställas utan även objektivt testas genom 11 stycken test- och exempelmail. De svarar på frågan ”Fungerar rekommendationerna?” och visar att ”Så här skulle ett email kunna se ut”. De har testats i nio olika emailklienter, fem

plattformsbaserade och fyra webbaserade klienter. De plattformsbaserade klienterna som använts är Apple Mail 3.6, Mozillas Thunderbird 5.0, Microsoft Outlook 2007 och Express samt Windows Live Mail 2009. Webbklienterna var Googles Gmail, Windows Live Hotmail, Outlook Web Access och Yahoo. Eftersom de webbaserade klienterna till viss del påverkas av vilken webbläsare som använts har resultatet för dessa även testats i fem olika browsers; Firefox 3.6.3, Google Chrome 4.1, Internet Explorer 8, Opera 10.53 och Safari 3.1.2.

Samtliga mail utformades efter HTML Transitional 4.0. Mailens utseende

kontrollerades i webbläsaren Firefox med godkänt resultat innan de skickades vidare ut till emailklienterna.

4.2 Metoddiskussion

Att arbetet utförs under en pressad tid på endast dryga tio veckor är en klar nackdel som påverkar resultatet, man önskar att det funnits mer tid för att kunna komma fram till ett mer komplett resultat. Samtidigt är det även viktigt att begränsa arbetet och hitta fokus och tydliga avgränsningar för arbetet och specificera vilka resultat man vill uppnå så att det inte svävar iväg vilket tidsbegränsningen krävde per automatik.

Som distansstudent är det svårt med fasta rutiner och arbetet blir gärna ostrukturerat och ”hattigt”. Det innebär att man aldrig riktigt kan känna sig ledig eller mäta de resultat man uppnår i förhållande till tiden man spenderat eftersom allt blir väldigt flytande över tid och rum. Att med denna utgångspunkt flytta sitt arbete hemifrån till ett kontor med fasta arbetstider kändes som en befrielse och en fantastisk fördel! Det har varit lätt att skilja på när man varit student och när man varit privatperson och man har med gott samvete kunnat ha ledigt röda dagar, till exempel.

Att tillämpa Unified Process (UP) under arbetet kändes naturligt eftersom detta är den metod vi kommit i kontakt med under tidigare kurser och arbeten. Det kändes inte befogat eller nödvändigt att börja leta efter alternativa projektmodeller i detta skede utan snarare att anpassa UP efter de egna behoven.

En oväntad vändning i arbetet var när utbudet av vetenskapliga artiklar och relevant litteratur inom området visade sig vara såpass tunt, för att inte säga obefintligt. Det kändes svårt att navigera bland resultat från sökmotorer och att få en känsla av vilka artiklar och guider som är pålitliga och vilka som författas på mindre seriösa grunder.

Det var därför viktigt att dra alla resultat över en kam och först läsa igenom dem och sedan testa dem istället för att blåögt bestämma sig för att ett resultat verkade mer pålitligt och påkostat än något annat, det var en viktig lärdom att vara kritisk i sitt arbete. Det kändes även viktigt att inte förkasta några sökresultat på grund av textens formatering eller webbsidans utseende och tillämpa ordspråket ”Det är insidan som räknas”, i det här fallet innehållet.

5. Resultat

I detta kapitel presenteras resultaten av informationssökningen och vad testningen har gett för utslag samt en sammanställning av hur email bör formateras för att få ett så gott och jämlikt resultat som möjligt i de olika emailklienterna.

5.1 Rekommendationer

Det resultat som informationssökningen gett är att det finns inga direkta standarder som är inriktade på just användandet av HTML och CSS i email. De standarder som finns är för webben och rent teoretiskt är det dessa man skall utgå ifrån. I praktiken fungerar det dock inte fullt ut.

Även om standarder saknas finns det gott om rekommendationer för hur email bör utformas. Dessa rekommendationer kommer dock från webbsidor och artiklar som inte är vetenskapliga, artiklar som alltså saknar till exempel granskningsreferenser, samtidigt som många av dem är färgade av skribentens åsikter eller eventuella företagstillhörigheter.

Här nedan presenteras och sammanställs dessa rekommendationer för att sedan kopplas till testmailen i den mån de anses användbara för HEJO MAIL.

5.1.1 Email Standards Project

Efter Email Standards Projects (hädanefter ESP) undersökningar 2007 delade de in emailklienterna i två kategorier: De som har gediget stöd och de som rekommenderas förbättringar. Indelningen såg ut som följer:

Gediget stöd

 Apple Mail

 Mozilla Thunderbird

 Windows Live Mail

 Yahoo! Mail

Förbättringar rekommenderas

 Google Gmail

 Microsoft Outlook 2007

 Windows Live Hotmail

I tabell 5.1.1.1- 5.1.1.4 ges en överblick över vilka egenskaper som testades och hur stödet för dessa var fördelat i emailklienterna. Tabell 5.1.1.1 och 5.1.1.2 visar

egenskaper som satts till hög prioritet, essentiella egenskaper som det är viktigt att det finns stöd för enligt ESP. Dessa egenskaper hanterar positionering och färgsättning av både element och text.

Tabell 5.1.1.1 De högt prioriterade egenskapernas stöd i de plattformsbaserade emailklienterna

Tabell 5.1.1.2 De högt prioriterade egenskapernas stöd i de webbaserade emailklienterna

Tabell 5.1.1.3 och 5.1.1.4 som följer visar egenskaper som är mer åt det förskönande hållet, egenskaper som hanterar till exempel textens utseende utöver färg eller kantlinjer. Dessa är inte lika högt prioriterade.

Tabell 5.1.1.3 De lägre prioriterade egenskapernas stöd i de plattformsbaserade emailklienterna

Tabell 5.1.1.4 De lägre prioriterade egenskapernas stöd i de webbaserade emailklienterna

ESP rekommenderar att bilder som enbart rör utseende och egentligen inte har någon inverkan på innehållet placeras i mailet med hjälp av egenskapen ”background-image”

eftersom separation mellan innehåll och presentation alltid är att föredra samt för att det underlättar för de enheter som inte stödjer CSS, till exempel mobiltelefoner. De önskar även att all CSS placeras inbäddad för att öka tillgängligheten och för att få ner dokumentets storlek i och med att mycket av koden är möjligt att återanvända.

5.1.2 Campaign Monitor

I artikeln Email design guidelines från Campaign Monitor (hädanefter CM) börjar man med att påpeka att webben är i ständig framfart och att standarderna där utvecklas kontinuerligt i en rasande fart men att för emailklienter är det helt tvärtom – antingen står utvecklingen stilla eller så går utvecklingen bakåt, det man syftar på då är releasen av Outlook 2007 som istället för utökat stöd tog ett enormt steg tillbaka genom att byta renderingsmotor från Internet Explorer till ordhanteraren Microsoft Word.

Man rekommenderar till en början fokus på tre saker: 1. Håll det enkelt. Ju mer avancerat och komplext mailet är utvecklat desto större risk är det att någon del av det inte tolkas korrekt av emailklienterna. 2. Ta kodandet ett drygt årtionde tillbaka i tiden, tillbaka till nästlade tabeller och inline CSS. 3. Testkör dina mail kontinuerligt. Bara för att det ser klockrent ut en dag kan det släppas en uppdatering och se helt förkastligt ut redan nästa vecka.

5.1.2.1 Layoutrekommendationer

När det gäller den praktiska utformningen av email rekommenderar CM användandet av tabeller för planering av layouten och positionering. De anser vidare att den mest pålitliga aspekten vad gäller ”width” är att ange önskad bredd i pixlar på varenda cell i tabellen jämfört med att sätta bredden direkt på tabellen eller via CSS, att använda pixlar är viktigt eftersom användandet av procent lämnar allt för mycket utrymme för egen tolkning. Ingen breddsättning bör heller lämnas upp till emailklienten, det kan sluta precis hursomhelst. Vidare skriver CM att en del klienter inte tolkar

bakgrundsfärg som är satt via CSS eller på ”BODY”-taggen och rekommenderar en yttre tabell som täcker hela den önskade ytan, man går här emot lite av det man tidigare sagt och rekommenderar att bredden sätts till 100 %. Enligt artikeln kan det även vara svårt med utrymme omkring paragrafer, ”P”-taggar, främst i Yahoos mailklient. Har man ett mail som är oerhört känsligt vad gäller avstånd och att varje liten pixel räknas bör man sätta en såkallad ”padding” direkt på varje element det berör.

5.1.2.2 CSS rekommendationer

När det kommer till rekommendationer gällande CSS skriver CM att all CSS bör flyttas inline, detta på grund av att vissa av de webbaserade klienterna skalar bort

dokumentets ”HEAD” -tagg och i vissa fall även ”BODY”-taggen där inbäddad CSS i normala fall brukar placeras. Man bör enligt rekommendationerna inte heller använda

sig av CSS-förkortningar såsom att deklarera alla egenskaper för texten efter en font- deklaration (font: 17px, Tahoma;) utan att man delar upp det i textstorlek (font-size) och teckensnitt (font-family). Detta gäller även användandet av förkortade koder för hexadecimal färgsättning, för webben fungerar det alldeles utmärkt att förkorta den svarta koden #000000 till #000 medan detta bör undvikas vid utformandet av email eftersom detta kan ställa till problem. Slutligen vad gäller CSS höjs en varningens flagga när det gäller egenskapen ”float”, den saknar stöd i till exempel Outlook 2007 och man rekommenderar ett något föråldrat attribut som placeras direkt på elementet det gäller som kallas ”align”.

5.1.2.3 Bildrekommendationer

Sista avsnittet i artikeln som gäller rekommendation för klient- och webbaserade handlar om hantering av bilder. Den första punkten som CM rekommenderar att man tänker på är att många bilder blockeras automatiskt av emailklienterna. Det kan därför vara riskabelt att förlita allt för stor del av sitt mail på bilder vad gäller layouten. Nästa punkt gäller att man ska ange vilken storlek man önskar på bilderna, annars har de flesta klienterna fördefinierade storlekar som de tillämpar om ingen storlek angetts vilket kan ge ett oväntat resultat. Vad gäller filtypen för bilder är det GIF eller JPG som rekommenderas, det betyder en något högre filstorlek men ger bättre stöd framförallt i klienten Lotus. Vid användande av bilder som bakgrund bör man alltid ha en bakgrundsfärg tillgänglig som alternativ för de emailklienter som inte stödjer CSS- egenskapen ”background-image”. En annan viktig aspekt är att alla bilder bör förses med ”alt”-attributet. Detta är ett attribut som ”IMG”-taggen kräver och som är tänkt att visas om en bild har blockerats eller inte kan visas av annan anledning. Man kan dock inte räkna med att ”alt”-attributet visas i alla lägen eftersom det även är vanligt att det skalas bort av bland annat Outlook 2007, Hotmail och Apple Mail.

5.1.3 Mail Chimp

Free guide från Mail Chimp skiljer sig något från de andra källorna, den är mer

omfattande och innehåller även information om email i allmänhet, om hur de fungerar rent tekniskt och så vidare, men det finns även en del rekommendationer gällande HTML och CSS och det är dessa som kommer att sammanfattas nedan.

5.1.3.1 Layoutrekommendationer

Man bör ha en bredd på mailet som ligger på 500-600 pixlar, det är alltså andra riktlinjer än vad som gäller för webben på grund av att utrymmet är mycket mer begränsat och många användare läser mailen direkt i den förhandsvyn som finns främst i de plattformsbaserade klienterna. Layouter bör vara enkla och inte vara nästlade allt för djupt även om tabeller är vad som rekommenderas för positionering och skapandet av kolumner. Även om användandet av ”DIV”-taggar och CSS är det enda vettiga alternativet för utveckling på webben fungerar det enligt guiden inte i email. Man bör se upp så att det inte blir alltför många rader och kolumner i tabellerna dock. Vad man bör tänka på när det gäller tabeller är attributet ”colspan” som tillåter celler att löpa över en eller flera tabeller, risken finns att detta ignoreras i klienten. Så istället för att nästla tabeller och överanvända ”colspan” kan det vara läge att använda fler tabeller istället. Man kan som exempel använda separata tabeller för headern, huvudinnehållet och footern.

Nästa del med rekommendationer gäller de klienter som är webbaserade, alltså Gmail, Hotmail och Yahoo. Först och främst lyfter man fram det faktum att ”HTML”,

”HEAD” och ”BODY”-taggarna kommer att skalas bort från dina email för att förhindra att det du angett kommer i konflikt med de deklarationer som finns för webbläsaren och klienten. Det betyder, precis som fanns att läsa i CMs artikel, att ingen bakgrundsfärg som är deklarerad i ”BODY”-taggen kommer att synas.

Lösningen är en tabell som täcker hela dokumentet och att man sedan sätter en bakgrundsfärg på detta element.

5.1.3.2 CSS rekommendationer

Att ”HTML”, ”HEAD” och ”BODY”-taggarna skalas bort betyder även att om man vill länka in CSS eller ha den inbäddad kommer detta skalas bort om det ligger i

”HEAD”-taggen och bör därför placeras precis nedanför ”BODY”-deklarationen, strax ovanför den ordinarie HTML-koden. Man nämner även i det här avsnittet att i vissa klienter skalas den inbäddade CSS:en bort, troligen av samma orsak som ovanstående taggar; för att det inte ska komma i konflikt med CSS:en för klienten.

Även om inbäddad CSS skalas bort och det inte finns stöd för positionering med CSS rekommenderas användandet för formateringen av exempelvis text och färger.

Dokumentet bör rent strukturmässigt byggas så att det ”misslyckas med stil”, skulle CSS:en av någon anledning inte nå fram ska mailet gå att läsa och se acceptabelt ut.

Detta kan endast försäkras genom att man faktiskt testar.

5.1.3.3 Bild- och övriga grafiska rekommendationer

Rekommendationer gällande bilder är att dessa bör förvaras på en server och länkas in via den absoluta sökvägen jämfört med att bifoga bildfiler i mailet. Att bifoga dem skulle dels öka storleken radikalt samtidigt som det skulle kunna bli svårigheter med placering och formatering av dessa filer.

Även om det är lockande avråder Mail Chimp slutligen från att använda tekniker som Flash, Javascript och ActiveX eftersom det finns ytterst lite stöd för dessa i

mailklienterna vilket gör användandet meningslöst.

5.2 Tester

De 11 test- och exempelmailen är i mångt och mycket väldigt lika i sin utformning, de innehåller samma typ av element och egenskaper för att testa de mest grundläggande funktionerna med inspiration från den existerande tjänsten. De testar även olika tekniker och kombinationer av HTML och CSS för layout och positionering.

Den HTML som testats är:

 DIV

 H1-H6

 IMG

 OL/LI

 P

 SPAN

 TABLE

 UL/LI

Den CSS som testats är:

 Background-color

 Color

 Float

 Font-family

 Font-size

 Margin

 Padding

 Text-align

Del ett av testmailet som illustreras i bild 5.2.1 innehåller och testar de olika typerna av rubriker som finns, rubrikerna har ändrad färg (lila eller orange) och är placerade antingen oförändrat till vänster eller till höger i mailet.

Därefter testas paragrafer och stycken. Första stycket är en ”SPAN”-tagg som är turkos och i teckensnittet ”Arial”. Nästa stycke är en ”P”-tagg som är centrerad, brun och i teckensnittet ”Courier”. Det sista stycket är en ”DIV”-tagg som är placerad till höger, är röd och i ”Tahoma”.

Bild 5.2.1 Önskat resultat, del ett.

Del två som illustreras i och med bild 5.2.2 testar positionering av bilder. Tanken är att en bild ska placeras ”flytande” vid sidan om ett textstycke. I det här fallet testas två olika varianter, det övre stycket är placerat i en ”P”-tagg och det nedre i en ”SPAN”- tagg. Teckensnittet är satt till ”Verdana” för båda dessa block.

Nedanför dessa bildblock finns en tabell. Tanken med denna tabell är att testa huruvida detta alternativ fungerar för att skapa till exempel kolumner. Tabellen har

även placerats centrerat för att testa positionering. Tecktensnittet i tabellen är ”Times New Roman”.

Bild 5.2.2 Önskat resultat, del två.

Del tre, även bild 5.2.3, innehåller sex olika block med listelement. Placering av dessa element har testats genom att placera dem till vänster (standard), i mitten och till höger.

Längst ner finns en paragraf som talar om vem som utformat mailet samt en länk med ändrad färg för att testa stödet för detta.

Bild 5.2.3 Önskat resultat, del tre.

Innan genomgången av testmailen påbörjas finns det ytterligare en sak att nämna angående den webbaserade emailklienten Outlook Web Access. Den finns i två utföranden: Den ser ut och fungerar på ett sätt i Internet Explorer och vitt skilt från detta i de flesta andra webbläsarna. Resultaten grupperas därför efter dessa två kategorier.

Nedan följer således en presentation av testmailen var för sig, presentationen innehåller en sammanfattning av vad de ämnade testa samt vad de gav för utslag och resultat.

5.2.1 Testmail 1

Testmail 1 är utformat med hjälp av en standard ”DIV”-layout som vanligtvis används vid utveckling för webben, detta i kombination med CSS som flyttats inline och alltså ligger direkt på elementen efter rekommendationerna från både Campaign Monitor och Mail Chimp. För centrering av den yttre ”DIV”-taggen används CSS-egenskapen

”margin” som är satt till ”auto”.

Ett första gemensamt problem som dyker upp är att de ”P”- och ”SPAN”-taggar som innehåller bilder i kombination med text verkar endast vara anpassade efter textens omfattning. Detta skapar problem eftersom bilderna då ”inkräktar” på elementen som ligger nedanför. Problemet illustreras med bild 5.2.1.1.

Bild 5.2.1.1 ”P”- och ”SPAN”-taggarna i Gmail, Firefox

Ett annat generellt problem rör webbläsarna Chrome, Safari och Apples mailklient Mail som inte tolkar positioneringen av listelement riktigt som förväntat. Texten blir centrerad men den (i de här fallen) punkt eller siffra som definierar listan följer inte med som visas i bild 5.2.1.2.

Bild 5.2.1.2 Positionering av listelement i Gmail, Google Chrome

5.2.1.1 Resultat testmail 1

Nedan följer en presentation av resultatet i de olika emailklienterna och webbläsarna.

Om inget annat anges såg resultatet ut som förväntat med undantag för bildblocken och listelementen. Det som kommenteras är i första hand hur klienten hanterar

”margin” och andra CSS-egenskaper.

Apple Mail

”Margin” för positionering fungerar utmärkt. Teckensnitt och färger på textelement okej, Verdana något bold. I och med att den nedre bilden flyter över gränsen för

”SPAN”-taggen påverkar detta tabellen och den flyter upp och lägger sig ovanför bilden.

Bild 5.2.1.3 Apple Mail, testmail 1

Outlook 2007

Kan inte hantera “margin”-, ”padding”- “width”- eller “float”-egenskaperna, vilket stämmer överens med Email Standards Projects slutsatser. Mailet täcker därmed hela ytan vilket i det här fallet inte ställer till några visuella problem annat än att den grå bakgrunden faller bort. I och med att ”float” saknas är båda bilderna placerade till vänster och texten börjar i dess nedre kanter, elementen är anpassade efter dess totala storlek. Formateringar vad gäller texter och länkar ser mycket bra ut.

Bild 5.2.1.4 Outlook 2007, testmail 1

Outlook Express

Mycket bra resultat. Texten fyller i det närmsta upp samma område som bilden i bägge bildblocken och ger därmed ett mycket bra resultat. Utöver detta tolkas även

anvisningar för postionering och dessutom ser alla textangivelser ut som förväntat, både vad gäller form och färg.

Thunderbird

Godkänt på samtliga punkter. Även tolkningen av bildblocken är väldigt nära förväntat resultat. All positionering och text-/länkformatering ser ut som förväntat.

Windows Live Mail

Även här mycket bra resultat. Endast de ”HR”-taggar som skiljer elementen åt drabbas och suddas ut på grund av bilderna men ingen del flyter över och skapar ett alltigenom negativt resultat. All positionering och text-/länkformatering ser även ut som

förväntat.

Gmail – samtliga browsers

Okej med ”margin” för positionering. Saknar ”Times New Roman” på tabellen, övriga teckensnitt helt okej. All positionering av text med hjälp av ”text-align” är okej. Bra padding på styckeselementen.

Bild 5.2.1.5 Gmail/Firefox, testmail 1 Hotmail – samtliga browsers

Kan inte hantera ”margin” för positionering. Tabellen har om inte ”Times New Roman” åtminstone serif-teckensnitt, övriga teckensnitt är också okej. Bra padding på styckeselementen och länken längst ner har önskad färg. Att bilden flyter över i bildblocken påverkar dessvärre även nedan liggande tabell i Hotmail. Att den inte är centrerad beror på att det beordras med hjälp av ”margin” men texten i tabellen får konstig padding i överkant.

Bild 5.2.1.6 Hotmail/Firefox, testmail 1 Outlook Webaccess

- Internet Explorer

Kan inte hantera ”margin” för positionering. I övrigt är tolkning av positioneringar och teckenformateringar mycket bra, så även färgsättningar. Det översta bildstycket ser helt okej ut och flyter inte över alls medan den nedre bilden endast flyter över ett par pixlar.

- Övriga browsers

I övriga webbläsare fungerar det med ”margin” för positionering. Något som däremot ställer till det utöver vad som nämnts tidigare och som ger en mycket negativ

upplevelse är den minimala teckenstorleken som ger ett helt oväntat resultat.

Teckensnitten och färgsättningar är däremot korrekt tolkade. H1-taggar kan däremot inte heller hanteras och tolkas.

Bild 5.2.1.7 Outlook Web Access/Firefox, testmail 1

Yahoo – samtliga browsers

”Margin”- positionering okej. Teckensnittet i tabellen är inte ”Times New Roman”, övriga teckensnitt är godkända och så även färgsättning. All positionering av text med hjälp av ”text-align” är okej. Tunt med padding på styckeselementen, enligt artiklarna från Campaign Monitor och Mail Chimp. I webbläsaren Safari när den nedre bilden flyter över lägger sig tabellen ovanför denna.

Bild 5.2.1.8 Yahoo/Firefox, testmail 1

Bild 5.2.1.9 Yahoo/Safari, testmail 1

Email Standards Projects resultat stämmer med andra ord ganska bra överens med de resultat som framkommit genom testerna med undantag för Gmail som faktiskt stödjer, åtminstone, de egenskaper som testats här.

5.2.2 Testmail 2

Testmail 2 är utformat i stort sett likadant som testmail 1. Basen är fortfarande en

”DIV”-baserad layout, ”margin: auto;” används för centrering av element och ”text- align” för positionering av text. Eftersom problemet med ”P”- och ”SPAN”-taggarna för bilder verkar vara beroende av textens storlek och omfattning har

standardstorleken för text satts till 17px. En annan viktig skillnad från testmail 1 är att all CSS har flyttats från elementen och anropas istället inbäddat i en ”STYLE”-tagg strax under ”BODY”-taggen med hjälp av klasser, id och elementnamn enligt rekommendationer från Email Standards Project. Själva testmomentet består alltså främst i hur emailklienterna hanterar inbäddad CSS.

5.2.2.1 Resultat testmail 2

Resultatet av detta test är mycket gott och det finns endast två undantag;

Gmail skalar bort all inbäddad CSS:

Bild 5.2.2.1 Gmail/Firefox, testmail 2

Detta är även svaret på varför Gmail fått genomgående nedslag i Email Standard Projects tester som alltså bygger på inbäddad CSS.

Outlook Web Access (ej Internet Explorer) tolkar inte önskad generell textstorlek (17px) som angetts på ”BODY”-elementet. All övrig CSS fungerar dock som tänkt vilket skulle kunna betyda att just ”BODY”-taggen skalas bort för att undvika konflikter med webbläsarens direktiv enligt artiklarna från både Campaign Monitor och Mail Chimp. I Internet Explorer finns inte detta problem.

5.2.3 Testmail 3

Testmail 3 är utformat för att testa huruvida emailklienterna kan hantera inlänkad CSS.

Strukturen är alltså densamme som för testmail 2 men all CSS har lyfts ut och placerats i ett separat dokument som sedan länkats in i HTML-dokumentet via en absolut sökväg.

Bild 5.2.2.2 Firefox Bild 5.2.2.3 Internet Explorer

5.2.3.1 Resultat testmail 3

Resultaten kan delas in i två grupper: De med stöd för inlänkad CSS och de som saknar stöd.

Stöd för inlänkad CSS:

 Apple Mail

 Outlook Express

 Thunderbird

 Windows Live Mail Saknat stöd för inlänkad CSS:

 Gmail

 Hotmail

 Outlook 2007

 Outlook Web Access

 Yahoo

5.2.4 Exempelmail 1

Efter dessa tre testmail kändes det som att en relativt klar bild över koden började växa fram och ett exempelmail utformades. Ett försök att komma till rätta med de felformaterade taggarna för bilder sattes en fast storlek på texten inbäddat på

”BODY”-taggen, bilderna sattes även till fasta storlekar med hjälp av HTML- attributen ”width” och ”height”. ”Margin” har helt och hållet bytts ut mot HTML- attributet ”align” för att tillgodo se de klienter som inte stödjer detta.

Vad som föll i glömska var dock att varken Gmail eller Outlook Web Access tolkar inbäddad CSS och resultatet blev återigen misslyckat. Placeras önskad textstorlek däremot även på textelementen direkt försvinner detta problem och mailet ger önskat resultat vad gäller dessa bildblock.

5.2.5 Exempelmail 1.1

Även om konstruktionen för bildblocken fungerar och i fallet med exempelmail 1, efter en del justeringar, ger önskat resultat känns metoden ostadig och opålitlig. Det känns inte hållbart att låta bilden och texten vara beroende av varandra storleksmässigt

och det går inte heller att lita på att användaren förstår problematiken och anpassar texter efter bilden, eller tvärtom. En ny strategi arbetades därför fram – bilder av denna typ, som flyter bredvid en text, placeras inom en tabell med två celler. Texten placeras i en cell och bilden i en egen. Denna lösning fungerar som tänkt i samtliga emailklienter.

Bild 5.2.5.1 Gmail, Outlook Web Access och Yahoo

5.2.5.1 Problem exempelmail 1.1

Något som framgår tydligt i och med detta testmail är att då CSS-egenskapen ”margin”

bytts ut mot HTML-attributet ”align” misslyckas det i Yahoo vad gäller tabeller. Allra tydligast blir det på tabellen med textinnehåll som inte tar upp hela ytan.

Bild 5.2.5.2 Yahoo/Firefox, exempelmail 1.1

Outlook 2007 ställer däremot till med andra problem. Området bakom tabell- och listelement saknar den vita bakgrundsfärgen och den grå bakgrunden lyser igenom.

Detta har förmodligen att göra med att en extra ”DIV”-tagg har tillkommit, det finns nu alltså två ”DIV”-taggar, en för att sätta den yttre bakgrundsfärgen till grå och en som fungerar som behållare till mailet och någonstans tolkar Outlook 2007 detta på felaktigt sätt.

Bild 5.2.5.3 Outlook 2007, exempelmail 1.1

5.2.6 Testmail 4

Efter flertalet försök att hitta lösningar för de problem som framkom i och med exempelmail 1.1 genom att ändra små detaljer fick återigen en ny strategi arbetas fram

för att täcka de luckor som uppkommit. För att kunna särskilja problemen åt inriktas testmail 4 på att hitta en lösning som fungerar som tänkt även i Outlook 2007.

Eftersom både Campaign Monitor och Mail Chimp rekommenderar att man använder tabeller för att bygga sina layouter blir detta nästa teststeg. En yttre ”DIV”-tagg ligger kvar även i detta mail för att sköta bakgrundsfärgen då ”BODY” skalas bort men behållaren för själva mailet har bytts ut mot en tabell som har en rad och en cell där all övrig kod placeras.

Denna ändring löser det aktuella problemet och samtliga emailklienter visar upp önskat resultat.

5.2.7 Testmail 4.1

Detta testmail är således mer inriktat på att hitta en lösning för problemet i Yahoo och det faktum att ”align”-attributet inte fungerar fullt ut vad gäller tabeller.

Idéen till detta testmail kom i samband med att den yttre ”DIV”-taggen i till exempel exempelmail 1 och 1.1 placeras centrerat med hjälp av ”align” vilket fungerar utmärkt, även i Yahoo. Tabellen i fråga kapslas därför in i en ”DIV”-tagg som sätts till

”align=center”, ”align”-attributet tas därmed bort från tabellen helt men ersätts med CSS-egenskapen ”text-align” som talar om att texten i tabellen ska hållas till vänster eftersom den annars hade ärvt den centrerade positionen.

Detta löser problemet och mailet ser med andra ord ut helt som man tänkt sig.

5.2.8 Testmail 5 – 5.1

Syftet med testmail 5 är att arbeta fram en lösning för hur koden skulle kunna se ut senare i själva tjänsten. Tabeller kommer att kapslas in i en ”DIV”-tagg för att positionering ska kunna hanteras på bästa sätt och en tanke är att mailet ska delas in i olika block som alla är inkapslade i en ”DIV”-tagg.

5.2.8.1 Blockindelning enligt testmail 5

Bild 5.2.8.1 Block 1

Bild 5.2.8.2 Block 2-3

Bild 5.2.8.3 Block 4

Bild 5.2.8.3 Block 5

Bild 5.2.8.4 Block 6-11

Bild 5.2.8.5 Block 12

I testmail 5 är positioneringen delad mellan ”align”-attributet och CSS-egenskapen

”text-align”, i testmail 5.1 däremot är det enhetligt utformat så att de ”DIV”-taggar som fungerar som blockbehållare positioneras med hjälp av ”align” medan texten inuti dessa positioneras med hjälp av ”text-align”. Ett exempel är, som nämnts tidigare,

texttabellen i block fem som ligger centrerad i mailet medan texten fortfarande ska hållas i vänsterkanten.

5.2.9 Testmail 6

Det avslutande testmailet är ämnat testa om emailklienterna tolkar bakgrundsfärgen från ”BODY”- eller den heltäckande ”DIV”-taggen.

Det är mycket enkelt utformat och innehåller endast den omslutande ”BODY”- taggen, en yttre ”DIV” som dragits in ett par pixlar för att kunna skilja på dem, en tabell som fungerar som behållare som i sin tur innehåller en ”DIV”-tagg som presenterar innehållet i mailet.

Bild 5.2.9.1 Återkonstruktion av testmail 6

Dessa resultat kan delas in i tre kategorier: De som kan tolka båda bakgrundsfärgerna, de som endast tolkar bakgrundsfärgen från ”BODY” och de som endast kan tolka bakgrundsfärgen från ”DIV”.

BODY:

 Outlook 2007 BÅDA:

 Apple Mail

 Outlook Express

 Thunderbird

 Outlook Web Access

 Windows Live Mail DIV:

 Gmail

 Hotmail

 Outlook Web Access

 Yahoo

5.2.10 Exempelmail 2

Det sista mailet som utformades var ett exempelmail med anknytning till hur framtida användare kan komma att vilja använda tjänsten.

Precis som testmail 5 är det uppbyggt i block; en header som innehåller en topbild, tre block med bilder och flytande text och en footer med en bottenbild som avslutar mailet.

Bild 5.2.10.1 Exempelmail 2

Bilderna ligger i varsin tabell och visar även på hur texten kan placeras i förhållande till tabellens övre och nedre kanter samt centrerat.

Resultatet ser ut som förväntat i samtliga emailklienter.

6. Diskussion

Detta kapitel är ett försök att återknyta resultaten till de frågeställningar som finns specificerade under måldelen; tankar om avsaknaden av standarder, hur de rekommendationer som testats bedöms samt ett förslag på en praktisk lösning.

6.1.1 Återkoppling till frågeställningar

 Finns det någon gemensam standard för HTML och CSS i email?

o Vilka rekommendationer finns det?

Att det saknas specifika standarder för email känns ganska förvånande då email trots allt är en betydande och stor del av internet i allmänhet. Som nämndes i

metoddiskussionen var det en oväntad vändning när ”mer betrodda” resultat saknades, det kändes som en självklarhet att det faktiskt skulle finnas resultat (vetenskapliga artiklar och litteratur) att ta del av! Detta var inget som hade kunnat förutses men absolut en risk som hade behövts räknas in i arbetet.

I början av testandet kändes det ganska ljust och faktiskt möjligt att använda sig av webbstandarder då den standardiserade ”DIV”-layouten såg ut som förväntat i 8 av 9 emailklienter, men man ska alltså inte ta ut någonting i förskott!

Det hade varit bekvämt att kunna dra slutsatsen att de plattformsbaserade klienterna får så bra resultat eftersom de har andra förutsättningar och har större möjligheter att faktiskt göra som de blir tillsagda medan de webbaserade klienterna jobbar i

uppförsbacke och måste tolka resultaten med hänsyn till de specifikationer som finns för vald webbläsare. Så är det säkert också till en viss grad men i och med Email Standards Projects undersökningar bevisar Yahoo att det faktiskt går att utveckla en webbaserad klient med full gott stöd samtidigt som Outlook 2007 visar på någon slags motsats, vilket är oerhört intressant.

2007-2008 kan ses som något av en ”storhetstid” för diskussionen gällande standarder för email, många av de artiklar som jag stött på i arbetet är skrivna under dessa år och även Email Standards Project startades under denna period – allt tack vare Outlook 2007. Det är svårt att låta bli att undra varför de ändrade sin renderingsmotor från Internet Explorer, som uppenbarligen fungerade, till Word vilket är detsamma som att ta ett stort steg tillbaka. Det räcker med att jämföra Outlook Express som får goda resultat i testerna jämfört med Outlook 2007 som skapar problem. Express varianten

är dessutom en tidigare gratisversion och 2007:an måste köpas i ett större Office- paket.

Tack vare eldsjälar och organisationer som främst Email Standards Project och Campaign Monitor förs dialogen dock vidare och rekommendationer för hur man skulle kunna utforma email även idag finns det gott om.

 Fungerar dessa standarder eller rekommendationer som förväntat i emailklienterna?

Jag skulle vilja sammanfatta resultaten av test- och exempelmailen med att de rekommendationer som jag valt att använda mig av absolut går att använda och är pålitliga. Ett undantag som finns är ju dock de resultat som Gmail får i Email

Standards Projects undersökningar, resultaten stämmer förvisso eftersom klienten inte hanterar inbäddad CSS men i övrigt hanterar de allra flesta egenskaper alldeles

utmärkt. Syftet med projektet är ju dock i första hand att föra en dialog och påpeka klienternas brister och med det i åtanke känns det lättare att acceptera resultatet och sågningen.

Något som också bör vägas in vid bedömning av resultatet är den avgränsning som gjorts vad gäller testandet. Redan i början av arbetet specificerades vilka emailklienter som arbetet skulle rikta in sig på, vissa versioner och klienter har därmed medvetet utelämnats. Vid intresse är detta absolut något som rekommenderas som framtida utveckling, jag ser gärna att även en undersökning görs specifikt för mobila enheter.

Det förslag jag tagit fram utifrån resultaten från test- och exempelmailen är inte en ren

”DIV”-layout eftersom detta bevisligen inte fungerar men inte heller en helt tabellbaserad variant. I ett vanligt emaildokument skulle flera olika tabeller behöva användas och nästlas med rader och celler åt alla håll och det skulle inte bli någon rolig kod att arbeta med om man manuellt måste gå in och göra någon ändring, till exempel.

Dokumenten skulle även bli oerhört tunga och stora med både massiva

tabellkonstruktioner och inline CSS. Enligt gällande webbstandarder är det dessutom okej att placera till exempel en ”DIV”-tagg inom en tabellcell vilket gör att mitt förslag även känns berättigat.

6.1.1.1 Praktisk lösning

 Hur skulle detta kunna användas rent praktiskt?

I samband med testmail 5 och exempelmail 2 började en bild av ett rent praktiskt användande av koden växa fram. I en annan applikation än HEJO MAIL som man utvecklat på HEJO Interactive använder man sig av en funktion med modultänk, det vill säga man bygger i det fallet en nyhetssida med hjälp av olika block som sedan kan flyttas upp eller ner beroende på önskemål. Detta var något jag fastnade för och såg potentiell användning i. Funktionen skulle givetvis kräva en del omstrukturering men jag ser ändå viss återanvändning vilket skulle spara tid och energi för framtida utvecklare.

Tanken är alltså att man med hjälp av olika ”DIV”-taggar skapar olika block i sitt emaildokument. Användaren kan givetvis själv välja hur stort ett block ska vara och måhända endast skapa bara ett block för hela sitt dokument men jag tror ändå att det kommer underlätta utformningen och framförallt hantering och placering av bilder.

Ett förslag är att man skulle kunna behöva välja mellan text- och bildblock.

Väljer man ett textblock måste man specificera ett teckensnitt, placering av både blocket och texten (vänster, mitten eller höger) och även en textstorlek som sedan alltså kommer gälla för hela det blocket. När man gjort dessa val får man upp en dialogruta där man kan klistra in sin text och därefter ska det kunna vara möjligt att fetlägga enstaka ord eller färglägga enstaka ord eller meningar. Detta görs rent tekniskt med hjälp av ”SPAN”-taggar och inline CSS. I textblocken ska man även kunna infoga rubriker och länkar. Föråldrade taggar, såsom ”FONT”- eller ”STRONG”-taggar, bör undvikas för att eftersträva god webbstandard och eftersom det enligt testerna är möjligt att använda CSS för samma effekt.

Funktionen för att infoga bilder är inaktiverad vid val av textblock och textinmatning eftersom särskilda val kommer behöva göras för dessa block. Som ett första steg måste man bestämma om man vill ha en fristående bild eller om man vill ha text flytande omkring den. Vid val av fristående bild kommer blocket således endast bestå av en

”DIV”-tagg innehållandes en enda ”IMG”-tagg. Attributen ”width” och ”height” bör anges för bilden eftersom detta ger ett säkrare resultat, är användaren inte så insatt skulle det kunna finnas ett val för att använda bildens originalstorlek till exempel. Även

”alt”-attributet bör vara obligatoriskt för att öka tillgängligheten för bilden.

Vid val av bild med flytande text föreslår jag i första hand två alternativ vad gäller placering; höger eller vänster, eftersom detta kommer att göras med hjälp av en tvåcellig tabell. När valet av placering är gjort får användaren infoga sin bild som därefter placeras i cell efter användarens val och texten får sedan klistras in via

ytterligare en dialogruta och placeras automatiskt i den lediga cellen för att underlätta för användaren och minska risken för att något blir fel.

Detta är i stora drag ett förslag på lösning för HEJO MAIL som jag spontant känner skulle kunna byggas stabil och enkel samtidigt som många detaljer jobbar med att försöka minimera risken att användaren gör något fel. En sådan här lösning är å andra sidan väldigt styrd och lämnar inte mycket utrymme för till exempel pixel-noggrannhet från användarens sida då allt är väldigt standardiserat och utstakat, jag tror dock som försvar att ju mer man styr användaren desto större chans är det att utskicken får ett bra resultat när det till slut skickas ut till klienterna.

6.1.2 Framtida utveckling

Utöver en implementation av en lösning har jag förslag på två ytterligare punkter för framtida utveckling som dessvärre fallit utanför ramen för mitt examensarbete. Den ena punkten rör när text klistras in från en ordbehandlare, Microsoft Word till exempel. Word skickar då med enorma mängder kod för sin egen formatering, denna kod syns i nuläget inte i editorns designläge men finns med under HTML-läget. Det vore inte underligt om denna kod i sin tur kommer i konflikt med de val som sedan görs vad gäller teckensnitt och storlekar i editorn. Detta är ett viktigt problem som absolut måste upplysas om eftersom en stor del användare föredrar att författa sina texter i en ordbehandlare på datorn där de kan känna sig bekväma, spara sina texter och få dem genomsökta efter stavfel.

Punkt två gäller användandet av RGB och hexadecimal färgsättning. Den nuvarande tjänsten använder en salig blandning av de båda. Personligen föredrar jag hexadecimala koder men jag har inga som helst belägg för att det skulle vara bättre varför jag

rekommenderar en undersökning av användandet; vad är det för skillnad och vilket rekommenderas?

Jag skulle slutligen vilja uppmuntra fler programmerare att lägga tid på research, prioritera undersökningar av vilka alternativ som finns för implementeringsspråk, databas eller vad det nu kan vara. Våga lämna gamla hjulspår och ge sig ut på upptäcktsfärder på det underbara Internet eller i litteraturens värld. 10 veckor av ett projekt må vara i grövsta laget men kanske kan det i slutändan löna sig att avsätta X antal veckor i halvåret för research och lägga kod knackningen på hyllan?

7. Källförteckning

7.1 Elektroniska källor

Campaign Monitor, [2010-05-19]

http://www.campaignmonitor.com/

Campaign Monitor, Email Design Guidelines, [2010-05-19]

http://www.campaignmonitor.com/design-guidelines/

Email Standards Project, [2010-05-19]

http://www.email-standards.org/

Mail Chimp, Free Guide, [2010-05-19]

http://www.mailchimp.com/articles/email_marketing_guide/

W3Schools, Html, [2010-05-19]

http://w3schools.com/html/default.asp W3Schools, CSS, [2010-05-19]

http://w3schools.com/css/default.asp

351 95 Växjö / 391 82 Kalmar