Tuesday, February 13, 2007
Wiki-enabled Print Publishing System
Wiki and other web-based collaboration platforms have been on the rise over the past few years. Wiki platforms have proved to be a successful tool in socially driven open content environments. The best known wiki, Wikipedia has accumulated over 1.6 million documents since the project began in 2001.
Building on the success of Wikipedia a number a niche wikis are springing up to provide rich information resources on a number of topics. For example, RocWiki, a community wiki for Rochester, NY will soon reach 3,000 pages of content contributed and edited by local Rochesterians. While Wikipedia has an article on Rochester, it does not match the clarity that RocWiki provides.
The adoption of the wiki is not limited to internet communities and open content movements. Wikis are also being deployed by business to meet their enterprise publishing requirements.
This means there is a lot of structured content in databases and some of it wants to, needs to, or will eventually be printed.
Viewing articles in a wiki is currently confined to the web pages used to mange the content. There are currently no methods to easily print or make the content portable. One could certainly visit and print desired pages from a browser or copy and paste content into document composing application such as Microsoft Word or Adobe InDesign. But this not efficient.
Some wiki engines allow you to individually export pages as a PDF, but this is just a tedious as using File, Print in the browser.
Another method is to engineer an intelligent publishing system to facilitate the selection and assembly of documents from content in the wiki. Depending on the application requirements of the document, the final output could be in a format suitable for printing on a desktop printer or a document ready for submission to the web-to-print system of a print service provider. Or it could be in some other portable document format ready to be displayed on a PDA or e-reading device.
What are the document technology requirements for this type of system?
Wiki engines come in many flavors, some are designed for specific applications (MediaWiki), many are designed to meet the general requirements of most. A majority are open source, some are proprietary and only available via ASP or SaaS models. A wiki comparison site, WikiMatrix lists 81 different wiki engines that are considered stable and ready for every day use.
This means there are 81 different different implementations in a variety of programming languages with 81 different wiki markup languages (the human editable syntax used to give structure to content in a wiki), and 81 different data storage methodologies (most use a SQL-based database).
So how do you develop a print publishing system to interface with all various wiki implementations? You don't. You develop a normalized input format that the print publishing system uses to create its page description lanaguge (PDL) files. So what does this normalized format look like?
MediaWiki provides a format, but I'm not sure this meets the requirements of a publishing system.
A presentation-neutral XML-based content and metadata format needs to be developed to adequately describe information stored in a wiki. The Atom Syndication Format (RFC-4287) might meet the requirements. Or it could provide guidance in the creation of format that would meet the requirements of a system.
Theses are some issues I hope to examine over the next year. I plan on using PrintWiki as a proving ground to test out a prototype.
Posted in: Web-enabled Print
6 Comments
Hi Adam,
Who and why would want to print wiki pages?
Comment by Max - Tuesday, February 13, 2007 at 07:28 PM
A simple enterprise application is the use of a wiki to manage the editorial process of a book.
A print applications outside enterprise could be the use of a Davis Wiki to produce a customized visitor guide to Davis, CA.
Comment by Adam - Tuesday, February 13, 2007 at 08:44 PM
To continue Adam's points, part of this is breaking out of a "mass production artifact" print model. By that I mean, that a piece of print needs to have thousands of reproductions and is intended to last forever.
Once we move beyond that, print becomes another portable document container (differentiated from the ubiquitous .PDF).
Then the question becomes, what are applications where it is useful to temporarily liberate content from the constraints of a Wiki (needing to be online with access to some form of web browser). A "small city" guidebook is an excellent example of such a use (especially for a business traveler on an extended stay in a city they may never return to).
Comment by Matt - Thursday, February 15, 2007 at 01:03 PM
This type of thing is already being done by a few groups online with blogs (via Blurb, BlogPrinting, and Qoop). Qoop is also doing book composition via a number of different photo sites, inlcluding WebShots and Flickr. I would say it's highly feasible to do the same with Wikis.
In terms of the blog printing, I feel like if I used a tool like Blurb's BookSmart to build my book, I would be somewhat limited in my abilities to get the exact design that I want. However, dynamically flowing this content directly into InDesign would be an ideal scenario, and InDesign Book file support (.indb) would be amazing.
Maybe there's already a solution to this that I'm totally missing, as I've been fairly busy and haven't been able to really look into it.
Come to think of it, the wiki-to-print thing could be quite amazing. I'm going to Grenoble, France over spring break. Let's say there's a Grenoble Wiki with a wiki-to-print module. I could browse through articles, and as I'm browsing, I can add articles to my "WikiBook" cart so-to-speak, and then at the end, request an on-demand book of those articles. Or I could choose the most highly rated or most popular articles to be put in a book, or just order a static book put together by the admins of the Grenoble Wiki.
Let's take PrintWiki as another example. Its content could be the driver for maybe not the upcoming Pocket Pal, but the edition after that. A person could order a Pocket Pal from PrintWiki on-demand, and whatever articles are marked to be in the Pocket Pal would be grabbed and printed. Or if a person has a special interest in printed electronics, it could add this section into the Pocket Pal. There are endless possibilities to integrate print into a wiki.
This would be beneficial to user, as well as beneficial to the Wiki, as it provides a revenue stream that could support the wiki. Buying these books would be like a donation to the wiki.
Pretty badass.
Comment by Bryan - Sunday, February 18, 2007 at 11:23 PM
I don't dispute the technology is cool, but I've yet to be convinced there is an actual market.
On the one-hand, you have the Vanity Publishing market. It's entirely driven by self-generated content, however. I'm not going to pay to publish public Wiki content for my coffee table.
Nor do I think the "custom travel guide" idea is economically feasibly. In all such scenarios, you have to ask yourself how the market is currently being served. Examine the travel guide market. What flaws does it have that a Wiki-to-Print system would redress?
1. Travel guides go out of date.
2. Travel guides might not be aligned with my interests.
However, I'm a traveller. I use and reuse the guides I've purchased. I can't see myself paying to publish a "one-time use" travel guide. It will have the same flaw of going out of date, plus it introduces the flaw that it won't be broad ENOUGH to support repeated visits to an area or a change of plans.
One market that does make sense to me, is the textbook market. Articles are written by a diverse group of authors. Every article needs editorial review. In fact, many different people may need to contribute to an article, and some discussion needs to occur. Using a Wiki for this, and then having a method to finalize the content and publish it, is a very good idea.
Comment by Thomas D. Greer - Wednesday, February 28, 2007 at 07:30 PM
My point, if it wasn't clear, is that Wikis are not going to drive new markets for printing. However, existing printing/publishing markets may definitely find a use for Wikis.
Comment by Thomas D. Greer - Wednesday, February 28, 2007 at 07:36 PM