cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alfredas Chmieliauskas <alfre...@sseriga.edu.lv>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Sun, 04 Nov 2001 01:27:29 GMT

Reflecting on Stefano's RT's:

I guess there is not much doubt and argument about the "user agent <- publishing <-
store" part as C2 provides an 
excellent framework for any type of contract implementation, moreover, as long as you have
structured/and semanitic data in the "store", 
the rest of the job itself can be structured.

The most dubious part to my mind is the "edit agent -> CMS" and the agent itself. 

The _dilemma_ lies in enforcing the user's input as semantically reasonable data, without
losing the WYSIWYG traditions of the nowadays document management. 

A year and a half ago we were considering alternatives of making a CMS - a management layer
for the new 
web-publishing opportunities C1 had opened. At rthat time we came up with three reasonable
posibilities for the 
"editing agent -> cms" implementation: 1) java applet 2) mozilla XUL 3) IE "endowed" DHTML
editor solution with the same good C1 
for producing the structured input UI.

Eventually we chose no 3) - as mozilla was _not at all_ popular in our user environment and
IE had better integration posibilities with the 
_oh so popular_ MS Office. Another "PRO" was using the same C1 not only for publishing but
also for producing the semantically 
"correct" DHTML-based UI and enforcing the logics of input that would afterwards be used by
C1 in publishing - I hope you can trace a sense logics here ;-)
Despite the fact that our goal was more about proof-of-technology, we implemented this solution
and it is used for production in several places 
for more than half a year already. 
During that half of year I realised the shortcomings of such approach that can be divided
to several areas of concern:

1) Users; office workers - people responsible for certain processes in the company and now
able to directly report them by CMS.  

Despite the sophisticated and very user-friendly UI that we managed to develop (almost anything
can be drag-n-droped anywhere; when creating content,
managing permissions, creating new datasources, various items, etc), using any new wroking
environment for the avg. office worker requires training and assistance.
The axiom here is that training/teaching/assistance is always more expensive than development,
especially for big companies, at which such tools are mainly targeting.

2) Integration with the existing CMS tools "on the desktop" (offices, like MS, Star, Lotus,
etc)

Remember the _dilemma_ - the more the solution is convenient for the developer (structured/semantic
input approach discussed by Stefano) the harder 
it is to integrate with the existing office tools, which are primarily concerned about the
layout of the document, not the structure. And suck 
office tools are not likely to die away so fast, sad but true. 

3) New publishing/CM routine

Going back to the users. A new publishing/content management environment creates a new/and
different work routine that is additional to the 
existing ones. Generally, people are not satisfied having to work more than they used to.

3) Transformation of existing data

Almost every company has a web site and some sort of document management system right now.
A concern when considering editor agent for a CMS is whether/and how
it will be able to handle the existing data, especially that is in a unstructured format.
Well I guess this comes back to the integration issue.


Considering these factors it seems reasonable to support Michael's proposal - using OpenOffice
(OO) as an editor agent.
In addition to the PROS that Stefano has mentioned (open-source, almost finished and portable)
it solves (or is closer to solving) the integration (2) issues - by supporting the widely
used proprietary document formats as .doc, .xls and a possibility to convert them to XML.
I completely agree that the XML support the OpenOffice has to offer is a complete crap (looks
similar to the html saved by MS Word ;-) but IMHO it is 
reasonable to try to enforce fixed templates in order to make the input more structured (and
there is a chance that the OO guys might realize their mistake and improve the xml features
just like MS did with their HTMLFilter2 ;-)

While using to export the documents to the CMS the publishing routine (3) would remain the
same as it was + one more "Save As" to be pressed 
to export the content to the CMS; and that would also decrease the training cost of the personel,
thus increase the value of the product, right?

Stefano's proposal is more appealing technologically (I was always fond of XUL idea for a
front-end ;-) - I wanted to share a more managerial perspective.
Anyway - both of these perspectives _should_ definately be the areas of our overlapping concerns
in order to continue the trend of cocoon's success  ;-)

Regards,

Alfredas

----------------------------------------------------------------
Stockholm School of Economics in Riga <http://www.sseriga,edu.lv>
Strelnieku 4a, Riga, LV-1010





---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message