Emoji in Gmail inbox preview snippet

I got an email from Google+ yesterday and saw some odd characters in the preview snippet.

gplusss32

The “inbox preview snippet” (or  “inbox snippet preview” or “preview snippet” or “snippet preview” or “snippet” etc.) is where your email client grabs a line or two of the copy from the email and pops it after or beneath the subject line in the inbox.

I had a quick look through the code to see if anything shouted at me but didn’t get anywhere, so after a full minute of looking I turned to twitter with a screenshot.

Within 30 seconds I had a reply! “Yay!” I thought, but it was James Dempster from Cobb Digital with a joke … he is funny though.

A few minutes later I was replied to by the legend of Mark Robbins telling me it was emoji!

I returned to the message and looked deeper. I found that what I had thought was two images, badly aligned, either side of a title, was actually two shooting star emoji characters.
So when Gmail grabbed the copy from the message, it had grabbed the emoji as normal characters and rendered them normally, be it with a different emoji set but it does open a door or two.

gplusss3

Many people like to add a hidden block of text in the top of their body code so they can control this snippet without having it affect the experience once the email is opened.

I think I need to check out how this looks in other snippet showing inboxes and see how useful this can be at getting attention.

Emoji in the subject line is not a new thing and can help if you don’t over do it – more of a novelty thing really.
Personalisation in the subject line, is a similar thing; when done well and not too much it is effective.

Personalisation in the snippet preview is a lot safer, because whilst it shows up in the inbox its not the subject line and as a snippet of the start of the message, it leads the user into the email, building momentum to get the open. So emoji in the snippet could a useful creative tactic.

Time will tell I suppose.

Microsoft giveth then taketh away

image

Outlook on Android winning / windows 10 is made of fail

Just as the Outlook app finally promises to deliver responsiveness to Android thus completeing the responsive provision in the mobile world, Microsoft announces the new windows10 outlook that will not only ignore media queries, it is identical across all windows10 devices, no matter the screen size. So not even hybrid cannot make it work.

Could this give Gmail the excuse it needs not to bother with the promised responsiveness for its email apps?
Did anyone care about windows mobile, yet, will they ever, who cares?

Will the outlook app on android get less clunky and acheive its full potential? If so might that be enough for google to pull its finger out?
I like it, while it’s not quite ready yet the feature set is near perfect.

Either way time will tell but we’re still short on a responsive android since lollipop has dropped a native email client in favour of Gmail – that client was pony anyway.
Although my old XperiaZ just got lollipop and Sony’s left one in, not that I use it, I use Mailbox [function over fashion], until Outlook’s ready or Google makes something decent.

Querying your responsive terminology

Responsive-web-design-devices3

Querying your responsive terminology

There’s a fair few phrases banging about regarding responsive emails and the term “responsive” itself is one of the most argued terms.

Having HTML render differently on a smaller screen was of course led by web-pages and emails caught up as much as they could, battling through the endless quirks of the many inboxes which an email can be smashed to bits by.

What seems to be the core of the terminology of site design structure is four terms:
Fixed, Fluid, Adaptive, and Responsive.

Fixed – all elements’ widths are set and stay that way on any device

Fluid – all elements’ widths are percentages and the elements will grow and shrink to fit the browser window/device screen.

Adaptive – all elements widths are set to fit the average screen size – media queries are then written to force elements to change at set max and or min screen width sizes. This can be any attribute which CSS can alter, from widths to display, to positioning and more.

Responsive – this where websites are built in a fluid fashion but also use media queries to alter the structure to suit different screens.

But when it gets to email, the jargon seems to get very muddy because you don’t have the luxury off all CSS in all inboxes and you have to use tables to hold them together.

A fully fluid approach is a bit restrictive because you are tied down to a single column that grows with the screen. Nice enough of course, looks great on a mobile but does not make the best use of the space available on desktop and browser inboxes. You don’t have any media queries and it can be a bit of mess with so many screen sizes on desktops too and is subsequently rarely attempted.

An adaptive approach is very popular because most smart phones have a similar screen size so you just set the breakpoint for the largest phone eg: 320px and bring your desktop optimised fixed width multi-column email down into one column and have new fixed widths.
The downside of this is that the reliance on media queries means that it only really works on an iPhone; Android email clients’ support of the media query is poor – although Google have dropped hints that they want to get them working on their Gmail apps now they have dropped Android’s native email from future Android versions.

The other slight downside is having the set width for one phone screen could mean the email does not make best of use of larger phone screens in order to work on the smaller.
So the most popular method is to build for the desktop with mainly fixed widths but with some fluid to help for larger mobile screens and the then use a media query to change the structure down to one column and then use percentage widths so they make the most use of each screen size.

This method tends to be called “responsive”. This makes sense to me as it is a mixture of adaptive and fluid.
But there has been some disagreement over that being truly “responsive”.

The phrase “responsive email” is also used as an umbrella term for any email or web-page which alters in any way to optimise itself for more than one screen size.

It has also been argued (badly) that the use of percentages on the phone’s media query making each block’s width 100% on a phone does not count as fluid because it comes after an adaptive screens size cut off …. this holds very little weight in my mind.

This discussion got a little heated on Twitter recently when someone was not happy that the social icons on a certain newsletter were apparently too big when it adapted for the iPhone and they went further to state it wasn’t responsive it was adaptive.

From my point of view any email which alters its structure for different screen sizes can call itself “responsive”, whether it is purely adaptive or uses fluidity as well or alone where possible.
The method(s) you use for this responsiveness would then become the more granular description of how you made it responsive.

For an email not be responsive it would have to 100% fixed width and not make any allowances to be altered from its original desktop version on the phone or vice versa if is a fixed width slim email built for a slim screen over a wider desktop.
On that note, if you ever feel you have the decide between fixed width slim and fixed width desktop, choose desktop. Everyone knows how to pinch zoom on a mobile but not as many people as you’d think know how to zoom in on a desktop. But pay attention to the clicks by device. it is likely that mobiles will get more opens than a desktop but rarely as many clicks due to the inbox triage. If you are getting good traffic from smartphones, then pay more attention to them.

To add to all of this, it was all changed again during completely email in London last week when Mike Ragan of industry leading email development firm Action Rocket wrote off Fluid as a viable label for email and introduced their new term “Hybrid”, I’m sure I’ll discuss this in another post.

Watch out for plain text

applewatch

Watch out for plain text

As you ‘should’ know, a plain text version of your email is vital for inbox access; Viruses and spammers often don’t bother so content filters lookout for it.

Way back in the days before the WWW, email existed. You sent plain text messages between computers/terminals and the file was a header and the content  – plain text. Then later on, the web was made and HTML was bolted onto the bottom of the mime and email marketing grew.

Over time more and more inboxes would render the HTML and now, pretty much all of them do by default – even blackberrys!

So you just made it quickly with the click of a button or it is made for you and you haven’t had to care about it for quite a while, But now you do!

Phones are getting bigger and to fill the void of the tiny smart gadget, wearables are appearing – most notably the Watch!

Word on the web is that it is very likely that Apple’s smart watch: “Apple Watch” will render full emails but only the plain text version and due to the novelty of it, they are likely to read it or at least the start, they could continue to read the plain text or handoff to the phone.

Either way, your plain text will likely start to matter but you likely won’t know about it because there’s no open tracking in plain text, only link tracking and the likelihood of clicks on a watch is slimmer than a phone, however there is a chance they’ll handoff the click down to the phone – if that’s an option – it should be!

In fact they should let you queue up the pages you click to so you triage the inbox then get your phone out and the pages are loaded and ready!

Make sure you check the plain text version of your emails is structured in an accessible way, especially the top 3rd.

Fun with Background Images


DeepSeaworks2_spots470

This week I’ve mostly been trying to get one dark background image to render behind the message copy, which is white; on Outlook and the big three consumer ISPs: Gmail, Hotmail, Yahoo.

Those of you who know, know…

Each inbox has it’s own preferences about what it will render and how it wants you to code it; background images are one of the more complex. Here’s why:

body color body image table color table image
Outlook Y Y Y N (vml*)
Gmail Y (inline**) Y (inline**) Y Y
Hotmail N N Y Y
Yahoo N N Y Y

 

*Outlook does not support background images on tables or tds, however there is a workaround using VML, this technique is known as “bullet proof backgrounds”.
**Gmail will obey styling of the body tag but the code must be added to the body tag directly because it converts body tags into a div tag but will leave the rest of the contents of the tag in place.

You might ask why there are no mobile clients in there, it’s because if I get these right, the others will work too … or will they? answers on a postcard.
Note: Call the background color before the image in all tags, otherwise the color will be rendered last which will put it on top of the image and you won’t see the image.

 

Essentially Outlook wants the image and fall back color added to the body, style tag will work. Gmail needs it inline to the body or on a 100% wrapping table. Yahoo and Hotmail won’t render body styling so you have to add it to the wrapper table.

The complication is that while Outlook won’t render the table image it will render the table background color, so where you have added a background color to the table for when Yahoo and Hotmail block the images, Outlook will not show that image at all but will show the colour and that will be in front of the image on the body.

If I leave the color out of the table Yahoo and Hotmail will look terrible because the copy is white so won’t be readable on the white background.

What do you do?

One answer is to use a bullet proof background, this is Outlook specific code called VML to make Outlook render the image. There is a free little tool to automatically make the code on Campaign Monitor’s site.

This would work in most scenarios, however on this occasion, my customer had an antiquated system which cannot handle the VML code. On top of that I prefer to only go down this route as a last resort.

Instead I just used the [if mso] trick!

Initially I had to code in the background colour and images in the following places:

  • To the body tag in CSS in a style tag inside the body tag
  • To the id of the wrapper table in the style tag
  • Inline on the bodytag as an html attribute and in CSS
  • Inline on the wrapping table as an html attribute and in CSS

This will work everywhere except Outlook where the table background colour will show in front of the body background image.

Then I simply add an [if mso] comment block underneath the style tag. This block will include another style tag which also refers to the wrapping table and makes the background color transparent, ie:

<!--[if mso]>
<style type="text/css">
#backgroundTable {background-color:transparent !important;}
</style>
<![endif]-->

This essentially turns off the background coloring on the wrapping table but only in Outlook and all is well in the world.

One thing I have not spent the time to test is the number of times I’ve coded the background image. I’m fairly sure that using html attributes and using inline css is a bit overkill, however I’m not sure if one engine prefers inline and another prefers html or either either will work and I just need to pick one. Hopefully inline css is the winner; if you know, let me know!

If only there was an easier way – if you know, let me know…

Promotions Tab goes Pintastic

When the Promotions tab first appeared, brands who’d got Gmail promo’d panicked. They called it “Junk 2” and “the 2nd junk folder”, they spent time with animations in emails showing people how move the emails into their primary folder, had landing pages with videos.
Loads of bandwidth was wasted on this! People still went to their promo folder when they were in Promo mode, eg: in the evening whilst in front of the telly.

Then Google added ads at the top of the promo tab, initially disguised as emails: The email industry went berserk! Sprouting the law of opt-in and permission to emails. Except Dela Quist of course who said they were clever and there is more to come – how right he was, as always.

Are they emails are they not emails? Google changed the colours a bit, added a little “ad” label and an ‘X’ button and we all got on with our lives.

Reports came in about open rate drops in Gmail, email marketers were depressed.

Then Google started to auto-load images, Yay! something to be happy about; then we found that the caching was stopping tracking for all repeat opens, device tracking and location logging.

What will they do to us next they cried! There was sooo much drama!!!

Well…

Introducing the new imProved, Pretty, Pinteresty: Promo Tab Grid View

Loads of films in the early 2000s suffered from appallingly bad endings where producers were so unable to restore the equilibrium to be better than or even equal to the start of the film, they’d kill off a main character to make you think that anyone could die so by then end you were just relieved that no-one else died rather than disappointed at the shoddy ending. eg: Transformers – Jazz, Serenity – Wash: Yes Spielberg I’m talking about you!

Some say this was Google’s plan all along. In order to maximise it’s impact they had to make the promotions tab look a bit crap first.

As announced on the Gmail Blog it’s currently only in a field trial, Gmail are giving users to ability to turn on a classic grid view of the content of their Promotions tab to give them a better experience of their marketing emails.

Even though the grid view is not a new thing, it seems to have been made famous or at least cool again by Pinterest, either way it’s the first time it’s been in an inbox (or is it?).

Although it will make it easier for Google to slip in adverts, this is definitely a good thing. Google have even released details of what to put in your emails in order to customise the hero image and of course the sender logo is taken from your Google+ page.

If you want to try and get involved in the early days of this, sign-up for the trial and hope for the best.

If you just want to get ready, check out the dev code to make sure you have everything read to add to your emails going forward.

 

What’s next? Brands telling their users how to move the emails  from the Primary tab back to the Promo tab, maybe a G+ button on the emails to help the brand on G+ maybe to even help deliverability?

Time will tell!

Either way, I love the fact that someone is being innovative with an inbox. It is the recipient experience that matters and our job to facilitate that in the environments provided.

 

 

(image courtesy of the Gmail blog)