Notes on Scriptnotes

February 8th, 2014 | by | screenwriting


On John August and Craig Mazin’s Scriptnotes podcast, a recent subject of discussion was screenwriting software development. They solicited feedback from listeners, which got me, as a listener who has a little experience with the subject, thinking about a few things for which I could possibly provide some additional clarification and particularity.

Starting with:

Scriptnotes probably has a very tech-savvy audience.

I’ve been talking to a lot of screenwriters about technological issues over the last couple of years, and I’ve come to learn just how big the overlap is between the screenwriting-interested group and the programming-aware group. As it turns out, there are a lot of programmers who also write screenplays. (And at least a couple of screenwriters who also program.) And it also stands to reason that the people listening to a podcast about screenwriting are likely to be fairly technology-literate. You can probably assume that a lot of them already have a very clear understanding of what goes into software development. The problem with trying to talk technical is that there might be technical people listening. Not to mention that one of the hosts of the podcast also happens to be in the software business.

Retina didn’t take anyone by surprise.

Mac developers knew about Retina. It was already Apple’s flagship display technology on the latest iPhone, iPod, and iPad, and was a highly touted feature of the mid-2012 MacBook Pro in advance of its release. Not everyone had seen it in person yet — the night a Fade In user got his brand new Retina MacBook Pro and emailed me to say Fade In’s text wasn’t crisp, I remember I certainly hadn’t. But fortunately the Mac developer tools had a utility to simulate high-DPI text through magnification, so I used that to fix it. (It’s called “Quartz Debug” and it’s in the “Graphics Tools” folder, in case anyone had trouble finding it.) Then I went down to my local Best Buy and stealthily downloaded the Fade In demo on a display model to see for myself how that super-sharp text looked.

It would be nice, but software developers don’t get a phone call from Apple about things like Retina. Unless maybe there’s some cut-off I’m not aware of. Maybe every company of 50 or more people (because obviously 40 didn’t hit the threshold) gets personal handholding from the hardware manufacturer to make sure they have their bases covered. But it’s hard to imagine that anyone who makes a living from Mac software was left utterly gobsmacked by the sudden appearance of the Retina MacBook Pro. And in a company of, say, several dozen, surely at least one person has it in their job description to be on top of stuff like that. Or at least be curious enough to go down to Best Buy.

Unicode is not new technology; it is in fact pretty old technology.

For a professional text-editing application to still be limited to 8-bit text is, in 2014, a highly notable deficiency. And for a software developer to mention Unicode support as one of many things they’re looking into for future development is practically anachronistic. Better late than never, I guess, but here’s the thing: Unicode has been around for 25+ years, and in use in major applications like Microsoft Word for 20. It hasn’t taken anyone by surprise, either. It’s not some new, mysterious thing that anyone alone has to deal with. And if this is actually something that people talk about all day long, it’s difficult to imagine what’s left to say about it. Although talking about it is undoubtedly a lot easier than actually doing it.

Using deprecated and discontinued technology will eventually cause difficulties.

Just to correct a misconception in case anyone has it: you can do Retina text in Carbon. So that alone wouldn’t be what’s stopping an older Mac application from supporting Retina text. It would have to be something else.

For instance, if you run that older application in a terminal and see a warning message like:

Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.

that means that the application is using QuickDraw, which is the original 1980s MacOS graphics technology.

If you then dump the strings of that same older application and see a bunch of embedded class names like “LTextEditView” and “LTETypingAction”, that’s an indication that it’s built with PowerPlant, a popular early/mid-1990s classic MacOS application framework.

Now, if that that older application is a legacy 1990s Mac application, both of those things make perfect sense. But then there’s the problem that Retina text is explicitly not possible with QuickDraw. In fact, QuickDraw was deprecated by Apple almost ten years ago, and even that was well after Metrowerks, the makers of PowerPlant, began diversifying away from the Mac development tools game fifteen years ago. Hopefully no one was recently surprised by either.

Here’s the thing about software: you have to work on it continually to keep it up to date. Continually. I guess, maybe, a company could do very well for itself selling older software at a premium price for years without any substantial engineering re-investment, but at some point it’s going to catch up with them. At that point I suppose what a company could choose to do is, having enjoyed those ten years of revenue, put the software development work that probably should’ve been ongoing as the normal course of business into a paid upgrade that gives end users little new (but has some changes on the inside) (at least on the Mac).

Speaking of which, you know what would really suck? To be a Windows user and have to pay the same amount for that same upgrade. And not get Retina. Or full-screen. To maybe get a new toolbar (ribbon) and a handful of minor features. And to have all of that time spent explaining on a podcast what took so damned long and what was so damned hard about the Mac version.

Part of what this highlights is that there is actually a difference between being in the business of developing software and being in the business of selling software.

(Now, if you actually, somehow, had numbers from a company itself saying that only 10-15% of its employees — meaning out of a company of, say, 40 people only 4 to 6 of them — were actually programmers, then that would help give a much clearer idea of exactly where that company’s business focus was.)

Software is hard.

People can easily get confused when talking about Carbon and Cocoa, so let’s make sure we all have our facts straight. Carbon and Cocoa are two Mac application programming interfaces (APIs) that were introduced to developers by Apple at more or less the same time, around 15 years ago, with OS X.  They were meant to co-exist, with Cocoa being the official and recommended API for OS X and Carbon being a way to get classic MacOS applications to run on OS X without being completely ported to Cocoa. Because yeah, there’s some work — a lot of work, to be sure — to port an application of any size from one API to the other. Luckily it’s not like Apple came to anybody only three or four years ago and suddenly told them to start using Cocoa. Apple has always wanted developers to move to Cocoa (even though, notoriously, it took them years and years to port major Apple programs like iTunes and the Finder itself from Carbon). The most famous example, though, was probably of Photoshop, one of the largest applications there is, biting the bullet when 64-bit Carbon was canceled and doing it. That was big news in Mac development in 2007.

So fortunately no one has been blindsided on this, and developers have had years to work on their own roadmaps and figure out what they’re going to do and how and when.

Now, the nice thing about undertaking a huge effort like porting to Cocoa would be that, along the way, if your software has notable shortcomings that really need to be addressed, you can address them. I mean, I can’t imagine it would make any sense to do what some might call a “page-one rewrite” and not fix those things while you’re at it. So at least that’s one big benefit.

But look: whenever someone complains about how hard software development is…well, that person is right. It’s hard. It’s really hard. But it’s really hard for everybody. And everybody figures out how to do the really hard parts and keep going. That’s why whenever I hear of someone running painfully into a programming wall I can only nod my head in empathy and recognition of how many times I’ve done exactly the same thing and pulled my hair out and cursed the very day I first turned on a computer. And how many times it’s going to happen to me in the future.

And it’s sure not like any company ever said anything remotely like:

We have to charge a lot for a minimal update because our code is really old and we’re having a hard time working with it and if we didn’t charge so much we’d go out of business.


Second-last thing:

Fountain is easy.

I put this near the end because, while it might seem minor, I think it encapsulates a whole lot.  Fountain is a very useful thing for screenwriters, as I’ve gone into here previously. And Fountain support isn’t that hard. Especially if you can say that your application is practically there already because you already do basic plain text import. In that case, adding Fountain support should be a no-brainer. Just do it already! There’s no UI re-engineering involved, no porting from Carbon to Cocoa, no magic. It’s probably an afternoon’s worth of work for a moderately competent programmer to tweak some existing text-import behavior, and it will be a great benefit for the people that matter: your users. Again, a no-brainer: providing great benefit to your users at next to no cost.

So what possible reason could there be not to do it?

Well, actually, I can think of one. And that would be if you were so extremely protective of your own file format and the air of sanctity you work so hard to maintain around it, that the very last thing you’d want to do is commodify what your software and file format do so that someone can use any other program to do it.

In that case, John August would be your Che Guevara.

And finally, just to put everything in perspective:

A minimal upgrade for a hundred bucks really isn’t the worst thing a company could pull.

Okay, fine, maybe charging that much money for relatively little end-user punch is more like passing the hat than anything else. And sure, maybe an upgrade like that is basically corporate crowdfunding, and maybe it belongs on Kickstarter instead. (Although people would complain about it there, too. People always seem to take it the wrong way when companies go asking for handouts.)

But you know what would be worse? Let’s imagine a company promising their customers, say, an iPad app, for years, and finally releasing it only to be met with great disappointment because it was a reader only, when everyone had been expecting something they could write with. Let’s also imagine that people were outraged that the company went ahead and still charged $19.95 for that reader-only app. And then imagine the company dropped the price dropped it again until, when they finally did deliver their writing app, the reader-only app was free. Now imagine that the reader-only app was, by the company’s own admission, a technology test of their iOS work for the eventual writer app. And that what happened was that they released it commercially, charging an eyebrow-raising initial premium, essentially getting what cash they could out of their most loyal and eager and earliest-adoptingest customers before dropping the price to zero. (There would probably even be painful Twitter exchanges where a customer couldn’t get the reader-only app to work, and the company rep would dismissively refer to it as their “free” app when the poor customer obviously paid good money for it.)

Yeah, I think that would actually be worse.

Authored by

Comments are closed.

© 2022 Kent Tessman

▲ Back to top