I forget useful code, but Snipt remembers.

If you’re anything like me, you’re not really a Web developer by trade, but you push around a little bit of code on an extremely regular basis.  And often, it’s the same little bits of code over and over again.  And every time you need to use it, you go flipping through text files, Google searches, Delicious bookmarks, and oh, there it was.

Or there’s Snipt:

It’s simple.

  1. Sign up.
  2. Save your snippet of useful, reusable code.
  3. Give it a logical name.
  4. Add some tags.
  5. Find what you need later, quickly, just the way you like it.

Snipt is another fine little piece of usefulness from my friends (and co-workers) who go by the name of Lion Burger.

Howard Weaver’s exit interview

I was struck by a few things in Howard Weaver’s post announcing that he’s leaving McClatchy — and journalism — at the end of the year.

For one thing, Howard’s a damn fine writer.

I haven’t agreed with everything he’s said or done as I’ve followed his blog for the last couple years, but I recognized that he was someone at the pinnacle of a long career in the news business who still believed in the power of newspapers to make positive changes in our world through impassioned investigative journalism, even if it wasn’t profitable and never would be again.

And then there’s a few nods to the obvious in Howard’s send-off:  Google didn’t kill newspapers, Craigslist didn’t kill newspapers, newspapers aren’t dead, there’s more to the problem than the economy.

Howard’s an optimist, probably more than I am, about the future of print, but there’s one important paragraph near the end of his post :

“Nothing else we do as a company means much if we fail to sustain our public service journalism. The McClatchy family has not persevered into the seventh generation in order to publish successful brides magazines, or websites with comprehensive nightclub listings. We labor not to ensure we can create new blogs for pet owners, or rich vertical online sites devoted to vacation properties. All of these and much more are essential, of course, because public service journalism is an expensive proposition, but we must not take for granted the capacity or elasticity of our newsrooms.”

It would be easy to write off that paragraph as a brief rant against spending development cycles trying to build the inevitable platform for hyperlocal cat pictures, but I think he has an excellent point, which I’m about to co-opt and twist:

Spending resources on revenue-generating applications and integrating services that help us serve as a local information utility is important, yes, but if we have a mission as journalists, at some point soon, we’re going to need to funnel resources into development of applications and services that provide more of a public service for readers than a dining guide or a business directory.

Being the best source (with the best SEO) for local information, listings, and answering the frequently asked questions about our block or town or city is important, yes, of course.

But, fulfilling the mission of big-J Journalism (which I believe still can be done, whether or not it’s done by a news organization that puts out a print edition every day) — by doing things like exposing corruption in government, pointing out hypocrisy in the proverbial halls of power, and shining a bright light on the details buried deep in data sets — continues to require more than panel talks at conferences and handwringing editorials, it requires resources.

And by resources, I mean money, time, and Web development teams focused on applications for news.

Which raises the question: Is your organization willing to commit to spending those three things on news?

Technology is easy; labor is hard

Aron Pilhofer of nytimes.com on the hardware, software, and costs associated with building the best interactive data projects in the news business:

Everything we use is free and open-source. Our platform is Ruby on Rails backed by Mysql databases running on Ubuntu servers. The cost here isn’t software, or even hardware, which is relatively cheap these days through hosting companies like Amazon EC2 (on the high end) or Slicehost (on the low end). The price most news organizations (and it’s not just small ones) seem reluctant to pay is for people — developers like the ones in my group who can build the infrastructure to support the rich, deeply engaging web features that so many people love about our site.

Read the whole thing at Old Media, New Tricks.

Dealing with the elephant: Build the software you need, then sell it.

This is the fourth post in a short series I’m pretty much done with about the business model for online news before I go back to my usual routine of pointing out the obvious to people wearing dark glasses.  The starting point, the givens in the equation, are listed here.  Suggest which windmill I should tilt at next using the Skribit widget in the sidebar of my blog while it’s still there.

elephant by droolcup on Flickr
“elephant” by droolcup on Flickr

There’s something funny about software for publishing online news.

Newspapers don’t develop it.

There’s an exception or two to that rule of course, but I hope I’ve force-fed you enough fine LJWorld.com products at this point to hammer that exception home.  (I almost wish they had an affiliate program.)

But usually, instead of spending money to hire developers to build software to match the specifications of their own needs, newspapers and the companies that own them reach out the third-party vendors on a daily basis in order to provide basic functionality to online readers, consumers, and advertisers.

Follow along with me for a moment, substituting your own organization for the Royal We, in the parlance of our times:

  • Classifieds? Let someone else build it, sell it, and profit from it.  We won’t have much input into what they build for us, but we won’t need to worry about the servers or credit card processing.
  • Databases? If we know what to do with them, we certainly haven’t hired anyone who can build them with journalistic intent.  We outsource them, or we trust the one developer in the newsroom who knows what they’re doing to build a framework we can use more than once, or that we can use when they move on.
  • Calendars, content management systems, even project management tools? We seem to have been out sick from school on the day “vertical integration” was covered in AP Economics.

No, I wouldn’t recommend you drop everything you’re doing so you can re-invent the wheel, especially when some of those wheels are pretty darn good at filling your needs for a relatively small short-term price.

But yes, I heartily recommend you build an extensible Web application for the next unserved need in your organization.  Just pick any one of those that pops up in the next month or so, and go at it.

After you’ve launched it and earned the praise of your peers, slap a price tag on a license and get to work marketing it.

You’ve made a long-term investment by hiring developers.  The capital is coming back in the form of the application that’s useful to your organization; think of the license fees for the software as interest income.  You’ll be supporting the software for your own papers, anyway; might as well serve a few other organizations at the same time, for a price.

So ask yourself which software needs are going unmet in your own organization.  If you can’t find the right tool for the job, chances are, no one else can either.

A caveat: I’ve given out a lot of advice (some of it unsolicited) to newsrooms about using free, Web-based tools for online news production.  I still think that’s the right approach for many news-related purposes, but as soon as you find yourself paying for a mediocre service that’s part of your core business routine, it’s time to build something better.

Working with developers and designers

I wrote a post for IdeaLab earlier today.  It’s a short update on ReportingOn development, framed as a weighing of the pros and cons of a few different development platforms.

It occurred to me near the end of it that I should treat this project as if the developer was someone other than myself.  (Yes, at some point in the next year, I’m planning on hiring out some design work on the site, and possibly some development for a specific purpose or two, but not right away.)

So here are five tips for working with Web developers and designers:

  1. Content is king:  Your new hire or freelance pal can’t magically build a site out of nothing.  You need to know exactly what type of content lives on your site.  That doesn’t mean you need to write a bunch of fake entries or create phantom profiles, although that couldn’t hurt.  It means you need to know what belongs in each space on the front page, and where the links on that page lead.  Please don’t tell a designer what you want “it” to look like if you haven’t talked about what “it” is.  This happens all the time.
  2. Start with a pencil:  That’s right, it’s time to whip out ye olde dead tree times two — paper and pencil.  Personally, I prefer swiping a sheet of 11×17 from the nearest printer.  Lots of room for notes at that scale, plus, you’re going to want to draw all sorts of crazy arrows and add captions and numbers and diagrams and… maybe that’s just me.  But either way, this is your first prototype: Paper and pencil.  Pen if you prefer to live dangerously.
  3. Prototype in HTML if you can:  If you know enough HTML (and preferably, CSS) to build a little dummy page with links that go nowhere, by all means, do it.  Not only will this exercise help you build out a map of your site, showing you and your developer friends what needs to be a link and where it might lead, but if you’re good with HTML and CSS, these dummy pages might even become templates you can plug dynamic code into later.
  4. See more than one option:  Once you’re relatively settled on branding and a rough color scheme (stick with words for colors at this stage, not hex codes), you’ll want to see multiple iterations of the design.  Consider these rough drafts, not final products to accept or reject.  Now is the time to finalize that color scheme, make some decisions about where to place those blocks of content, and eliminate any features that feel superfluous.
  5. Don’t pixel-push:  Seriously, do you really think it’s going to matter in the end whether or not there’s just a little bit more whitespace around that heading?  It’s not going to matter to your users.  If precise design and perfect typography is your thing, hire someone who is an expert at putting those elements in just the right spot.  It’s nice if you can get it all looking just the way you pictured it in your head, but you should really just hire people you can trust, and then trust them.  Chances are, they have built more of these than you have, and their judgment (and experience) is there for a reason.

And a bonus tip: Pay attention to the dominant trends in Web development and design.  If you’re involved at all in the building of Web sites these days, you should at least be taking a cursory glance at A List Apart, 37signals, and the work of Khoi Vinh, Dan Cederholm, and everyone you see in the blogrolls or posts on all these sites.

The goal here isn’t to throw around buzzwords; it’s to better understand the real words your developers and designers are using.  Don’t say “AJAX!!!” without reading about it first, for example.  You’ll have a better time talking with the construction crew if you have some level of familiarity with the materials.

Your tips for working with humans who work with code?

In the comments…