I recently wrote a small piece about Zoho Writer, an online word processor that seems to be the best one around at the moment, unless you have a need for a slavish copy of MS Word in which case you might consider ThinkFree. I looked at it when I was researching a small part of my larger project, which involves envisaging the necessary components for a memi - a persistent online personal dataspace.
Today I had time to look a lot more at it and I found something that completely surprised me, and left me wondering what exactly was going on. The Zoho design team seemed to have solved a major problem without even realising it. In fact, looking more closely I was unable to decide if they had failed to understand the potential of what they have done; if they had understood it but not announced it yet; or whether they had just floated something (in proper Web 2.0 fashion) in order to see what might happen.
Whichever one of these it is, I have taken the bait. I am hooked. Let me explain why.
The memi is supposed to be a life-long personal repository, along lines suggested sixty years ago by Vannevar Bush. If you possessed such a thing and you lived in a connected world of shared networks then a question would naturally arise. Why would you do anything twice? Doing things twice simply guarantees inaccuracy.
For example, if I have my curriculum vitae in my memi, why would I want to copy it to give to you? If I did that then the next time I altered or updated it you would be in possession of an outdated copy. Either I would have to remember to send you an updated version, or risk you continuing to distribute an old version.
In the same way, if I write a paper for an academic conference why would I want to send a copy to the organisers so that their web-master could format it and put it on their site? When someone kindly pointed out a factual error or typo I would be obliged to forward corrections to the organisers, hoping that they would ask their webmaster to update it. They might not and I might end up patiently answering emails from a growing crowd of conference attendees all helpfully pointing out the mistake I had already tried to correct.
This problem will not be solved by sending my contacts a link or an RSS feed. The conference organisers do not want to put a link to my paper on their site. They want to publish my paper, and all the other papers, in a uniform format on the conference site. Then, when the conference is over, they want to have them available in an online archive of papers.
The problem will not be solved by wikis either. Neither the organisers nor the authors are offering the work up for alteration and adaption - at least at this stage. They want to present the work as completed, while somehow allowing the author an easy way to correct, enhance, expand it or syndicate in the future.
What is needed to fill this requirement is a form of distributed publishing. This would allow me to publish my paper in my own memi, and then provide a simple mechanism that would allow other people to have the paper automatically published on their sites, using their style sheets. The paper would appear as a standard page on the site, but would be linked back to the originating site, and would be updated automatically to reflect any changes in the original.
The distribution of the linking mechanism would form the entire process of publication.
I had contemplated many approaches to this problem. I had thought in terms of a WordPress plug-in and abandoned this because the scope of this would be too narrow. If the idea is going to work then it needs to meet people where they are, and not require them to adopt a particular piece of software, however good it is.
I then thought of mutating one of the RSS standards and building a reader that posted a full article on a specific page. This languished because the more I thought about it the duller the prospect of actually doing it seemed.
Finally I thought about storing the articles as html fragments and using either the object tag, or an iFrame, to import them into an existing page. This was actually in progress when I found Zoho\'s hidden surprise. (Incidentally, if you are wondering how slapping some text into an iFrame could be "in progress", then the answer lies in the fact that IE6 and IE7 do not easily allow text files to be embedded in object elements, as they arguably should, and neither do they seem keen on styling the content of iFrames with the CSS used by the rest of the page - something which is essential to the whole concept.)
Zoho\'s surprise is simply this: the standard looking option in Zoho Writer labelled Publish does nothing like you might expect it to do.
The equivalent button in Google Docs, for example, does do exactly what I expect. You click on it and it gives you a url that looks like this:
http://docs.google.com/Doc?id=ajc4dfj9ffxw_12hnpbk7
If you post it on your web site then people who click it will be taken to an impersonal version of the Google Docs page where they will see a read-only version of your document. It\'s just another link, that\'s all. You could get the same effect in a neater way by posting the original on your own site and handing out a permalink.
I had taken this to be what web applications meant by Publish, and so I was slow in bothering to explore how Zoho Writer did this. When I did I discovered that it did something completely different. It gave you a code snippet like this:
<script src="http://writer.zoho.com/public/owen/Zoho-for-distributed-publishing/script"></script>
When you paste this into any web page it calls a javascript function that inserts the content at that point in the page in such a way that it is styled with the page\'s own CSS style sheet. Every time the page is opened the script is enacted again and the latest version of the publication is always loaded.
This means that if you post the code snippet on your site, everyone who takes it and includes it on their site will publish your articles in the style and format of their own site, while being certain that their published version remains in sync with the original version. In other words, out of the box, and with no announcement or discussion of the implications or the potential, Zoho Writer offers a version of distributed publication.
Much of current Web 2.0 innovation consists of technically simple ideas realised well that generate interest and excitement, or solve social and community problems. In each case (from eBay to Flickr to MySpace) the success of the idea has been as much about its adoption by a group or community who begin to use it in their own ways as by its technical innovation or brilliant design. The fact that MySpace originally appeared badly designed and hopelessly disorganised turned out to be its biggest strength.
The implications of what I am calling distributed publishing also stand to open up the web in surprising new ways by extending the idea of unhosted networking, mashups and remixes to online magazines, books, academic journals and conferences.
Imagine a group of science fiction writers who self-publish on the web, and imagine them making their work available for reuse through distributed publication. Imagine an editor wanting to start an online science fiction magazine. Instead of asking for submission, the editor can search the web and then clone those stories that fit the magazine best. Instead of asking the authors to supply formatted copies, the formatting will be done automatically by the magazine site\'s style sheets.
Imagine a group of poets, campaigners, or environmental activists putting their work online and then collecting it into anthologies through cloning what they choose as the best pieces that permit distributed publishing.
This builds upon the model that fuels Creative Commons licences, as well as acknowledging that attention is a new form of currency in the information economy. Creative Commons licences permit the exchange and creative reuse of intellectual property. Distributed publishing provides an unsupervised networked mechanism for this to actually happen.
As far as I know Zoho is currently in a unique position to assist this development because, by design or accident, it has already made almost the right tools available. There is no danger of being locked into one system though, because what Zoho have is a well developed web-based word processor and a javascript function that does exactly what is needed. This is something that Google or Yahoo or any of the other independent web suites could also offer if they chose to. What Zoho has is the advantage of being first there, with the abilities that that implies. If a cloning community is going to develop then it will develop initially around Zoho, and if Zoho\'s methods work properly then the community will likely be increasingly reluctant to switch engines.
At the moment Zoho\'s method\'s almost work properly.
The problems that are currently apparent are not connected with how the publication is distributed. That works fine. The problem is with what is distributed.
If this idea gains traction it will spread for cultural reasons and not because it is technically possible. It will be spread by academics, writers, campaigners and poets who are willing to publish under a Creative Commons licence because they want their work to be shared, and to enter the culture. These people will be concerned with distributing their content, not with learning a new set of counter-intuitive computer skills. The system will therefore have to seem as easy as email.
Since the work I am discussing will be born and live its entire life on the web, it will almost necessarily be structured as html. Since it will be distributed to people who expect to publish it by inserting one line of code onto a web page, the html will need to be well structured and completely predictable. This will mean that authors will need to follow a simple set of guidelines so that Heading 3 is used reasonably consistently across documents, for example, but it will also mean that the html that is produced by the authoring application will need to be well-formed and useful. By useful I mean that the html that it output will need to be in a form that is amenable to being styled at its destination.
This means that the tool use to author the work will need to produce the right kind of html, and (from this perspective at least) the html that Zoho Writer produces is somewhat less than optimal. Fortunately, though, it has such a clean and well designed interface that implementing the necessary changes may not be very difficult, if Zoho have the inclination to do so.
As an aside here, I want to point out that all online word processors live in an odd relationship with html. They use it to show documents on the screen while many (maybe most) users will end up converting the documents to a desktop format such as rtf or doc. So choices about what elements to use may need to be governed as much by the practicalities of the conversion process as by a webtastic desire for valid xhtml.
Nonetheless the designers at Zoho have also chosen an online publishing method that will distribute the documents as html, and for that they do need clean code!
There are at least three obvious problems with Zoho\'s current use of html.
The first and most important is the decision to make the normal use of the return key produce line breaks instead of new paragraphs. Open a new document; start typing as you might in Word; format a few headlines and then save. If you look at the html view you will find the headings are formated correctly but there are no paragraphs anywhere, only line breaks. On the other hand, if you open a new document and then (before typing anything) select the Normal style, pressing the return key will result in the closing of the current paragraph and the opening of a new one.
I understand that this probably makes no difference at all to people who are simply going to view the document on the screen, convert it to rtf, or print it out, but it is of crucial importance to anyone who is going to use Zoho for distributed online publication.
The second point is possibly less serious. Zoho marks up bold and italic by creating spans and then adding inline style to them, whereas WordPress, for example, marks them up correctly by using the strong and emphasis tags. This is correct theoretically because it avoids mixing up logical and literal mark-up. It is correct practically because it allows designers at the destination to apply whatever local styles they want: to put all the bold mark-up in a different font, and the italic in small caps, for example.
Dropping inline styles into documents intended for distribution and styling at the destination serves no logical purpose, and can only be the source of unnecessary problems.
The third problem is simple, and can be solved by simply adding another menu item. Zoho does not appear to offer a simple method for marking a paragraph as a block quote, something that is used frequently all over the web, and off-line in academic papers.
I also noticed that any tags connected to the page in Zoho Writer are not exported as part of the document, but I decided that htis is not a problem. In this case I think Zoho have got it exactly right. The tags should be local, and related to the rest of the content on the receiving site. They should not be a canonical part of the published document.
The observations above are based on a first look at Zoho Writer\'s output, and not on days and days of exhaustive testing. They may not be true under all circumstances and there may either be simple workarounds I have not spotted yet or, on the other hand, there might be other similar issues. I am therefore going to set a team of students to test Zoho comprehensively from the perspective of using it as the engine for distributed online publishing.
I am doing this because everything I have read on the Zoho blogs and forums so far suggests that they might well be interested in this kind of use for Writer. I shall email the development team once I have posted this to find out!
I am also going to get another group to continue to explore the idea of organising distributed publishing using text files and the object element. My hope is that this will not need to be put into practice, but, at the very least, it will provide a useful set of comparative data.
I am putting this essay on my web site as a distributed publication now in order that other people can test how the publication process works on their sites, and when rendered on Macs and Linux computers - and in order to see how useful the process actually appears in practice.
When it is clear how the vision can best be realised then I will write a clear manifesto for distributed publications which (obviously) I will post here as a distributed publication. If Zoho are able to make the few amendments necessary to the applications output then I will also promise write a manual for how to author work for distribution using Zoho Writer.
My hope at this stage is that Zoho will be able and wiling to devote enough time to upgrading the html output of Writer to work with us on establishing what I at least envisage as an important new medium of information distribution and exchange.
We shall see.
This essay is intended as a distributed publication. It was authored by Owen Kelly and published on March 13th 2007. The original title was Zoho for distributed publication.
You are reading version 1.0, which was last modified on March 13th 2007.
You are free to republish this essay on your site. In fact, you are actively encouraged to do so, if only to test the technology and see the ideas behind it in action.
To publish this paper simply copy the following code snippet into a suitable page on your site:
<script src="http://writer.zoho.com/public/owen/Zoho-for-distributed-publishing/script"></script>
Then add any other information to the page, such as a local title, introduction, categories or tags. The current version of the essay wil be loaded into the page each time it is accessed or refreshed.
');