OpenOfficeFrontEnd

Motivation to OpenOfficeFrontEnd

While the GUI-based interfaces are good. Unless you are dealing with Writely (now called Google Docs) they are lacking in WYSIWYG and responsiveness when compared to the application-based word-processors. The problem is that

Possible Approach

The way the otherwise awful SharePoint is resolving this issue is by tight-coupling between SharePoint as CMS and MicrosoftWord. I have thought this approach had value for quite some time as it avoids the need to rebuild at considerable cost/time/effort the WYSIWYG document-editing experience in a web-browser. Of course the open source approach would use OpenOffice using RichTextFormat.

By offloading WYSIWYG interface to OpenOffice you actually improve on the user experience of: SharePoint, Twiki, and Google Docs all at once at lower cost. Users would already know how to edit content and post it. They would also understand how to print intuitively. Templates in OpenOffice would become how they create standard web-pages.

To maintain the edit-everywhere ease-of-use of the web one would need to support Foswiki-markup-language. That cost is probably less than building and maintaining a cross-platform WYSIWYG web-browser based editing tool.

Use Case

The user opens, edits, saves, and prints documents in and from a WYSIWYG client side document editing tool such as OpenOffice. They continue to be able to edit FosWiki through the text-based web-browser as well.

Discussion

• Absolute dependency on OpenOffice
  • Solution: Document is saved in HTML, thereby allowing any WYSIWYG HTML editors to be part of the Foswiki platform.