Managed hosting door True

Technologie

Nieuwsbrieven en de vooruitgang

 

Computable Expert

Jan van Leeuwen
IT Consultant, Stajl IT. Expert van Computable voor de topics Development en Internet.

Wanneer ik een website of webapplicatie maak, gebruik ik vandaag de dag natuurlijk  html5, css3 en php gecombineerd met javascript. Je let er op dat pagina's ten minste een flexibele breedte hebben of een vol responsive design zoals bootstrap van twitter (wat ik als een slecht design ervaar).

Ik had een klant die me vroeg om een nieuwsbriefsysteem voor verschillende groepen klanten te leveren met ongeveer tienduizend nieuwsbrief-abonnees. Voor zo iets gebruik ik graag phplist dat voldoende functionaliteit heeft om de klant tevreden te stellen. Dat combineer ik dan met zijn cms.

Als voorbeeld werd me een nieuwsbrief van een discounter getoond, zo ongeveer moest het er uit zien. Dus vlijtig aan de gang, iets breder als de 750 pixel van de discounter met een paar layers (z-index), achtergrondbeeldjes zodat het er goed uit zag. Testbericht van de webpagina uit phplist gestuurd, ziet er keurig uit in Thunderbird. Ter controle nog even de webpagina in Internet Explorer vanaf 8 tot 11, Firefox, Chrome en Opera getest, beetje aanpassen, en het is een keurig net resultaat.

Totdat ik mijn klant  een test-nieuwsbrief stuurde die hij met outlook bekeek. Van de Cascading Style Sheets (CSS) is de helft of meer niet gerenderd en ook de html klopt niet zoals het bedoeld was.

Nu is het alweer vier jaar geleden dat ik me intensief met nieuwsbrieven bezig gehouden heb, dus naar de zoekmachine en een paar begrippen samenbrengen.

Stomverbaasd!

Hoewel het web de afgelopen jaren grote stappen genomen heeft in de richting van 'rich content' bevinden zich mogelijkheden van enkele e-mailclients nog op de stand van 1998/1999 en dat van leveranciers als Microsoft (Outlook 2007 en Live Hotmail), Google (Gmail) en IBM (Lotus Notes 8).

Een beeld geeft waar je kunt zien hoe het met de ondersteuning van de W3C-stadaards door e-mail-clients gesteld is. Kort gezegd, slecht. Volgens emailclientmarketshare betreft dat een derde van de markt.

Hoe is de stand nu eigenlijk in technisch opzicht? Aangeraden wordt een maximale breedte van . . . . 600 Pixel! Dat is nog niet eens een derde van een hd-beeldscherm of de helft van een gangbare tablet. De layout moet gemaakt zijn met tabellen in tabellen in tabellen want heel veel CSS om beeld-elementen te positioneren werkt bij deze clients niet. Zo heeft men in 1999 websites gemaakt, in een tijd dat geen mens een full-hd-monitor of meer op zijn bureau had staan, 15-inch was de standaard en 1024 pixel breed was al veel.

Kun je dat dan niet oplossen met mediaqueries is de vraag die direct boven komt. Antwoord, nee, die worden ook niet ondersteund bij Outlook. Met al die tabellen wordt een nieuwsbrief ook onnodig groot. Recent heb ik een oude website omgebouwd en aan het eind bleef nog 5 procent van de code over terwijl de site er identiek uit zag.

Het is een bekend verschijnsel dat de markt zich conformeert aan de tekortkomingen van één product, maar dat duurt meestal geen vijftien jaar. Er is bijvoorbeeld al de twittergroep 'fixoutlook'.

Misschien kunnen de klanten van deze drie (ahum) 'technologie-bedrijven' hun sales eens wijzen op de tekortkoming en laten zien dat er veel vrije alternatieven zijn die al lang nieuwsbrieven correct kunnen weergeven, ook als ze 1000 pixel breed zijn.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5234137). © Jaarbeurs IT Media.

7,2


Lees meer over


Partnerinformatie
 

Reacties

Ja, lastig hé, die email clients! Met de laatste Outlooks is het er zelfs nog slechter op geworden. Microsoft gebruikt n.l. de routines uit Office(??!!) om HTML emails te tonen.

Het is nu dezelfde situatie als toen IE6-7 nog gangbare browsers waren. Er kon zó veel, maar... ohh, de pijn om het ook voor IE te doen.

Anyway... Eén trend neem je helemaal niet mee. E-mail op mobiel is nu wel een dingetje. En ook je nieuwsbrieven moeten daarop. Smal is daar wel goed voor. Mobiele clients zijn over het algemeen beter in het weergeven van Nieuwsbrieven dan Outlook.

Mogelijke route is ook nog om van openers bij te houden welke clients ze gebruiken en als je weet dat iemand over het algemeen een capabele client gebruikt, dat e-mailadres een modernere versie te sturen. Maar heb je wel opeens meerdere templates om bij te houden.

Succes!

@Marijn
Mobiel is niet het probleem, dat werkt met zulke smalle layouts zonder extra werk.
Voor een bedrijf is dit een grote ellende, een nieuwsbrief zou toch een simpele aangelegenheid moeten zijn, het is mij een raadsel waarom MS/Google/IBM daar niets aan doen, ze sturen zelf toch ook nieuwsbrieven.

MS/Google/IBM doen om verschillende redenen niets aan dit punt.

Microsoft is vooral bezig met de "eigen standaard" te verbeteren. Zoals je weet laten zij zich niet veel gelegen liggen aan standaarden.

De prioriteiten van Google liggen veel meer op het gebied van dataverzamelen en GMail is daar slechts een middel toe.

De focus van IBM licht allang niet meer op Lotus Notes. Zij zijn vooral bezig met het leveren van Services.

Dat is natuurlijk allemaal jammer want zo worden partijen die wel aan dit soort ontwikkelingen werken in de kou gezet. Het is ook jammer voor jou, je wil mooie nieuwsbrieven maken maar kan die niet kwijt omdat de meest gangbare clients ze niet ondersteunen.

Jan, haha, ik herken je probleem. Ik heb systemen gebouwd voor het versturen van nieuwsbrieven.

Nieuwsbrieven versturen is permissie marketing. De gebruiker geeft aan deze te willen ontvangen. De businesscase om al je nieuwsbrieven zo te maken dat ze er altijd goed uit zien is best lastig, daarom zie je in veel nieuwsbrieven op de eerste regel "Ziet uw email er niet goed uit, klik dan hier voor de webversie". Ook kun je de optie geven aan de lezer om bijvoorbeeld de tekst versie te krijgen met platte links.

Alles perfect maken in alle omstandigheden is erg duur.

Zorg er sowieso voor dat je weet wie je lezers zijn en hoe je het ze het best kunt benaderen. Als links geklikt worden in de nieuwsbrief, maar je neemt niet waar dat ze geopend zijn, dan is dat een sterke indicator dat de gebruiker geen plaatjes laad en de nieuwsbrief er per definitie daar niet goed uitziet, en zo kun je dingen pro-actief verbeteren.

Voor deze keer ben ik het in grote lijnen met Henri eens, het gaat in de eerste plaats om toestemming en pas in de tweede plaats om de vorm. Iemand die zich hier altijd als een fel voorstander van privacy toont is behoorlijk opportunistisch door zich nu druk te maken om verschijningsvorm van de boodschap. En dus vraag ik me nu af wie Jan is op de foto, Pavlov hondje links of privacy-evangelist rechts?

Nu zal deze reactie me wel weer de gbruikelijke gele ster opleveren van opportunistische Pavlov hondjes omdat meestal niet verder gelezen wordt dan eerste regels van gedicht van Rudyard Kipling over 'six honest servingmen' terwijl boodschap daarvan juist in laatste deel zit:

"She sends'em abroad on her own affairs,
From the second she opens her eyes—
One million Hows, two million Wheres,
And seven million Whys!"

Doel van als nieuwsbrieven vermomde marketing gaat om de profiling, het opschonen van code aan voorkant versus business regels aan achterkant met CRM systemen is de hond commanderen maar zelf dom blijven blaffen. Vergeet niet dat nieuwsbrieven een vorm van correspondentie zijn waaraan klanten rechten kunnen verlenen, het beloven van misleidende winkansen breekt nationale loterij nu behoorlijk op.

Om even e.e.a. duidelijk te maken, het gaat hier om een groothandel die zijn zakenpartners wil informeren. Daar is de discussie over privacy niet aan de orde omdat er al een zakelijke verbinding is tussen verzender en ontvanger.

Daarom beschouw ik de reaktie van Ewout maar als een geconditioneerde reflex.

Punt is dat HTML in email al een tijd lang gebruikelijk is maar dat MS, Google en IBM dat na 15 jaar klaarblijkelijk nog niet mee gekregen hebben.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×