Archive for February 10, 2014

Monday, February 10, 2014

Scriptnotes on Final Draft

Scriptnotes 129 (via Guy English):

Craig Mazin And so I was a very early adopter of Final Draft. And I stayed with Final Draft through the revisions. And along the way I got disillusioned. And I’ve become increasingly disillusioned. An particularly disillusioned with what happened with Final Draft 9.


Marc Madnick For 10 years we provided free phone support. 10 percent of the people — remember now, I run a business; we have to make business decisions. Okay? We’re in business not to go out of business. — 10 percent of people would call up when it was free with no clock and talk and start asking about their printer not working and how do I get Microsoft Word. I mean, things that had nothing to do with us.


Marc Madnick Take all the bells and whistles out of everybody’s product, all the competitor’s products, okay. Take them all out. What it comes down to is pagination. Period. A minute a page. Break it down in eighths. Right, you guys are directors as well, okay. So, we are trusted because it’s the proper pagination. You get a script, it’s 120 pages, you can estimate it’s going to be approximately 120 minutes. That’s really what it comes down to. Does it paginate properly?


Marc Madnick We made an iPad app called the iPad Writer. It took, ready for this, two years. And you’ll say to me, “Marc, some of these apps that are much less expensive, by the way some of them are even free, they told me they took two, three, four months. Why does it take Final Draft two years?”

A year and a half of that two years was spent making sure that your script of 119 pages was 119 pages there. And also on your IBM, your Windows, I’m sorry, look at IBM, I’m old school.


Marc Madnick The biggest one was about 10 years ago Apple, even though we’re a developer and they love us and we have friends over there, they don’t tell you anything. 10 years ago they made you do Carbon language. And you’re familiar with this. And you had to go down there and strip it, you know, put Carbon in.

I’m not a techie, by the way. But, now they come to us three, four years ago and say, “You need to do Cocoa.” That means a page one rewrite for us. What does that mean to the customer? Well, version 8 they came out with MacBook retina displays. Guess when we found out that our font wasn’t really looking as crisp as it should? When somebody came to our office with a MacBook retina display.

It’s not like we got a call, or they mentioned it to us. We didn’t even know until it happened. So, what do we have to do? We have to spend a year and a half rewriting our software so it works on not only today’s latest Mac operating system […]

Design Details: Paper by Facebook

Brian Lovin:

Paper by Facebook has been out for a day now and the reviews are, for the most part, quite divided. I haven’t been an avid Facebook user for some time, but the design and attention to detail on Paper is unmatched, and is worth sharing with other designers.

The Design Details for Twitter post I wrote yesterday received some great feedback, so I thought I’d quickly compile some of my favorite interactions in Paper - pardon the low-quality GIFs!

Strings, Unicode, Localization, and Parsing

The new issue of is all about strings.

Ole Begemann:

The truth is that an NSString object actually represents an array of UTF-16-encoded code units. Accordingly, the length method returns the number of code units (not characters) in the string. At the time when NSString was developed (it was first published in 1994 as part of Foundation Kit), Unicode was still a 16-bit encoding; the wider range and UTF-16’s surrogate character mechanism were introduced with Unicode 2.0 in 1996. From today’s perspective, the unichar type and the characterAtIndex: method are terribly named because they tend to promote any confusion a programmer may have between Unicode characters (code points) and UTF-16 code units. codeUnitAtIndex: would be a vastly better method name.

Daniel Eggert:

We must never use -uppercaseString or -lowercaseString for strings that are supposed to be displayed in the UI. Instead, we must use -uppercaseStringWithLocale:[…]

Florian Kugler:

When using the NSLocalizedString macro, the first argument you have to specify is a key for this particular string. You’ll often see that developers simply use the term in their base language as key. While this might be convenient in the beginning, it is actually a really bad idea and can lead to very bad localizations.


Good localizable string keys have to fulfill two requirements: first, they must be unique for each context they’re used in, and second, they must stick out if we forgot to translate something.

We recommend using a name-spaced approach[…]


When using date and number formatters or methods like -[NSString lowercaseStringWithLocale:], it’s important that you use the correct locale. If you want to use the user’s systemwide preferred language, you can retrieve the corresponding locale with [NSLocale currentLocale]. However, be aware that this might be a different locale than the one your app is running in.

Chris Eidhof:

Scanning a hex color is the same as before. The only difference is that we have now wrapped it in a method, and use the same pattern as NSScanner methods. It returns a BOOL indicating successful scanning, and stores the result in a pointer to a UIColor[…]