Browsed by
Category: Email

Can you put a hedgehog in an email?

Can you put a hedgehog in an email?

Taking the classic question all email geeks will be familiar with. “Can I put a video in an email?”, I decided to replace the word ‘video’ with first word that sprung to mind at that moment, ‘hedgehog’. (That is not true)

*I feel at this point I should point out that this is purely an experiment and not a real email, this is all part of personal research project, I’ll be receiving no financial recompense. It’s just for me and the #emailgeeks.*

I’ve been on a bit of a mission recently trying to explore “gaming” in email, and it ties in somewhat to some of the things I was looking at when I created the Interactive Tree. I feel that “gaming” in it’s true sense can obviously be limiting. For example what if the situation arose where we try and promote an actual game… could we do that justice with interactive email? (like Sonic The Hedgehog for example) how far could you realistically go with it? and what could be a good way to do it?

We’ve already seen some innovation in gaming emails in the past with Mike Ragan’s Transformers Pixel-art. But other than that I don’t recall seeing much worthy of remembering.

I started to think about HTML banners, CSS animations, and those interactive/animated adverts you get here and there, and how perhaps a simplistic nod to the game might work, and began to sketch out ideas. I chose Sonic largely because as a boy I was Mega Drive kid, and loved Sonic 2. I also felt that the platform simplistic nature of the early versions would work (it really could have been anything though… Mario, Dizzy, Chuckie Egg. I must again stress that in no way have SEGA or Sonic The Hedgehog been involved in this, I used the theme of Sonic purely for experimental purposes).

So first up, I made a list of key Sonic traits and these were. Running, jumping, rolling, spinning, and moving fast, collecting rings, landing on spikes, drowning, quirky 8-bit music. Awesome. I then started sketching some VERY rough ideas. Below are some of the later sketches.
Beautiful right?! (and a textbook mug of tea stain)

sketches

 

I then went on the hunt for assets. Thankfully there are loads of sprites out there for this sort of thing, so I found one suitable and easy to work with and then went on the lookout for assets to create the setting/background.

The first thing I had to do was to start setting up sprites, choosing sizes, this was all pretty easy, but creating the backgrounds for Sonics “Green Hill Zone” was one of the most time-consuming parts of all this. Sonic’s worlds are not flat, and I wanted it to be flat/level more for my own ease, and to keep things simpler, so I began slicing up sections and trying my best to merge them together to create a flat version. Here’s part of it.

green_hill

 

I went in to this knowing full-well I’d be targeting Webkit and using Absolute position in this which if something like this were sent it would give Samsung Native apps some problems, but I can target that, so didn’t hold back.. But obviously being an experiment it wasn’t a problem.

I decided to initially break what I had planned in to three parts, and build each section individually – and then try to connect them up in one html afterwards. So I made the first section. The Entrance, and this would largely create the settings for the rest as well.

diagram

 

Entrance


The Entrance

For this section I wanted Sonic to enter the frame from off-set, as you can see above I still have the initial sketch I did for planning the layout for the whole thing, (I’ve gone over the key bits for the first frame in Pen). It was all largely straight forward. The key was having the Sonic animation, and the container around Sonic. So then each element could be controlled individually. The container moves to it’s position from off-set and the background sprite plays while it happens.

The main thing to be aware of here was really with the title. From what I can tell you can’t go from “Display:none” to “block” and vice-versa in a keyframe timeline. So I got around this with the title by setting it’s height and width to zero, and then changing that in the keyframe.

Once I’d done this I was a little torn with what to do from here, as it would take me in a direction. I didn’t want to try to define controls and have him move around at the users will. I felt this although quite a cool option, this would fail in the expectations of the user. I’d considered it for a while but in the end I stuck with my initial plan.

The Entrance section didn’t change from my first version.

 

Original Run Sequence

Run

From here it was largely straight forward…. Press run, hide the ‘entrance’ stuff, show the ‘run’ stuff. Key difference is Sonic’s container no longer moves, but the background moves instead, and the new sprite plays. I then created the sign to drop down in the keyframe timeline and programmed a jump button to appear, where the “run” button was previously.

 

Jump

Jump

Again this was similar to the ‘Run’, I swapped the background to one with spikes, and the key difference is in the timeline is getting the sprite set-up correctly was a bit fiddly, I even remade the background and moved the spikes around a few times as I worked it out. And then making Sonic’s Container move up and down, along with the sprite animation to jump over the spikes. It was largely lots of back and forth.

Not Jump 

So this is where I had to rethink things and go back. Throughout the process so far I’d been using  ” #foo:checked ~ * .foo{” (so when the box is checked, make this happen).
My plan for “if they don’t press jump” seemed simple enough, ” #foo:not (:checked) ~ * .foo{“. (Seems obvious now)
I didn’t pre-empt that during the entire animation that the “Jump” checkbox would not be checked, and as I started to bring all the pieces together I quickly realised this, and that things like the the sprite of  Sonic running in to the spikes would be showing throughout. I tried to find a way around it, but nothing was working well enough.

I know the obvious thing to from the start would be to have a long-timeline in which you press run, and eventually at the end of it Sonic would run in to the spikes if you didn’t press jump. This is what the final thing ended up being. But I was aware this was going to have to utilise a lot of images (the ratio and weight, goes against my better judgement). This method mean’t I’d need “a big old background” for the run section.

final_run

Rebuild the Run Section.

So the Run section was rebuilt and slotted back in, and became a long section, and the background image was much longer and bigger.
I knew this would have an affect on load up time, on the press of “run” so I added them in to the body of the email and covered them over with flat colour so they start loading up from the start. Which seemed to help, in a similar way to a pre-loader. I also lowered the quality a little and ran them through optimisation a few more times than I would have liked.

gameover

Ending signs

This is pretty simple. They are images that are the size of the frame, set inline as “a tags” with IDs, and in the embedded style for the control of them. They are both set on a timeline to drop down over the frame after a certain amount of time. In the case of ‘Game Over’, it will drop down after 11 seconds after pressing the run button, and in the case of the ‘Play Sonic on your phone’ it drops down 4 seconds after the jump button is pressed, and if jump is pressed the ‘Game Over’ doesn’t happen.

The plan would be to link “Game Over” to the online version of the email, and link “Play Sonic on your Phone” to the app store.

Conclusions and other things

There is still plenty to do with it, but as it’s just an experiment I’ll gradually pick bits up here and there as I go along.

  1. It hasn’t felt as smooth as I initially had it and I guess that is largely  down to weight, and timelines, but some of that I can’t afford the time to fixing. I partially feel like I was as happiest with it when I had it at a point where it was really simple and Sonic just kept running until you jump… The whole thing worked well and although simple, it was quite nice.
  2. Mike Ragan, pointed out to me that the ending wasn’t right and that Sonic should Jump through the big golden hoop like he does in the game at the end of a level. This idea I really like, and now it annoys me a little that it doesn’t do this, however I couldn’t really spend too much more time on this and I could probably quite happily keep working on it forever if I had the chance. So I’ve left that out. (sorry Mike)
  3. I think one of my biggest frustrations with that I haven’t really sorted out yet is the ‘Jump’ button. Again because timeline doesn’t support transition between display:none and block. It’s always there, but the opacity changes. So I want to work out a better way of setting this up when I get chance, probably utilising the same height adjustment method I used previously.
  4. The other thing is, it’s pretty tiny outside of mobile and of course it’s largely all images. But as an experiment I’m pretty pleased with it. I like the fact it’s still an advert, and promotes the game. It doesn’t distract from that end purpose. Which in my research with the Tree and this, I think it’s a different approach to a similar idea.
  5. Oh and -MOZ- doesn’t support background animation in a keyframe as far as I’m aware… Obviously the build is for webkit. however for view online I’d have to have a look at the “jump countdown”  This could easily just be a .gif or change the messaging perhaps.

Give it a go. View it here 
(Open it in  Chrome or Safari)

So that’s really it, still a few bugs to work out but that’s about it. All it needs now is fallbacks, and any surround/fallback design, hacks putting in for Samsung Native Webkit and then it’s a functioning email.

We’ll be making more fun things, that we might send out so sign up to our emails here

Thanks for reading.

Kristian

@joon82

 

sonic_die

Backgrounds for email: Part 3 – Vector Markup Language (VML)

Backgrounds for email: Part 3 – Vector Markup Language (VML)

There are a lot of things you can do with VML, like word art, shapes and all sorts of things, but unless you’re doing something really quirky just for those Outlooks, and unless you have a lot of spare time, then why would you?

I’ve covered off sections relating to VML Considerations in part 1 and part 2, but this was related to background images. In part 3 I want to highlight an alternative by looking creating VML gradients.

Why would you bother?

Recently I have been working a lot with a brand that uses a lot of background gradients in their designs, and in certain circumstances I’ve used background images (perhaps where there is one gradient section), and in other circumstances (where there have been numerous),  I have simply created the CSS gradients in the embedded style to keep things simpler and lighter, which i prefer.

Because I’d started moving towards more lightweight solutions for these templates, and the client had a large Outlook customer base, I figured if I could create these solutions in CSS, I should create then in VML as well as I knew it was possible.

Create the Gradient

It;s pretty much the same as adding a background image, or creating a VML gradient for a fallback button. In this example I have recreated a simple vertical gradient, running from one colour to the next. The crucial bit is all in the V:fill section. You set your two colours and then you toggle with the angle and the focus to create what you want.

<!--[if gte mso 9]>
 <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" 
stroke="false" style="width:600px;height:338px; padding:0px; margin:0px; 
display:block;" inset="0,0,0,0""><v:fill Type='Gradient' 
Angle='0'  Color='#007fcc' Color2='#003196'  Focus='0%' />
<v:textbox style="v-text-anchor:bottom;" inset="0,0,0,0">
<![endif]-->

Angle
Angle is self-explanatory. You change the angle according the reflect the gradient direction you require.

Focus
Focus is the starting position. The default is 0, but values range from 100% to -100%

grds

 

What else can you do?

If you feel like experimenting with these a little more you can take them up a level, and looking at some of the sigma gradients.

<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" coordsize="21600,21600" style='width:600px;height:350px' fillcolor=#446674>
<v:fill method="linear sigma" angle="45" color2="#000000" focus="100%" 
focusposition=".5,.5" focussize="0,0" type="gradientRadial"/>
<v:shadow on="t" Offset="0pt, 0pt" />
<![endif]-->

The code for these is a little different, but they’re quite interesting to mess around with. For these the ‘method’ changes to linear sigma, I have a ‘fillcolor’ set, and then just a ‘color2’. Again you can adjust the focus, and the angle as before, but with these you can create some interesting effects by using ‘focusposition’ and ‘focussize’

Focus Position

Like with Focus this is about the starting position/centre position for the gradient. But with radial gradients you can set two positions. from the left and from the top.

Focus Size

The values are fractions of the width and height of the shape. The first is a percentage of the fill to the right edge of the shape and the second is a percentage of the fill to the bottom of the shape. The default value is 0,0.

radials

I’ve mocked up a few examples, but it’s worth having a play around with them as you can create some nice textures and effects with them. You can also use these in ’roundrect’, and add in ‘v:shadow’ as you can see in the code below.

<!--[if gte mso 9]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" 
xmlns:w="urn:schemas-microsoft-com:office:word" style='width:600px;height:350px' 
arcsize="4%" fillcolor="#446674">
<v:fill method="linear sigma" angle="270" color2="#000000" focus="100%" 
focusposition=".4,.8" focussize=".4,1" type="gradientRadial"/>
<v:shadow color=#333333 on="t" Offset="10pt, 10pt" opacity="40%" />
<![endif]-->

Give it a try, let me know if you come up with anything cool, or anything to add.

You can access the @litmusapp builder file here

Kristian

@joon82

Litmus Announces Microsoft Partnership

Litmus Announces Microsoft Partnership

litmus-microsoft

Last night during Boston’s Email Design Conference, it was announced that Litmus and Microsoft are going to team up to make email better.

Caitlin Hart, Program Manager at Microsoft was welcomed onto the stage by Kevin Mandeville and Justine Jordan who then described the long term plan for the partnership with Litmus.

Every email developer out there knows that Outlook is the biggest of many bug bears when it comes to email development due to the myriad of versions and platforms that Outlook runs on; the biggest issue being that the (desktop) application uses Microsoft Word to render email instead of Internet Explorer.

We’re excited to partner with Litmus, who has an amazing user base of passionate email marketers and developers that can provide us with real world examples of rendering bugs and errors. This will allow us to better identify and prioritise rendering issues to work on improving rendering in Outlook.

Caitlin Hart, Program Manager at Microsoft

Litmus announced as part of the partnership that it plans to include a ticketing system, so email developers are able to report all the issues they experience with Outlook directly to Microsoft. In addition to this, Litmus announced that new Microsoft email clients (Windows Mail 10, Outlook app for Android, iOS and Windows Phone) are going to be available for testing in the app, as well as allowing users to sign up for a free Litmus account that allows for Outlook render testing only.

We couldn’t be more excited about this partnership, and want to thank the Microsoft team for joining the campaign to #MakeEmailBetter.

Paul Farnell, CEO, Co-Founder at Litmus

Our Thoughts

Whilst Outlook and all of its annoyances aren’t going to be fixed overnight, this is a huge step forward. The fact that Litmus has managed to get one of the biggest email clients onside, willing to make changes to their products for US as email developers, is a great achievement.

We’ll be following up on this post with our thoughts on the changes that we think should be made to Outlook in the future, in order to #MakeEmailBetter.

Tom Riley
@MrTomRiley

Background Images: Part 1 – Content Images as background.

Background Images: Part 1 – Content Images as background.

Backgrounds Title Header

To follow-on from my talk at ‘The Litmus Email Design Conference 2016’ (#litmuslive) I’ll be doing a series of blog posts covering background images. They’ll feature key design considerations, prevent time consuming frustrations, some simple code solutions and some additional ideas for things like progressive enhancement.

Increase your Design Opportunities.

Background Images in email have a mixed reputation. Depending on your experience and approach, they can be a pain to work with, and many people find them too time-consuming, add too much weight, and/or restrictive. If this is the case I think it stands to reason that designers and developers when time is precious can potentially do what they can to avoid using them.

But if you use them in the right way there can also be some real design benefits to using them over and above just being to add live-text over an image, such as:

  • Create impactful designs without using too many images.
  • Help to frame content and add extra texture and depth.
  • Increases your creative options
  • It opens the door to more emotional design.
  • Can enhance the user experience with minimal effort.

We now know that we have that we have to be very focussed with our content, and that we have literally seconds to make an impact, something like a background image could be a good tool to have, and use in the same way as websites do to draw your attention.

Because email rendering can be awkward, and support can be sketchy my ideal scenario is to use backgrounds that are layout images, so if the background or the image is not supported you aren’t losing any thing from your content. You’re then not relying on the background image to deliver a message.

However probably the most frustrating part of using background images. Is when you have to use content images as backgrounds. Especially if that is a full width header image.

Content Images as backgrounds.

So with this situation I always aim for the same result. And I think I have a simple method of achieving this. The key thing to remember is that, email doesn’t have to look the same everywhere. So in that transition between desktop and mobile, regardless of the image, I aim for my content to remain the same size/easily readable on mobile. Immediately you then have another victory over “burning” the content in to the image. It also provides me with a simple mindset, and solution to aim for that I can build upon with very little effort.

To start, the thing to remember is that background images can be fluid. This is roughly the code set-up I like to use.

core_code

I’ve then set-up my image, and added inside the VML <DIV> the content to go on top, and forced it in to the position I want, at the foot of the screen.
For this I have used a top padding of 180px, but you may prefer to use heights instead.

NOTE: As a side note for anything horizontal I have spacing <TD> because there is a glitch with Outlook 2013 where horizontal padding has a habit of not working inside the VML fallback.

desk_robot

GMAIL APP

(please note that since writing this, Gmail has started supporting ‘background-position’ and ‘background-size’ on gmail addresses)

At this point I would test it in the Gmail App. To see what kind of result I get. Because if it’s not right in there. There is little I can do about it.
Thankfully it works quite well, but if not, I would go back to the desktop and try to find a workaround. Perhaps by repositioning the text, etc…

(Not featured in this example, but when setting the content up, I will often to start by setting things up in 2 floating table columns, even if one is blank. This give me a column that will stack on gmail and i can sometimes use it to my advantage to position things and then re-control on other mobile platforms.)

I’ve also set the position as ‘background-position: center top;” which shows the central portion of the image. This is made easier because the key area of the content (Mr.Robot) is narrow. However as you can see with the other example (Silicon Valley). You’re really looking to choose the ideal portion from either left, center, or right of the image when it’s a “busier” image.

You can however as Remi Paramentier (@HTeuMeuLeu) said at the same conference target the gmail app, and apply ‘background-size: cover;’ in shorthand and gmail reponds to that. So that might be something you want to work with and try out.

gmail_app_position

CALC and the GMAIL APP

UPDATE: This is now probably more relevant when rendering in the Gmail Apps on a non-gmail address.

If you’re looking for more precise positioning, you can always use CALC inline to reposition the background, and then use a media query to reposition again on supported mobiles.
The support for CALC has been fine for myself, however I have some potential issues on older Android devices. Worth looking in to though especially if you have a right-hand side image like the one below.

The one thing to be wary of here, would be to consider your text positioning. If you were to put text to the left of the image, it would just move behind it. So keep your text, above or below.

calc

THE TRANSITION TO MOBILE

So as mentioned, I have a straight forward formula for mobile, and although there are other options. I tend to always immediately aim for 1 of 2 solutions.

Because I have a flat background colour applied behind the image, I simply allow the image to shrink down on mobile to see how it looks, and more often than not, the combination of the image shrinking down and the content remaining not at this point will force that background colour to appear from behind the image. I then used media queries (often padding) to force to the content on to the flat colour.

(if this doesn’t work for you you can always apply and flat colour behind the content using media queries and see how it works out)

The second thing I do here is once I have that version right. I then apply background-size: cover !important; as a media queries style to see how it looks when the image fills the space. This can be hit and miss, often depending on the amount of content. But it’s a easy thing to try, to give you a different result.

For the really awkward scenarios

If you get really stuck, there is one solution I have gone to in the past. But it does tend to leave you forcing the desktop on gmail, or targeting it with other gmail hacks. You can use media queries to:

  • turn off your background image
  • remove any fixed heights or padding from your content. Leaving just the content
  • Apply a flat background colour behind it.
  • Turn on a mobile version image of the background image.

So that’s it for the first part. It’s a basic premise. If you have anything you wanted to add, please feel free to let me know.

 

Next time around I’ll be looking more at the other part of my talk. Patterns, Enhancement considerations, and Layering of content.

 

You can access my slides from Litmus here

 

Kristian Robinson
@joon82