27.02.13
Mobile Email
Best
Practice (i)
A refresher on some of the techniques and approaches available from an angle of web standards …
A refresher on some of the techniques and approaches available from an angle of web standards …
I was asked by a client recently "What is best practice for an email on mobile?" While many ESPs offer practical guidelines, I wanted to take the opportunity to refer back to web standards for a refresher and some context.
It's a subtle distinction but the idea being to start from the perspective of fundamental principals that seek to improve experience, rather than just reeling off the latest approaches and aphorisms doing the rounds, and to an extent working backwards.
The Email Standards Project was launched on 2007, though I haven't registered much activity of late. Possibly following the launch of Outlook 2013 there was mass seppuku by all involved.
Reference to email standards on W3C reads more as a plea for action for email-client developers to support web standards than a comprehensive guide
To an extent mobile web standards can be extrapolated to the context of email. The main caveat being email clients don't support web standards so we're forced contextualise to the restrictions of clients, browsers and mail apps. In turn we can look at the subscriber base, user stats and target audience, and decide where the priorities for the campaign lie…
For a business to be spurred into reflecting on these things is ultimately beneficial and likely to yield better results than the mindset of just jumping on the must-have upgrade or feature du jour.
Below are a few parameters plucked from the W3C web standards page and some considerations that follow on from them. A lot of the ideas overlap and some are already well covered so I've kept it brief in places
One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. W3 Web Standards
'One Web' is a phrase that gives off a mawkish cheesy wiff of coca cola style sloganeering but it's essentially just promoting the idea of enabling the best possible experience to everyone in a practical way.
A few familiar design approaches that sit under the 'One Web' umbrella:
Create for the lowest common denominator and spec i.e. the "Default Delivery Context". Enhance the experience to "Exploit Device Capabilities" where feasible.
Build for the highest spec/best case scenario, then add fixes to accommodate devices lower down the chain. Often an appropriate choice where an existing product or format needs to be maintained.
What also follows is you need to be aware if the handlers or enhancements being implemented have adverse affects elsewhere in the chain e.g. Are your media queries written to prevent them rendering the mobile layout in some webmail clients.
With email it's not always clear cut what the highest and lowest spec scenarios are. Desktop will have much greater screen real estate to play with while mobile will often offer much more css support.
It can be helpful to establish some precedence in terms of connecting with and enhancing experience for core customers and their technology vs the compromises required to reach further and further outlier clients. Simple things like ranking email clients, devices, customer profiles, even user case scenarios in order of priority can help to inform the logistics of what is eventually built.
Extra material contributes to poor usability and may add considerably to the cost of the retrieval. W3 Web Standards
Reducing content and file size with...
Appropriate use of gif, jpg and even png. Also, the whys and wherefores of using @1.5 or @2x (high res) assets.
Beyond 'save for web' exploring avenues like Jpeg Mini, Image Optim, RIOT. Even high res images can be heavily compressed - but there are pros and cons.
There's generally more than one way to bake an email cake. e.g.
Sometimes using multiple nested tables or rows for text blocks is the
only way to get consistency for paragraphing and stylings but once in a
while you can get away with employing <br/> and <span> tags
to ditch a few kb.
Code compressors can be useful to crush down a few kb. Of course, if it's a template that will see regular
use it can be lean but a bit of readable 'paragraphing' and
the occasional <!-- comment --> may be worth retaining.
Probably the most obvious and possibly most ignored. Less is very often more, especially where screen real estate and attention span are at a premium.
Cutting image download weight and improving accessibility where appropriate e.g. Ideally we're employing html text/system fonts for our body copy but even in cases where some text is rendered as image there's still scope to use html for certain visual elements and to create spacing and background colours - slicing headers and banners without masses of redundant white space.
Most techniques employed to hide content from mobile viewers (the reliable ones so far as I can ascertain anyway) will not prevent that content from being downloaded so be prepared to consider compromises that cater for an expanding audience on handheld devices.
Even if you're not reducing download weight by suppressing certain content where possible - there's still a value to streamlining the user's path...
Mobile users typically have different interests to users of fixed or desktop devices. Equally, mobile users are typically less interested in lengthy documents or in browsing… Some services and information are more suitable for and targeted at particular user contexts. W3 Web Standards
Designing with scalability in mind or employing media queries to adapt the layout. Ideally a bit of both.
Where there's media query support:
We might automatically regard mobile as the lesser sibling of desktop but with the restrictions of desktop & webmail defining the 'Default Delivery Context' is not so straightforward…TBC