Printer's Problems with Adobe Fedex Kinko Plugin & Google Maps Microformats

I’m pretty much speaking out of the business domain I understand here. I don’t know about the US printing industry.

Disclaimer out of the way, apparently many printers are quite upset at one of the recent features in Adobe Acrobat: there’s a little icon that allows you to send a print job lickity split to a Kinko’s.

See this brief text write-up and audio from Monday’s Marketplace.

The Web to the Rescue

It seems to me that there’s the chance here for some microformats and web services here, namely in the form of Google’s recent announcement that they’ve added hCards to Google Maps. An “hCard” is essentially a programatic way of marking up contact information. That is, address, phone number, and other information for either individuals or businesses. (Sure, non-profits too: “organizations,” how’s that?)

So, my thinking is this. Instead of just making that magic “send to Kinko’s” button go to Kinko’s, why not do two things:

• Come up with a simple XML service descriptor that describes the printing services a printer provides and how to submit jobs for printing. The submission can be through a web service, or as many of the “smaller” printers say they do good business in, email.
• When an Acrobat user clicks on that “send to printer” button, allow them to search for printers on Google Maps. At that point, if they find an printer they want to use, they can save the hCard locally (or just click on it if MIME types will load up Acrobat).

At that point, Acrobat would get the URL for the printer from the hCard, and then look up that simple XML file at a “known” URL, like, http://www.theprinter.com/acrobat-print.xml. It’s the same KISS principal behind robots.txt. That is, it the format and use/deployment of the file should be easy enough to cut-n-paste, to not have to be a programmer or hire someone to do it.

So, Acrobat has allowed the user to find a printer they want to use through the familiar and easy to use interface of Google Maps, looked up how to send a job to that printer, and then with some more hand-waving, Acrobat can actually send off that job, even via email.

Decentralized control that’s good enough

For me, the key is to decentralize the discovery of printers from some sort of Adobe (or whoever) managed store of printers. Indeed, the idea isn’t tied to Google Maps at all, that’s just one way of many to get the URLs, and, thus, look-up the little printer service descriptor. Also, it allows the printers to help themselves (read: costs Adobe little to nothing maintain, heck, Adobe could even sell a little product/add-on to edit and publish that file).

Now the big thing here is the expectation that “everything will go fine.” I’m sure a large part of the time and effort put into the “print to Kinko’s” button in Acrobat is making sure user’s know what they’re paying for and that the job gets through. Submitting a print job through email is far from the sure thing that a fully web service outfitted method is.

And yet, people trust email just fine…at least according to the reports from the pissed off printers. That is: maybe the reliability of email is just fine in favor of a very loosely coupled way for Acrobat users to pick which printers they want.

Really, they’re just saving cut-n-pasting their PDF as an attachment to an email, but, hey, maybe that’s a big deal when it comes to printing work-flow.

Disclaimer: Adobe is a client.

Technorati Tags: printing, adobe, acrobat, pdf, microformats, webservices, goodenough