Behold, the Uber-Project
I really like working on Langosta. It’s a project that suits me perfectly - something to work on on the side when I’ve got time, a relatively small project that isn’t impossibly complex and difficult to add new features to. However, Langosta has one fatal flaw: the only person it really benefits is me. In the past, it has always been the projects that I’ve done for others (such as my old high school’s website), usually for free, that have resulted in major payoffs for me in the end in the form of rewards like academic credit and a job. I’ve been attempting to find a new project like this for a while now, but a number of things, ranging from a lack of time to preoccupation with Langosta to my inability to work on any major projects for my school, kept me from succeeding in doing so. Now, the opportunity has finally come.
For me, my work on the school newspaper at OHS has become an almost exact replacement for the work I used to do on the CSHS website. However, it’s highly cyclical, and I don’t think I spend anywhere near as much time designing the newspaper as I used to spend maintaining and improving that website. Also, while the newspaper teacher has let me know repeatedly that my work is appreciated (and has bribed me with caffeine, of course), the average reader has no idea that I even exist and probably could care less about things that I nitpick about, like making sure that a line is positioned “just so” and that lines of text line up evenly across the page. So, in an effort to redouble my…um, efforts, I’m going to develop a new piece of web application software over the next year that will hopefully streamline the newspaper publishing process considerably.
The Problem
Currently, submitted articles follow a sorta-kinda-well-defined path to being published in the newspaper. It works like this:
- Students write their articles on computers at home or at school, using Microsoft Word.
- Students copy the Word document to a special folder on the school network’s common drive and fill out a form called a “tracking sheet” with information about the article such as: author(s) name(s), section, pullquotes (if any), and headline / subheadline.
- The article is edited up to three times by different editors, with the number of editing rounds depending on the article’s writing quality.
- The article is approved by the managing editor (the newspaper teacher) and the tracking sheet is put in a basket according to the article’s proposed section.
- A team of editors meets and runs through every article, assigning it “first wave”, “second wave”, or “third wave” priority.
- The design editors (me and usually one other person) divide up our pages by section and begin placing articles in their corresponding sections, using largely our own judgment and to some extent the priority guidelines given to us by the editors to determine which articles get the most important spots (front page, back page, above the fold in any section, etc.).
- As each article is placed, design editors are responsible for fixing last-minute editing errors and solving any issues such as finding photos for articles and giving them captions.
As you may or may not have noticed, there are some major issues with this method:
- Huge amounts of paper are wasted because each article is printed multiple times while it is being edited and all 60-odd articles submitted for each issue have their own tracking sheet.
- A lot of work falls to the design editors in the final days before publishing, usually because of writers’ laziness (it’s not that difficult to request that a photographer take a picture for your article or to fix simple spelling or grammar mistakes) and because the editors’ prioritization system remains somewhat vague. First-wave articles can vary widely.
- Tracking sheets are easily lost and difficult to deal with / search through. I don’t like spending precious minutes on a deadline day rifling through tracking sheets looking for an article that will fit in a certain spot.
The Solution
The bigger issue that causes all of the above problems is the “hole” in the article’s path to being published where the process switches from digital to analog/paper and then back. It would be vastly easier if we could simply making the entire process automated and digital. Enter, Gabo, the latest project in the Brettia family, named with yet another Spanish word. This time, it’s a nickname for famous journalist and writer Jorge Luis Borges. Here’s what Gabo will do:
- For Writers:
- Article submission is now done via the Internet (both more convenient and easier to manage dynamically).
- Articles can be flagged for extra editing by specific editors, if necessary.
- Articles have requests for photos attached to them.
- Articles can be revised on the website, with no printing necessary.
- Article metadata (proposed section, headline, subheadline, pullquotes, etc.) can be added and changed at will.
- Articles can have notes or comments attached to them that are directed to users of certain roles (such as layout suggestions for design editors, editing questions for editors, journalism questions for the managing editor, etc.).
- For Editors:
- A listing of all articles awaiting editing will always be available.
- Articles can be tagged with priority levels or rated to establish which ones are the best.
- Articles can be sent back to their writers with comments for further editing.
- For the Managing Editor:
- A list of all articles awaiting final approval would be available.
- (Can do anything that a normal editor can do, basically, as well as give final article approval.)
- For Photographers:
- A list of all articles awaiting photos would be available.
- Photographers would be able to attach photos (with captions) to articles.
- For Design Editors:
- Articles are now searchable, categorized by section, rated, and have photos by the time they reach the design editors’ listing.
- And the hidden link that makes it all work: InDesign can import articles as XML; to place an article, design editors would simply download the XML file (generated dynamically) and then place the article like they always have (except with no more dirty work).
So yeah, that’s my new proyecto grande. But even more is possible. Think for a second: how could a huge online database of every article ever submitted, along with all the necessary metadata for publishing them, ever be useful for anything but what I’ve described already? I’ll give you a little longer before I tell you…. Okay, long enough: the database could be used to build an entire website for the newspaper, dynamically. With basically no more work than what is done to produce a print edition, an online edition of the Cooney Crier could by published simultaneously. This opens up all sorts of new avenues of growth, such as online advertising and school event promotions. Also, writers whose articles miss the metaphorical boat for the print edition could still be available online (assuming they have final editorial approval), giving them a bit more incentive to write, even if their articles aren’t the best.
When I thought all this up, it was a random Saturday in May, and I was so excited by the idea that I could barely contain myself. Now that the idea has had some time to percolate in my mind, the excitement still hasn’t gone away, and I’m already planning for Gabo 1.0 (just the backend stuff, not the public website) to be finished by September 22nd. So I ask you, dear reader, what do you think? It it unique, incredible, worth pursuing? Or have I just been carried away by excitement at a concept that really isn’t that wonderful?
As far as difficulty goes, this project definitely is the hardest one I’ve ever attempted, at least on paper. However, I have advantages now that I didn’t have a year ago, such as Sangre, my collection of core libraries that will hit 1.0 on the same day as Gabo and then become its own project separate from Gabo and Langosta. At the same time, though, Sangre isn’t perfect. I’m working currently on several improvements, such as object-relational mapping, a way of representing data in a database and relationships between bits of data as objects in code (Ruby on Rails does this), full modularization of all code into actions and views, and a better authentication layer with support for user roles and permissions (these roles would be used to control what a logged in user can and cannot do depending on their job, such as writer or photographer) integrated into views and actions, database-stored sessions, and support for multiple authentication backends, such as LDAP, PEAR::Auth, the phpBB authentication system, or pretty much anything else. It’s a lot to do, but I have a whole year to get it right. Also, this project will be a much higher priority for me than Langosta ever was because bugs will impact more people than just me and the ten people who visit my site each day.
Anyway, don’t forget to comment if you have any opinion on this, otherwise, see you next entry (which I’ll be writing soon, I promise!).