Dinosaurs with Laserz

Note: I’m in no way trying to be vindictive towards the typographer, font foundry or anyone in this post. Pricing fonts for use in apps is still new territory for everyone. Also, bold formatting in pasted emails is mine.

The Setup

If you’ve read my earlier posts you’d know I’m working on the design for an iOS app, a companion for the website surftourist.com.

The website uses a font called Crete Rounded via Typekit, it’s become part of the Surftourist brand. Naturally I wanted to use the font in the app, and I purchased the Open Type version for €35, using it liberally.

You got a licence for that?

It occurred to me that the license I got with my purchase might not cover me for app use, so I tracked down the foundry, TypeTogether, and it turned out I was right.

On 11 Oct 2011 at 17:45, Veronika wrote:

Dear Craig,

thank you for your email.

The license you would need is a Limited Commercial Basic License, meaning that the fonts are embedded as static gifs (or similar). They are not used interactively, i.e. the user can’t type with the font within the app.

The license fee for this use is €900 per font and per application, valid for the life-time of the product.

Wait, what?

1. Using the font on a website via Typekit, 25,000 page views a month, free
2. Print, unlimited distribution, €35
3. iOS app, no interactive use, €900

How could you justify that? Apps sell at extremely tight margins. If I sold my app for a dollar, I would have to sell it about 1200 times just to break even on a font? I wrote another email, which subtly pointed out the pricing anomaly, noting that for €35 I could distribute it in its printed form to as big an audience as I pleased:

On 12 Oct 2011, at 08:46, Craig wrote:

Hi Veronika,

Just to clarify, if I don’t currently have a ‘Limited Commercial Basic License’, does the license I purchased with Crete for €35 allow me to use it in commercial print projects, or on slides in a public event presentation?

On 12 Oct 2011, at 17:19, Veronika wrote:

Hi Craig,

the Limited Commercial Basic License applies only to mobile, online apps. It refers to the actual font software being embedded within the product. You can use the print fonts to create any printed materials, embed in pdfs, use in a presentation and more. For more details please read our EULA: http://www.type-together.com/resources/eula/TT-EULA.pdf

Enter Mobile FontFonts

Coincidentally this happened just as Fontshop released Mobile FontFonts in October 2011. Fontshop’s communication was a little misleading – they seemed to be taking credit for making custom fonts available in iOS when it had been possible since iOS3 – but what’s great about these fonts is their price. For around $170 each, a team of up to 5 developers can use the font to their hearts content in as many apps as they want.

These two vast differences in pricing got me worked up, so I wrote another email.

On 11 Oct 2011, at 23:52, Craig wrote:

Hi Veronika,

Thanks for your quote of €900 per font per application.

FontShop International now offer 14 fonts which they claim are specifically designed for iOS. They’re priced at about $170 each.  http://www.mobilefontfonts.com/font/2346/usecases

I would prefer to use Crete, but due to this project’s budget it looks like I’ll be using Tisa instead.

I don’t want to sound flippant, I just want to alert you to the immense price difference. Licensing fonts for apps is still new territory for everyone.

On 13 Oct 2011, at 5:28, Veronika wrote:

Dear Craig,

we have priced our fonts in tune with market standards so far. I am sorry, but for now i can offer you only a 15% discount on the license fee.

Even with a 15% discount (€765) this font would have to be freaking amazing for me not to resort to a $170 alternative.

Mobile FontFonts have hopefully set the margin for font pricing. Unfortunately at the moment we’re only given 14 fonts to play with. All we can do is hope it’s a roaring success and other font foundries take note. Currently the app marketplace runs on low margin/high volume. While foundries continue to price high margin/low volume, the system won’t work.

Mobile FontFonts
http://www.fontshop.com/fontlist/applications/mobile_fonts

TypeTogether and Crete
http://www.type-together.com/crete 

Using custom fonts in iOS4
http://stackoverflow.com/questions/360751/can-i-embed-a-custom-font-in-an-iphone-application/3198821#3198821
http://blog.beefyapps.com/2010/06/custom-fonts-in-ios-4/

This morning it occurred to me that there was a lack of good information around for what we can get away with when using images in an email design.

I’m missing my images

Images not loading in an email is sucky, especially when it’s an email you’ve designed. Top of mind is the one pictured below (not one of mine) which arrived in my inbox recently.

We have to assume that no matter what we do we’re going to have to live with the occasional missing image, which is why we should always avoid splitting images up into separate parts. This stops photographs of products being cut in half, and rasterized text becoming unreadable.

How big?

I decided to ask @campaignmonitor what their opinion was on acceptable file size was:

@craigrozynski Generally, we say keep the email as light as possible – image-heavy emails are slow-loading and can burden mobile users ^RH

Nothing we didn’t already know right? Is it possible that no one has done conclusive testing? How can we be this far down the evolutionary path of email design and still be this vague?

I don’t think I’ve ever built an email larger than 200kB, but what if I’ve been needlessly paranoid, compressing product shots down all this time?

It’s all well and good to say “Dude your email should be like, 20kB tops. Draw it with CSS or something”, but when you’re selling products based on their aesthetic value, a heavily compressed jpg is dumb.

What I want to know is – how big a file size can I get away with?

How many times?

But wait, there’s another factor that may play a part here. Do email clients have an aversion to how many http requests I make? Obviously a single 100kB image will load better than 100 1kB images, but I want to know – what are the margins I should be working within? If my EDM has over 20 images in it should I be worried that some won’t load?

To the laboratory!

Okay I don’t have a laboratory. In fact I kinda hoped that by raising the issue with Campaign Monitor they might carry the torch, but alas:

@craigrozynski I’ll let you know if anything comes across my desk, def one to think about here ^RH

They are certainly better equipped to produce meaningful results, but they’re all very busy people. So, what’s the best I can do to get the ball rolling?

The criteria

1. What is a safe file size limit for an email design?
2. Does the number of http requests have an impact on loading images?
3. How do they compare on different connections?

1. Image size test file

1.1 100kB image
1.2 200kB image
1.3 500kB image
1.4 1000kB image

2. Http requests test file

2.1 5 images totaling 200kB
2.2 10 images totaling 200kB
2.3 30 images totaling 200kB

3. Connection type

3.1 Standard cable connection (100mbps)
3.2 Mobile 3G
3.3 Mobile Wifi

I’ve only tested with one email client, Apple Mail for the standard cable connection, and iPhone iOS for mobile 3G and Wifi. Given that different email clients use different rendering engines, I can only assume results vary across email clients, but that’s a test for another day.

Results

Image size test file  (Ranked out of 10, where 10 is the fastest load)
	100kB	200kB	500kB	1000kB
Cable	10	10	10	10
3G	10	7	7	5
Wifi	10	10	7	10

Findings

Judging by these results we should have no qualms about sending out a 500kB email. A 1000kB email would perhaps test the patience of someone checking their email on the move. Still, it was only a matter of seconds.

The amount of http requests made had no real effect. The most images used was 30, although they were all the same image. I’m not certain whether Mail and iOS redraw the same image from cache or call it from the server 30 times. A better test would’ve been 30 individual images.

What bothers me is there’s no evidence here of why images occasionally, and intermittently, fail to load in an email? That mystery is yet to be solved.

What is it?

• A HTML5 fluid grid framework whose units remain square.
• Column widths increase or decrease to suit your display size using Media Queries.
• It’s Mobile First, CSS is written for small displays, with Media Queries incorporated as display size increases.
• It works on all modern desktop browsers, as well as iOS, Android and BlackBerry’s mobile WebKit browsers.
• Uses css3-mediaqueries.js to work in IE or any browser that supports JavaScript but not Media Queries.

Check it out here www.fluidsquares.com or download fluid-squares-v2.0.zip (24kb). Use it or modify it any way you wish.

What problem does Fluid Squares fix?

Without a fix, the result of reducing a browser window’s width squashes a fluid grid’s squares into rectangles:

To fix this each unit’s padding-bottom size is set to match its width in percentages. On top of that each unit is a percentage of the global container to determine how many columns there are.

Setting a unit’s width to 25% and padding-bottom to 25% will give you four units in a row that will remain square regardless of screen size or browser window resizing.

What changed in version 2?

The original version of Fluid Squares used transparent images with max-width:100% to make a box stay square in a fluid grid. Thanks to Marco Lago’s (@marcolago) clever update, transparent images are now history thanks to a few clever lines of CSS:

#unit {
  width:50%;
  padding-bottom:50%; 
}

Marco writes on his blog:

It is possible to make full CSS fluid squares without images hack or javascript workarounds? YES! Just think how paddings (and margins) works in the box-model definition. If the vertical paddings (and margins) are specified in percent (%) values the size is a percent of the width of the containing element. So if you write: width: 50%; height: 0; padding-bottom: 50%; you get a fluid square box with only a three row CSS declaration.

The ingredients

HTML

The basic structure of each unit is a div for content, which is nested in an anchor element:

<a href="url">
  <div>content</div>
</a>

If you don’t want the entire unit to be a link, a class has been created for that purpose. Just add class=”category” to the div and remove the anchor element.

CSS

Media Queries control the number of columns displayed (1, 2, 3, and 4) on browser resize, as well as providing fine control over font sizes.

As far as support goes, Safari 3+, Chrome, Firefox 3.5+, Opera 7+, and IE9 all natively parse Media Queries, as do more recent mobile browsers such as Opera Mobile and all those that run on mobile WebKit. For older browsers and IE less than 9, Version 2 of Fluid Squares uses css3-mediaqueries.js, which makes any browser that supports JavaScript interpret Media Queries.

I’ve also cut down a css reset to bare basics to suit this bare bones grid, customise this to suit your needs.

iOS Safari bug fix

A bug in iOS Safari causes text to run off the screen when switching from portrait to landscape orientation. A JavaScript Safari zoom bug fix fixes this, but I’ve used the non-JavaScript alternative, which is to disable user zooming: <meta name = “viewport” content = “width=device-width, maximum-scale=1“>. Preventing zooming generally isn’t a nice thing to do to a user, but because Fluid Squares uses Media Queries to tailor the layout and font sizes for the mobile device this isn’t a problem. If you wish to support mobile browsers that don’t run on mobile WebKit, use the JavaScript fix instead.

No shiv?

While it’s HMTL5, a shiv isn’t required because it doesn’t use any of the new HTML5 elements. If you want to user <header>, <nav> etc include a shiv. Browsers that don’t natively support new HTML5 elements will then treat them as blocks and allow styling. Consider Remy’s Shiv and Modernizr.

No wrapper?

It uses the body tag as a wrapper, but would certainly work within a standard div wrapper or new HTML5 block elements.

Icons

ico and webclip files are included in the directory. Frustratingly I could not get my Android emulator to display a Web Clip icon when saving a bookmark to the home screen, so removed the apple-touch-icon link rel tag from the head. Matthias Byens has written a thorough article, ‘Everything you always wanted to know about touch icons’, on a subject that is much more convoluted than it should be.