Dear Bohemian Coding, please fix Frank.

Update: Friday, November 16, 2012. New Fontcase release imminent.

Received an email from Pieter Omvlee. An update for Fontcase has happened, but is being held up in Apple’s review process.

Due to Sandboxing issues, we need slightly more permissions than Apple seems willing to give us.

You can however download a beta directly from their site: www.bohemiancoding.com/fontcase/beta

The beta fixes issues in font activation, makes Fontcase work (and look) better on Retina Macs and has more general fixes and improvements overall.

Plus we get some reassurance on their commitment to Fontcase development:

Lately Sketch has taken up most of our time, but we haven’t forgotten about Fontcase at all; we’re still committed to continue improving it.

Thanks Peter!

 

Hello

Photo of Frank

I’ve worked as a commercial graphic designer for 14 years. I started out designing print ads for real-estate agents with Quark XPress. I now design web apps for mobile devices. Woop-de-dah.

Regardless of the medium I’m designing for, I need Frank (pictured).

Frank is the quiet little subordinate dude. He’s always pushing his glasses up his nose. He shies away from conversation. I’m not sure he even has a personality, but that’s cool. Because he does his job real well. Quietly. Reliably. The stuff you need is always there when you need it.

Thanks Frank.

The first Frank I had came from a place called Extensis Suitcase. Excellent for years before he got a bit old and senile. We had to get rid of him.

Then the new replacement Frank showed up, he came from Linotype Font Explorer. He really gave it his best shot in the beginning. Okay he was a bit uptight, but Employee of the Month six times running? Sheesh. You can’t beat that can you.

Then something happened, some cracks started to show in Frank’s professional veneer. To be honest his customer service was always a bit off. Then it all came to a head when I caught him trying to shag the photocopier at the 2011 Christmas Party. We had to let him go.

The new Frank showed up. He’s from a place called Bohemian Coding. His friends call him Fontcase.

This Frank’s got style. Cambridge bow ties and a lovely Argyle sock collection. He started out so amazing. Quietly. Reliably. Everything was always there when I needed it.

But it’s what’s inside that counts, and I’ve got to say Frank, you’ve let me down. You’ve developed a habit of breaking my concentration. I find myself having to help you with your own petty issues instead of solving my own creative problems. All I need is someone to go about their job and get it done without any fuss. If you did your job well I might even be happy to turn a blind eye if you enjoy the occasional stick-your-jolly-roger-in-an-office appliance thingy.

I want to believe in you Frank. I certainly can’t go back to the old Franks. When I mailed you explaining these issues, your assistant replied (bold italics mine):

From: Pieter Omvlee

Subject: Various bugs in Fontcase

There are known bugs in Sketch and we are working on an update to fix them. 2.1.2 is waiting for review and after that we might get round to fixing these.

My apologies for the inconvenience.

Not cool Frank. I had no idea you were working a second job. I need you 100% on my font management. You “might get around to fixing” my issues? What the hell am I paying you for?

So let’s get this straight. Are you still committed to font management? Should I wait around for you to lift your game, or go and find another Frank while you fret about your second job? Are they cool with your photocopier thing?

C’mon Frank, square with me.

Craig Rozynski

Uncategorized

November 15, 2012

Leave a comment

How much does it cost to use a font in my iOS app?

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/

Uncategorized

November 6, 2011

2 Comments

What’s a good file size for an email design?

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
Http requests test file (Ranked out of 10, where 10 is the fastest load)
5 images total 200kB 10 images total 200kB 30 images total 200kB
Cable 10 10 10
3G 7 7 7
Wifi 10 10 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.

Uncategorized

September 22, 2011

2 Comments

Fluid Squares V2

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.

Develop, Grids

, , ,

July 18, 2011

21 Comments

iOS App Design Workflow: Part 2

I’m turning a website for traveling surfers, www.surftourist.com, into an iOS app. It’s the first time I’ve designed for iOS, and I’m building my workflow – setting up shop – for future projects. This post follows on from iOS App Design Workflow: Part 1.

Keeping in touch with the team online

I’d recommend using Campfire with Propane for online team communication, although on this project we’ve been using Skype — out of laziness perhaps — but as we’re building it for ourselves it’s a bit more of a casual arrangement. If you are using Skype with multiple users be careful – it doesn’t save the contents of a chat between more that two people. Yes, I did find that out the hard way.

Remembering everything

Ideas and key points from conversations get pasted into Evernote. I’ve tried Yojimbo and Together – digital scrapbooks – but settled on Evernote because it’s development cycle seems to be the most active. If you’d like to try an alternative check out Together. I also recommend Yojimbo vs Together vs Evernote: a review.

Information Architecture: Sketches

The features and direction weren’t defined well enough to jump straight into wireframing, so I sought feedback from sketches first. The sketches were rough enough not to waste time but clear enough to get the ideas across.

For the novelty of it, and a little added convenience, I sketched on an iPhone App Sketchbook from appsketchbook.com. On standard delivery it arrived in two weeks – far too long. If you’re not in the States get it sent express.

Also check out UI Stencils’ stencils and notepads. UI Stencils iPhone Sketch Pad doesn’t provide enough room for adding comments and notes to screens for me, but they have got great products including a dry erase board with browser chrome, a really great idea.

Information Architecture: Wireframes

The sketches triggered discussion. Once there was general agreement I produced a new round of rough sketches for my own use that covered every screen of the revised app.

The approach I’m taking to the user experience on this project is more casual than what you’d find at a UX studio, which would be defining personas, scenarios and user testing in a more scientific, methodical way. If you’re interested in those processes there’s plenty of fantastic resources online waiting to appear in a results listing. See No excuses – budget usability testing for a start.

Until this project I’ve used Indesign for creating IA documentation — very much a designer’s approach. Professionals advocate Axure, but I was hoping to find something that was more mobile app aware. See The search for the perfect IA application if you want to read a little about Balsamiq, Omnigraffle and some of the other available options. The tool that best suited what I was looking for was FlairBuilder.

The most attractive feature of Flairbuilder is the ability to push a working prototype online with the click of a button. This was a major plus not least of all because our team is spread across Australia, Scotland and Japan. Another great feature is a component library that includes mock iPhone UI elements and device artwork.

Flairbuilder runs on Adobe AIR. Despite some fiddly bugs, which were noted and sent to the developer (who has promised they’ll be ironed out in the next release – thanks Christian!), the app was intuitive enough that I had a 40 screen iPhone IA/prototype with site map built in two days.

Not only could I create a working (clickable if you like) prototype, the ability to add interactivity meant that I was able to create user scenario paths that the other team members could click through. The team could forget about navigating the IA and focus on experiencing how users would complete specific tasks.

I love crafting user experiences, and writing front-end code too for that matter, but what people know me for is interface design. Looking ahead to commercial projects I’d like to partner with a UX team. If you have any recommendations leave a comment or dm me.

Thanks for reading. The next article will focus on interface design. Do you build apps and have suggestions for a mobile workflow? What’s your advice?

Design, IA, iOS

, , , , ,

June 26, 2011

2 Comments

WebInk vs TypeKit

Extensis, the outfit known for its font management software Suitcase/Fusion, launched a web font service called WebInk in August 2010.

After a quick snoop around WebInk’s website the two main differences when compared to Typekit are JavaScript not being required to run, and pricing structure.

If you’re a Typekit user like me you’ve been adding two script tags to every page that uses web fonts. Not particularly efficient. WebInk simply uses the @font-face rule in your CSS to load fonts from their server, like this:

@font-face {
font-family: Grotesque;
src: url('http://fnt.webink.com/wfs/?drawer=SSDFR111-0000…&font=ANRVDHQ-VFDSN…');
}

BUT, (that’s a big but btw) one of the benefits of Typekit’s script is that it hides the Flash Of Unstyled Text (FOUT) by concealing the text until it’s ready to display styled. Ironically WebInk provides a script called FOUT-b-gone via its blog to fix this, so technically their “No JavaScript” claim is BS. The problematic browsers in question are IE 7-9 and FF 3.5 and 3.6. Other modern browsers have already pulled into line, so eventually FOUT will be a thing of the past, the script can be deleted and we can all forget it ever happened.

The next main difference is pricing. Typekit charges an annual fee, WebInk is monthly. Typekit calculates bandwidth based on page views, Webink on the actual amount of bandwidth that’s been used serving the fonts (at least that’s how they distinguish it in their plans).

WebInk’s pricing plans:

If you’re hosting a personal site that’s getting less than 5000 visitors a months, Webink would be the marginally cheaper option at $23.88 to Typekit’s $24.99. Negligible. WebInk’s monthly pricing means if your bandwidth varies wildly from month to month your fee will too – check your credit card statements. Typekit state on their pricing page if your bandwidth is exceeded they’ll contact you to recommend a different plan. It does give the impression that WebInk’s fee is more prone to fluctuation.

Typekit’s pricing plans:

Obviously other factors such as font libraries and their browsing experience, and account management also needs to be taken into account. WebInk isn’t ground breakingly different enough to Typekit for me to switch my existing sites over. I’m keen to give it a go on a future project to fully understand the subtle differences.

Personally I also prefer Typekit’s website to WebInk’s (seriously guys, Futura?). Any product or service whose customer base are designers can’t afford not to be obsessive over their aesthetic presentation, and I find the WebInk site a little gloomy. Was using Futura a conceptual statement? It’s a classic typeface but it just doesn’t work for me in this context. (Jim Kidwell from Extensis points out that the fonts used are Proxima Nova and Foco, my bad.)

Typekit.com and WebInk.com

Uncategorized

,

June 13, 2011

2 Comments

iOS App Design Workflow: Part 1

I’m turning a website for traveling surfers, www.surftourist.com, into an iOS app. It’s the first time I’ve designed for iOS, and I’m building my workflow – setting up shop – for future projects.

Step 1: Read the instructions

It took a couple of afternoons to read Apple’s iOS Human Interface Guidelines. I got a bit carried away taking notes and ended up publishing a seven part article, which reformatted the guidelines specifically for designers. It’s been getting roughly 100 hits a day, and is the second result after Apple on Google for iOS Human Interface Guidelines. If you’re reading the HIG, check it out.

Step 2: App Def

Create an App Definition Statement. Challenge yourself to make it as short as possible.

We wanted our app to:

  • Let surfers search for surf spots.
  • Create and maintain a surf trip itinerary.
  • Share their trip progress and surf spot discoveries.
  • Give surfers the ability to record their regular day to day surfs.

If that sounds like a lot for a mobile app, you’re probably right. Regardless of it being ambitious or crazy, I managed to whittle it down to the following App Definition:

Plan your surf trips. Share your surfs.

Step 3: Feature List

1. Plan your surf trips
- Search surf spots via either map or country
- Collect spots into trips, check in to those spots during a trip

2. Share your surfs
- Share your regular surfs and trip surfs with comments, ratings and photos

For the purpose of this article that should do. I continued to break the features down into finer detail, turning features into functions, separating functions into groups, and began sketching a basic Information Architecture.

Next: iOS App Design Workflow: Part 2. See what tools I used to create the Surftourist Information Architecture.

Design, iOS

, , ,

June 2, 2011

Leave a comment

« Older posts
Follow

Get every new post delivered to your Inbox.