To set up your DNS entries, go to Settings > Your Site Settings > Set up your DNS

In Step 1, enter your domain name (the same one you used to set up your Site URL)

In Step 2 you will see which tracking, forward and bounce entries you can use. This is important if you would like all links to appear as sent from your own domain, not ours. (Tracking links are inserted upon delivery to your existing links)

Once the changes are propagated, you will see a confirmation page. Keep in mind the process can take several hours (depending on your DNS server’s time-to-live setting), so check back later if it doesn’t work right away.

Read the full Support Document here!

In order to help your clients maximize deliverability by authenticating their domain using SPF/SenderID and DKIM (DomainKeys Identified Mail), we have implemented a new email validation feature.

To validate a sender email address, go to Settings > Validate your email address

In Step 1 enter the email address that will appear as the sender email
(what will appear under “From” in the header of the email)

Step 2 will provide you with DNS setup instructions. There are three methods available:

• Method 1
  Add a CNAME record to the DNS for the DKIM authentication
• Method 2
  If your panel does not accept “_”, you will be provided with an alternate DKIM record
• Method 3
  Add a TXT record for the DKIM authentication

Final Authentication
When the authentication is complete, you will see a prompt letting you know. Keep in mind the process can take several hours (depending on your DNS server’s Time-to-live setting), so check back later if it doesn’t work right away.

 

Make sure this option is enabled in your reseller panel by going to Settings > Your Site Settings > General Settings > Display email validation tool to your clients

Read the full support how-to here.

A pleasant nightshift for CakeMail: baking cupcakes at 10pm on a Wednesday so they’re ready for Thursday’s morning coffee. Tried a new recipe for the cake itself, as I had never used cornstarch in cake batter before. As it turns out, it’s quite a good discovery!

This recipe comes from the Joy the Baker blog. Visit her site to check out the recipe itself  (I won’t reproduce it here so she can have all the credit).

Makes approximately 24 cupcakes

Cupcakes should always be served at room temperature. This icing is quite runny so I left it in the fridge and piped it onto the cupcakes just before serving them.

Joy has beautifully decorated her version with dulce de leche drizzle and fleur de sel. I made things easier by simply adding a piece of caramel à la fleur de sel on the top.

Team comments:
- Icing plus-que-parfait
- The caramel twist on the top was a triple D winner: delectable, delightful, delicious!
- Icing is great: not too sweet and creamy & tasty

My verdict:
One of the most ‘balanced’ cupcakes I’ve made. The cupcake itself is very good, even though it’s only vanilla! Icing is a perfectly balanced flavour somewhere between cream cheese & caramel. The cake itself has a beautiful golden color.

Score: 4.75/5 cherries

]]> http://www.cakemail.com/cakemail-caketest-perfectly-balanced-dulce-de-leche-cupcake/feed/ 1 http://www.cakemail.com/template-coding-the-importance-of-template-size/ http://www.cakemail.com/template-coding-the-importance-of-template-size/#comments Tue, 24 Apr 2012 13:25:32 +0000 Andrea Saez http://www.cakemail.com/?p=1102443 Continue reading →]]> It’s always important to remember that coding an email template is not like coding a website – different rules apply. Unfortunately, email clients are not as advanced as one would hope they would be, so when coding, one must remember to keep things as simple as possible.

A few weeks ago I wrote a post about important factors to consider when using background images and how it can affect the delivery of your email. This week I’d like to talk about limiting the size of your templates.

Even when coding a website you have to think about how different browsers and screen sizes will render your site. The same applies to email – except you have some different limits consider. While there is no set limit in length, email clients have a default width limit of 600px. It’s important to keep in mind that email clients will not use the full width of your screen to display your email – the last thing you want is for the email to look completely different than in your preview!

If you want your email to be viewed in one clean, straight view that does not require any extra scrolling from left to right, the 600px rule is something to keep in mind.

Luckily, our own Email Campaign Builder can help if you’re stuck – it will resize all images for you to 600px, and even gives you the option to resize/crop any images in your Image Library.

So how will this affect you?
I ran a test with a dummy campaign using Email on Acid for Gmail and Outlook2003 – here’s what would happen if I sent an email with 800px wide content. (based on a 1024×758 standard monitor size)

on Gmail

on Outlook2003
 

Notice how in both instances, the template and images are way too large for the preview pane to properly show the email.

Now here is the same email, but with the template at 600px

on Gmail

on Outlook2003

Not only is the 600px test cleaner, but I can see more of the content of the email in the preview pane. It required a lot less work to try to figure out what the email looked like.

By keeping these rules in mind when coding templates and you will ensure that your subscribers see exactly what you intended in their inboxes. You can also use tools like Litmus  or Email on Acid to preview campaigns across multiple email clients.

In traditional workplaces, ideas that don’t come from the product manager are not typically taken into account. At CakeMail, we think differently. Anyone can come up with a good idea – and if it’s a good one, it will be implemented in the product. We also listen to our customers as much as possible. Even though we happen to say no often (as you should – saying no is a powerful thing), if the idea is often requested, it might have a good chance of being put into the product.

Of course, we also have a product roadmap. Contrary to most companies, this roadmap is not set in stone for a given period of time. We know where we are going in terms of product strategy – but the priority for developing new features can change at any time. We try to stay agile as much as possible.

The roadmap is also not public. We don’t want to commit to a date, and we don’t want to over-excite our customers. They just know that every week or so we make changes to the platform, and every two months, big new features are available.

Wireframes

Every feature we add starts with a wireframe, or a mockup depending on the situation. Wireframes usually start as hand-drawn scribbles and end up as a full wireframe done with the fantastic Axure app. I prefer Axure over other wireframing tools because it’s so easy to create a working prototype in minutes, with on-mouse events, keyboard validation and multiples states on each page.

As soon as we have a working prototype, wireframes are uploaded on share.axure.com, letting teamates review the prototype and make comments. We don’t use the commenting feature of Axure Share – it’s not convenient at all. We simply share our comments by email most of the time, in a Basecamp project (their new version is great) or if necessary, in a Google Doc. From there, several iterations are made on the prototype – as much as necessary. As soon as we are happy with the feature, the designer comes in, and creates the design in Photoshop or Fireworks. The designer will also put his personal vision of the feature in the mockup – and that’s ok.

If you have good Axure skills, you can produce extremely precise wireframes in no time, using homemade librairies of your product. For instance, we’ve created a CakeMail library that contains most of the design elements we need, like popups, buttons, titles, links and so on. This way, new screens can be created in a very short period of time – and people won’t even notice it’s a wireframe, as it’s an exact copy of the application itself. However, if the feature is a new screen, a new page on the website, or anything that we don’t have in the product so far, we won’t have any other choice than to create mockups for it from scratch.

There is lot of debate at the moment regarding Photoshop/Axure vs HTML mockups. Really, it does not matter – use the technique you are the most comfortable with. It’s ok for a designer to design in Photoshop, and it’s okay for a front end developer to build an HTML version of the design.

Github

Github is a very important part of our workflow. Basically, everything evolves around it: bugs, comments on new features, design,… And it hosts our code, of course. As soon as a design is ready, we create an issue in Github. The issue contains the design and a very brief spec (nobody likes to read pages of Word specification). Each issue is assigned to a developer, a milestone and one or more labels. That way, the developer is aware that he is in charge of the feature. He also knows if he has to code it now (based on the release number) and depending on the label, knows if it’s urgent or not.

To describe a feature or a bug, we need images in the ticket in Github. It is crucial and speaks much more than words. We store all our images on Imgur. To make sure images are not deleted after a while, we have pro accounts. To speed up the process of putting an image in a ticket, I use a Chrome extension that lets me drag and drop an image from my Desktop to my Imgur account. Once the image is on Imgur’s servers, I copy the link and use Typinator to paste the link formatted as a Markdown link. Typinator is basically a text expander that lets me save thousands of keystrokes. To paste an image in Github, I simple type iimage and it generates ![image](http://www.ergonis.com/products/typinator/) automatically. It’s awesome.

Localization

Once a feature is finished, we can start entering strings in our internal localization tool, our so-called i18n portal. We officially support English and French, but we have many more languages that some of our customers support themselves. If your webapp supports localization, then you know it can really be hard to manage. Because there was no elegant translation solution available on the market, we decided to create our own. Our tool works pretty well: users can add or update text strings that then get approved by the person who is in charge of the locale. Then, each time a string is modified in the master file (English, for us), all the other languages are prompted to update these new or updated text strings as well. Last but not least, you can push all the strings in production  with a single click of a button.

Support

After this process, support comes in and prepares documentation for the new feature, which will be available to everyone in the new knowledge base we launched earlier this month. This new tool is pretty sweet: all we have to do is to update markdown files, push the changes to Github, and few minutes after, it’s live.

Announcing features

Once it’s live, we write a release note for the new feature and publish it to the release notes website. This way, any one of our customers know exactly what we’ve added to the software. As much as possible, we try to document the changes we’ve made. For bigger changes and major versions, we’ll blog about what’s been added in more detail, and send emails to our current customers and other opt-in subscribers so they’re aware of what’s new.

The delicate balance between creating your own tools and using existing tools

In the last few months, we’ve had to create multiple internal tools to help speed up our workflow, and especially to empower non-technical people with tools they can use themselves. We could have used existing tools – but most of them were not suited to our specific needs. It’s a decision that each company faces. When deciding on tools, we always ask ourselves these questions:

• is there an open source solution that we could use? If so, what is the hidden cost of using it (i.e. managing the server, fixing bugs, etc…)?
• is there an existing SaaS product that is not too expensive that could solve the problem?
• how much time would it take to create it ourselves?

The choice depends on multiple things: the urgency of the problem, availability of the dev team, budget, timeframe, culture of the company. We’ve decided, for each of our cases, that it was critical to be able to manage each problem ourselves.

In this new guide, you will find details instructions on getting up and started with a  reseller account:

1. Enter your company information
2. Configure your DNS Settings
3. Add users
4. Configure your Site Settings
5. Brand your site
6. Create your clients
7. Upload and share templates
8. Offer Add-ons

Check out the full guide here! 

In the guide you’ll find:

1. How to build your contact list
2. How to build and edit the content of your campaign
3. How to test and send your campaign successfully

From creating your first list, to editing the contents of your campaign, to testing and scheduling your campaign successfully – we have documented step by step instructions to help you get started.

You can read the full get started guide here!

Background images in HTML email templates have long been acknowledged as inconsistent in their rendering across email clients. While modern email clients (such as those on iOS devices) may display them correctly, more traditional desktop email clients, like Outlook, offer absolutely very little support. Modern web clients like Gmail have recently implemented background image support, ‘background-position’ is still not supported. Hotmail, in the meantime, offers very limited support on this.

Many users feel that background images are important features, there are a few factors that should be taken into consideration before using a background image in an email:

1. Remember that many email clients offer a “preview pane,” which may not render the image correctly. This could cause your background image to look distorted.
2. Your campaign should include an equal image-to-text ratio. CakeMail offers a testing tool called SpamAssassin, which will help you analyze your image-to-text ratio. Here are a few things to aim for:
   • A maximum of 40% image coverage
   • A minimum 60% text coverage
   • More than 3 images in the page – if any at all.
   • Not all images touching
   • At least 400 characters of text

   As per anti-spam law, all emails must contain some form of text (even if it a simple “hello”). Image-only emails will not display properly and are almost certain to be flagged as spam.

3. Always assume that the majority of your readers will use an email client that will strip out your background image. Here are a few design tips in case that happens:
   • Give your table a background color that matches the background image as close as possible.
   • Make sure there is enough contrast between your text and the background image/color in case the background image is stripped out.

If you would like more information on background image support across all email clients, take a look at The Email Standards Project homepage.

To share your campaign on Facebook/Twitter:
The Social Media Toolbar will allow you to insert a toolbar on top of your email, allowing people to forward the campaign to a friend or share it on Facebook or Twitter. To insert it, simply click on Insert Social Media Toolbar under the Advanced Options when creating your campaign.

To add follow links in your campaign:
A social media section is available to be inserted in Optimized Templates only. Simply click on the Facebook/Twitter icons under Add section to insert the section in your campaign. To edit the links, hover over each icon and add the direct link to your social media page.

View this support document and many others in our Knowledge Base!

The new knowledge base divided into three categories – reseller, end-user, and API – all of which are easy to navigate through. Our Support section has also been updated, with a more user-friendly look and quick links to access some of our most popular features.

CakeMail Knowledge Base
Support Site