11.03.13
Mobile Email
Best
Practice (ii)
A second look at web standards orientated approaches to engineering universal inbox nirvana …
A second look at web standards orientated approaches to engineering universal inbox nirvana …
Following on from the previous post - a look back to W3C web standards and some considerations that follow in the landscape of email…
"It is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations."W3 Web Standards
Obviously media queries would primarily be considered an advantage to help exploit mobile experience and offset limitations of screen area- but what kind of mail app is being used? Does it even support a responsive approach?
We might have an instance where stats indicated a high proportion of android users vs iphone, with likely a high proportion of those accessing the gmail app. Suddenly the 50% of opens we envision our content enhancements to be affecting becomes a much smaller proportion. As it is, consideration should always be given to any significant increase in download weight but all the more if it's 'dead weight' to many users. It doesn't have to be 'either or' in terms of scalability and responsive approaches.
A limitation could also arise in the form of flakey css support on a particular platform e.g. Android Gingerbread's failure to display background images. Definitely worth monitoring Android's developer blog for stats on Gingerbread usage but until it's significantly lower I'd be cautious of employing them.
Limitations can be assessed in context of the user scenario. Are they likely to be on public or home wifi, cellular 3G or 4G, dial-up, DSL/Cable modem or T1 line. The same content could take anything from a split second to half a minute to download.
There may be parameters that cannot be controlled like the effects of dreaded proxy server compression on images. It may be worth considering how a users expectation changes in different viewing environments or devices. A positive or negative experience is always in context to whatever is regarded as the 'acceptable norm'. If something does have to degrade in the chain it should ideally do so where there's already an expectation of diminished experience.
The success of video and animated gif in driving engagement shows even approaches with very inconsistent support can be worth their many caveats. In that way best practice can be used as a tool to gain more understanding and control over an email's deviating path between graceful degradation and progressive enhancement.
We can even consider 'device limitations' from an internal perspective too. In terms of the facility to test on a breadth of devices, device labs and/or Litmus testing. When fueling engagement it can often pay to be adventurous and push the boundaries but that may demand a certain level of resources to meet the aims and be most effective.
"Different screen sizes may demand different sized images. It is very common when delivering content to mobile devices to vary the details of the markup, format of images, image sizes, colour depths to suit the characteristics of the device in question." W3 Web Standards
Another advantage that exists which can become a deficit in practice. More on the pros and cons of these in this this article.
Responsive design in theory promises a wider reaching and superior experience for mobile users but in practice things may not be clear cut. If your 300 pixel wide image asset, particularly one with any kind of typography, stretches to fit one of the mid to larger retina screens - results may not always compare favourably to an adaptive or scalable solution. Since layout and content changes will be effected client side and without javascript to call on we can't just mimic the kind of approaches that may exists for our web assets.
Crowbarring in a little code tip, it's common practice to use attribute selectors to prevent your mobile layout rendering in unwanted places like yahoo mail.
td[class=italic] { font-style:italic !important;}
td[class=fuchsia] { color:fuchsia !important;}
However this format seems to prevent the possibility of combining classes for an element which can be a bit annoying.
EOA highlighted an alternative method used to give access to additional selector types and this format will also allow for classes to be used in combination:
body[yahoo] td.italic { font-style:italic !important;}
body[yahoo] td.fuchsia { color:fuchsia !important;}
So using the above format the two classes could now be combined in the usual way to apply the styles of italic and fuchsia…
<td class="fuchsia italic" style="font-family:Arial, serif; color:black; font-size:22px">"Fuchsia et Italica est meretricious at best</td>
A bit more semantics to the CSS but the option means you're less likely to end up with a lot of similar classes with multiple repeated attributes. It's also a useful way of preventing AOL reading your media queries in chrome.
"Because of the limitations in display and of input mechanisms, the possible absence of a pointing device and other constraints of mobile devices, care should be exercised in defining the structure and the navigation model of a Web site." W3 Web Standards
Increase point size of navigation text so more touch friendly
Reduce or reformat or even serve a separate nav tailored to mobile users. Consideration can also be applied to where the navigation appears for mobile in terms of the desired hierarchy presented to the user.
It may seem pointless to adjust your desktop/full width layout for mobile when you have media queries at your disposal but good scalable features are still valid for mail apps without media query support.
"The process of altering content to enhance the user experience on particular devices is referred to as Content Adaptation." W3 Web Standards
So the overarching ethos is adaptation and there are a range of approaches at our disposal for this which are pretty well documented:
One thing to emphasise might be to choose an approach that fits the aims and resource. That might not be the same for every campaign. Simple scalable solutions for one campaign, something responsive or adaptive for another.
The take away being - be adaptable in your approach to adaptation.