Nick Carr has sparked speculation that Microsoft will soon unveil its strategy for bringing its Office suite online – which to me means a way of working with Office documents on any computer which has an internet connection.  If you are connected, I’d expect you to be able to collaborate with others in real time; if you are not connected, I’d expect the software to work in offline mode.

When I say “any computer”, I don’t mean to restrict that to any particular operating system (and indeed, Silverlight runs on the Mac, and Microsoft has announce it is working with Novell on a linux implementation).  What good is collaboration software if some of the people you need to collaborate with can’t play?I thought I’d make some predictions about the business model.

There seem to be 2 key questions:

•  does each end user pay, or does a collaboration originator pay for the right to invite a certain number of collaborators?
• what support for Mac and Linux users, and when?

Whether each individual user is required to pay, or the originator pays, will reveal much about how Microsoft regards its online offering.  The latter model, that the person who originates a collaboration session pays for a certain number of people to be able to collaborate (ie whatever their platform), would show that their focus is firmly on collaboration.  This is the model we would use for any plutext SAAS offering (available to people who don’t want to install plutext server internally, for free or a fee). 

Here are my predictions:

1. Enterprise version (ie behind the firewall).  There will be a version an enterprise can install on its Sharepoint server, for those businesses which are not comfortable with their documents being hosted externally.  I’m sure Microsoft can work out how to let people give access to people outside the firewall as necessary.  An enterprise licensee will be able to invite people outside the enterprise without charge.
2. Cloud version. I expect there will be a cloud version for SMBs.  I think you will be able to use this for free, provided you have a license for the traditional Office product.  You will definitely need this (2007 version) to originate collaboration around a document (ie invite other users) – unless you are prepared to pay a full price for the online offering.  Maybe anyone will be able to accept a collaboration invitation (ie whether or not they are licensed to use Office), making the “who pays” question mute.  To create a new document (or print it?), I expect you will need to have a licence for the traditional Office product, or pay for the SAAS offering.
3. Mac and Linux support.  I think Microsoft will offer Mac support sooner or later, but delay any hint of support for Linux for as long as possible.  This is because Linux is much more of a threat than OSX (two reasons: (1) Linux is free, and (2) it is very easy to install it on your existing Windows PC).  That said, they might have it “only on Windows” to try to keep people there – until some critical tipping point is reached.  I would say that even now, the only thing stopping Microsoft from seeking revenues from Linux users are the inevitable press headlines along the lines of “Microsoft admits defeat” that would come with this.  The cost of this in terms of perception would surely outweigh any incremental revenues in the short term.  Mac users may be able to use it for free – provided they had an Office license they were able to associate with their online user ID.  
4. docx only. The documents which come out of this online service will be docx documents, not binary or RTF.  This will help to make the new format ubiquitous.

I wonder whether the collaboration protocols will be published under the recent interoperability initiative?  If they are, the way would be open for a rich world, in which docx4all could potentially play…  I’d be pleasantly surprised if they were, and there was nothing stopping someone from making a client or server of their own.  If anyone else could create a server, then why not get rid of it altogether and go peer-to-peer?  Maybe, just maybe, the thinking is that it would take forever for someone other than Microsoft to create a fully featured server, so third party implementations are to be encouraged (as is presently the case for OpenXML), since Microsoft’s offering will always be the RollsRoyce implementation which attracts the most usage, with the other implementations adding value to the ecosystem.

 The announcement, if/when it comes, will be fascinating!  Read the rest of this entry »

In comment 18 to comment of the day “Google Docs is Chock Full of Fail” by Karim on Read/Write web, Bernard Lunn says:

if you drew a magic quadrant with “control over presentation/formatting” on one axis and “rapid online collaboration” on the other, neither MS Office or GOOG Apps would be in the magic quadrant

That’s precisely the quadrant we’re aiming for with plutext. We still have a way to go

Anonymous comment 4 to Scoble’s contribution to the debate also articulates our reason for being:

I’ve found Google Docs is great for collaborative editing. Once everyone’s done editing then it’s up to someone to take the Google Docs version and properly format the doc using a desktop word processor.

Based on this observation, Google needs to completely clone a desktop word processor or focus on perfecting collaboration

We’ve now got a proof of concept of docx4all, our cross-platform WYSIWYG docx editor, ready for you to try. Here is the launch page to run it from your browser.  Give it a try in Linux, XP, Vista, or (if you are game) OSX.

This proof of concept includes:

• file: new | open | save
• text formatting (font, size, bold, italics, underline)
• paragraph formatting (alignment)
• cut/copy/paste
• styles
• printing

There is still a lot to do, but with the introduction this week of support for styles, we’ve got a basic feature set which you can use to do actual work (not that we’d recommend that just yet) – assuming you can live without tables (for the moment at least).

It is set up to run offline – it should offer to create a shortcut or a menu item so you can run it again later.

Let us know what you think of it, here or in the forums. Cheers.

Well, the VMware appliance is mentioned in my last post is now available.

Its a great way for prospective developers to examine docx4all, and also an easy way for people to work on Alfresco.

The appliance is built around Ubuntu’s JeOS (‘Just enough Operating System’), and Eclipse, which also means a desktop (for which we chose Xfce).

A stack of pre-built open source software delivered as an appliance which runs in a free container (eg VMware Server or Player) on your operating system of choice reduces to pretty much zero the cost for new developers to get started.

Its a pity we can’t deliver a similar appliance for developers wanting to work on our Word 2007 add-in – developers need Visual Studio, VSTO and Word 2007;  it would be great if Microsoft gave their blessing to a freely downloadable virtual appliance which contained these things (perhaps they could ensure that the only way you could launch Word was by running your application from Visual Studio).

That’s why I didn’t mention plutext-server in the second paragraph (even though you can install it into Alfresco with a single command).  Currently, you really need the Word 2007 add-in to work with plutext-server.  The barriers to entry for plutext client developers are one of the reasons we’re working to make docx4all a fully functioning plutext-client.  Stay tuned!  In the meantime, we’ll provide an easy installer for the Word 2007 add-in, so at least you can try the system end-to-end – provided you’ve got Word 2007.

With the Alfresco show-stoppers now behind us, we’ve packaged plutext-server as an Alfresco Module Package (AMP). The idea is that in due course, it will be easy to deploy plutext-server into an existing Alfresco implementation. See Integrating plutext-server into Alfresco for details.  Given that we’re going down the Alfresco road, we now also have a project on the Alfresco forge.  Mostly, that will direct existing Alfresco users here.

At the moment, it is still too hard to try out plutext:

• You have to build your own plutext-server, because there is no web-based user self registration for our test server.  This will change in the next fortnight.
• Building your own plutext-server isn’t too hard if you are a Java developer, but we’ll make that easier as well.  We’re building a VMware appliance which you’ll be able to download, which contains a preconfigured development environment.  Unless you are really keen, you may as well wait for that.
• Currently, you have to build a Word 2007 add-in to interact with the plutext server.  Soon this will be a downloadable executable.

So that’s the agenda for the next couple of weeks.  Cheers!

It looks like most (hopefully even all) of the weird behaviour I have been experiencing with Alfresco’s JCR API disappear if I explicitly wrap the actions performed in each session in a transaction using getRetryingTransactionHelper().

According to Alfresco’s wiki, an implicit transaction should take care of this for you.  Well, some 4 days of pain tells me it doesn’t!

Twelve days ago, I checked out Alfresco.

I thought Alfresco would be a good way to get access control sorted out. There are a number of other features in Alfresco which might prove interesting down the track, but access control was the immediate priority. Alfresco provides each user with a home directory, and lets invite other people to access their resources.

I also think that plutext-style document collaboration would be a great fit for many of Alfresco’s customers. Like most other document management systems, Alfresco uses the classic check-out/check-in model (detested by users the world over!). plutext collaboration frees users from that paradigm.

By Monday, a week in, plutext was basically working with Alfresco. This included the Word 2007 add-in authenticating itself when it makes web service calls (something I hadn’t implemented before). I found a few little bugs in Alfresco which I reported (here and here), but everything was going remarkably smoothly.

Sweet, I thought I’d have a relaxed Tuesday, checking the code in, updating the build and wiki, before declaring success in a blog post.

Well, that wasn’t to be. It turns out there are some major issues (here and here) with Alfresco’s JCR support and/or repository which need to be resolved. Its not so easy to identify simple test cases, since they seem to arise when a series of operations are performed in one session after another, and manifest themselves sometime later, but at least the problems are repeatable.

Hopefully the Alfresco guys will get onto these problems quickly. Otherwise I will have to learn more about Alfresco internals and its use of Hibernate than I’d care to!

Early next week (a week later than I expected) I will update the build procedures so you can easily build it for Alfresco, and then I’ll make sure it works with Jackrabbit again (we’d like to have a single content model that works for both repositories – more on that later).

If we can make good headway with the issues in Alfresco over the next week, we’ll probably regard that as our flagship configuration. If not, I’ll take another look at building access control around Jackrabbit. Although Jackrabbit lacks Alfresco’s bells and whistles, my experience with it (in the single user load scenarios which are causing Alfreco problems) was trouble free. That’s not to say I expect it to be perfect under heavy load, but it sounds very promising based on what Jukka wrote recently following the announcement of version 1.4.

Doug Mahugh recently mentioned someone using the DocX2Html.xsl that ships with SharePoint to preview DOCX files in HTML.

As it happens, we’ve just implemented HTML and PDF output in docx4j using a similar approach. We’re using the earlier WordML2HTML XSLT stylesheet available from Oleg Tkachenko. (It would be great if Microsoft also made the presumably newer DocX2Html.xsl that ships with SharePoint freely available).

To create the HTML, we use Sun’s xhtmlrenderer (thanks Sun!). See the obligatory tutorial.

To create the PDF, we take the HTML, and run it through Sun’s pdf-renderer (thanks again, Sun). And again, the tutorial.

The icing on the cake is the PDF Viewer which comes with pdf-renderer. That will give us print preview and printing in docx4all.

Finally, thanks Lars for bringing pdf-renderer to my attention.

This week, thanks to JAXB, we added strongly typed content models for the Styles part, and the Numbering definitions part of a docx.

Have a look at Styles.java and Numbering.java, used by their respective parts.

I’ve added a page to the wiki, showing how easy it is to programmatically create a new document from scratch.