Case Study: Review Builders
As with all of the case studies involving projects that I attempted prior to 2010, what you’re about to read is the product of my memory, some notes that I’ve dug up, and some old website files that I kept in an archive. I hadn’t intended, at the time, to do a public case study on these projects, so please bear with me. Projects from 2010 onward are far more detailed.
( 2007 – 2008 )
When I started the Artistic Opinions project, I knew that I wanted to have each Imagekind.com art review that I wrote to have the same format. The title of the work would be followed by the artist’s name, then a block of text, then the artwork itself, then the credit line under the image, then another block of text, then a closing. Having been interested in programming for a few years, I tend to look at any repetitive action I do on the computer as scriptable and I try to automate the process.
I didn’t know much PHP at the time, but I decided that writing a little script that would generate HTML code that could be plugged into WordPress would be pretty do-able. I started by creating a template for the reviews in HTML, then figuring out where I could insert variables. The title, for example, would be one variable. The PHP script would have an input box on it, I would type in the title of the art, then push the Generate Code button, which activated the script. The script would give me back ready-to-go HTML that included the title of the art in the correct place. That was the way it started.
As I went along, it became clear that having text fields in which I’d type the various properties wasn’t sufficient. It wasn’t automated enough. I chose to look at page scraping. By putting a bit of code in my Firefox bookmarks bar, I could activate my script from the art’s product page, passing the script the artwork’s URL. The script would load that URL’s source code, analyze it, and pull out the title, the artist’s name, and everything else about it automatically – then fill in my various text fields all by itself. Now we’re talkin’. All I had to do at that point was write the actual review and generate the HTML code.
Everything was fine until I told other people about it. Once I did that, they wanted to use it. I customized it so that they could use their own affiliate links. Then they wanted tools for more than just Imagekind. I created similar tools for CafePress, Zazzle, Loxly Gallery, and a couple of others. I found myself learning about APIs because a few merchants offered APIs. I found myself constantly updating the tools because they kept breaking when merchants updated their pages. Less than a year in, I had had enough. I put a notice on the site saying that the tools would keep functioning for as long as the merchants went without changing their pages and that I was no longer supporting the tools. One by one, they broke. I finally shuttered the whole thing in 2009. I no longer own the domain.
What worked
The tools, when they worked, were awesome. Push the button in the bookmarks bar, have the fields populate for you, write your review and hit Generate Code. Awesome.
I also liked the logo, though I have to admit, the font that I used to create it was based on the style used for Neil Peart’s Anatomy of a Drum Solo
What didn’t
Damn, this thing took up a lot of time. I count myself a fair programmer, not great, and when something stumps me, it really stumps me. I know where to go to get help programming PHP, but sometimes the explanations didn’t make much sense. Couple that with the fact that I had a few people constantly pointing out minor bugs and requesting features, and the fact that the merchants (especially Imagekind) couldn’t leave their pages alone for more than a week at a time… it became pretty unmanageable after a few months. Had I been a master programmer, handling the users would have been easy. Had I kept the tool to myself, I wouldn’t have had to deal with users at all. But I promoted it to affiliates in the print-on-demand space, and I got what I asked for – a response.
Verdict
I made under a hundred bucks on this site thanks to a couple of donations, one of which was a monthly recurring donation for a short time. It was nowhere near worth the time I spent keeping it maintained, however… and that is the lesson when it comes to donation-based projects. Be prepared to have your work devalued to the point where you just have to give it up in favor of projects that might actually pay off – either that, or start charging. The people who were using this tool were not willing to pay for monthly access, a phenomenon that I’ll be exploring in more detail in my case study of my time with CafePress.com. Print-on-demand folks are an interesting lot.
If it sounds like I’m bemoaning the amount of work involved, I am. I don’t have anything against work; I am not one to say that the ultimate goal is to make a ton of money without working at all. I’m okay with work. What made me decide to give up the project was not the work, it was the lack of reward and the lack of potential for reward. The concept of work for the sake of work is ridiculous. My talents do not lie in programming, ultimately, and therefore, the reward would never be commensurate with the work.
