Skip to main content

Using a Database to Manage Writing

I encourage writers, including my students, to imagine creative ways to use technology to support writing. Many aspiring writers keep logs of what they have written, to where they have submitted works, and when works have been published or produced. 

My magazine columns for one publisher are listed in a basic Excel spreadsheet. Sure, this is using the system as a database, but a list of almost 100 columns doesn't require a database. The spreadsheet column headings are: Column Number, Date Submitted, Date Published, Title, Slug, and Notes. The publication dates trail the submission dates by a month to three months. I thought about adding a "Word Count" column, since I'm paid by the word, but the columns are consistently 1000 words, give or take a few. 

Tracking scripts, however, requires more than a spreadsheet. That's because I might have nine or ten works submitted at any moment. Acceptance or rejection might come six months to a year after sending a work to a production company. Many producers prohibit multiple submissions of a work, so you can't send a script to three producers and hope for the best. As soon as a producer does reject a script, though, you want to send it out to the next possible producer. 

FileMaker Pro "Manuscript Tracker 2.0"

Scripts have complex contractual agreements that make traditional publishing look simple. Yes, there's an author's royalty, but there are also residual payments to the first production company, residuals to any dramaturg, flat payments to designers, and more. 

When I said that you need basic algebra skills to make sure royalties are accurate, a colleague laughed. How hard can calculating a percentage of ticket sales be?

The traditional royalty is 5 percent of 90 percent of the weighted average ticket price, assuming an 80 percent box office sales through (whether the theater fills 80 percent of seats or not). Remember that "subscribers" and "educational" ticket holders pay lower admission rates, too. You need to know the ticket prices, the number sold at each face value, and other variables. 
Other royalty rates include a flat percentage on gross ticket sales, a percentage of net ticket sales (which leads producers to claim all sorts of expenses), and a flat fee per performance. There are mix-and-match approaches to these royalties, too. I like to have a guaranteed minimum per show, but also the five percent royalty on gross, whichever is greater per show. 
If a show is being performed at more than one venue, and that is every playwright's dream, you have to track these agreements for every performance. Or, if you get lucky, your agent and publisher handle the royalty collection. 
Because I assign residual rights to others, including the first production company to develop a work, I have to track what I am due, then calculate how much of my royalty must be shared with others. Again, too much to track (for me) on paper. I'd lose the paper, anyway. Instead, I have a table of residuals by work. 
My database design links works to producers and publishers. It then links those business relationships to contract terms. There's more, but overall the system makes my life (and my wife's life) much easier. With a few mouse clicks or touches on the iPad, we can see a summary of all the complex terms and agreements associated with a script. 

Technology… letting me focus on writing instead of the business of writing. 

Enhanced by Zemanta

Comments

Popular posts from this blog

MarsEdit and Blogging

MarsEdit (Photo credit: Wikipedia ) Mailing posts to blogs, a practice I adopted in 2005, allows a blogger like me to store copies of draft posts within email. If Blogger , WordPress, or the blogging platform of the moment crashes or for some other reason eats my posts, at least I have the original drafts of most entries. I find having such a nicely organized archive convenient — much easier than remembering to archive posts from Blogger or WordPress to my computer. With this post, I am testing MarsEdit from Red Sweater Software based on recent reviews, including an overview on 9to5Mac . Composing posts an email offers a fast way to prepare draft blogs, but the email does not always work well if you want to include basic formatting, images, and links to online resources. Submitting to Blogger via Apple Mail often produced complex HTML with unnecessary font and paragraph formatting styles. Problems with rich text led me to convert blog entries to plaintext in Apple Mail

Learning to Program

Late last night I installed the update to Apple's OS X programming tool suite, Xcode 4. This summer, in my "free" time I intend to work my way through my old copy of Teach Yourself C and the several Objective-C books I own. While I do play with various languages and tools, from AppleScript to PHP, I've never managed to master Objective-C — which is something I want to do. As I've written several times, knowing simple coding techniques is a practical skill and one that helps learn problem solving strategies. Even my use of AppleScript and Visual Basic for Applications (VBA) on a regular basis helps remind me to tackle problems in distinct steps, with clear objectives from step to step. There are many free programming tools that students should be encouraged to try. On OS X, the first two tools I suggest to non-technical students are Automator and AppleScript. These tools allow you to automate tasks on OS X, similar to the batch files of DOS or the macros of Wor

Learning to Code: Comments Count

I like comments in computer programming source code. I've never been the programmer to claim, "My code doesn't need comments." Maybe it is because I've always worked on so many projects that I need comments  to remind me what I was thinking when I entered the source code into the text editor. Most programmers end up in a similar situation. They look at a function and wonder, "Why did I do it this way?" Tangent : I also like comments in my "human" writing projects. One of the sad consequences of moving to digital media is that we might lose all the little marginalia authors and editors leave on manuscript drafts. That thought, the desire to preserve my notes, is worthy of its own blog post — so watch for a post on writing software and notes. Here are my rules for comments: Source code files should begin with identifying comments and an update log. Functions, subroutines, and blocks of code should have at least one descriptive comment.