cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Tue, 06 Nov 2001 09:43:56 GMT
Alfredas Chmieliauskas wrote:
> 
> 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.

Yes, either with the store built into the CMS or not (yes, Gianugo,
probably the store should be hidden) this is the way to go to to "get
data out".

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

Yes: how to "get data in".
 
> The _dilemma_ lies in enforcing the user's input as semantically reasonable data, without
losing the WYSIWYG traditions of the nowadays document management.

Bingo. That's definately the point: there is a legend that says that
Microsoft Word has a feature they internally call "the letter to the mom
feeling" or something like that which is about the feeling you get when
you open up word and it's trivial even for somebody who never used
computers to write a letter to his/her mom and print it. (not saving it,
that's the hard part, but many users don't save their documents! my dad
is one of them, go figure!)

At one point, some smart guy came in and wanted to change this look into
a more "professionally looking" word editing software that could be used
either free-form (as most people do) but also as "constrained" (as most
of us would like "THEM" to do!)

Guess what: they decided the office assistant was a better way to invest
money. Well, probably this world *deserves* microsoft anyway :(

> 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.

Yes, these are the only reasonable answers if you want to do something
that integrate seemlessly with the user browsing experience.

> 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. 

As I understand this, I think this is very likely to change in the
future: I mean, Netscape 4.x is years-old and it generally sucks (like
all software which lags years behind of schedule) but Mozilla will soon
reach a 1.0 release and people and companies will start using it.
(either Mozilla, Netscape 6 or lighter clones like Galeon, Kmeleon and
what not).

Besides: IE 6 binds you with Passport. If the migrating path between NT
4.0 and Win2k was slow and not that successful, I can't even think about
companies moving to XP with all the security problems outlines.

Moreover, can you tell me in what way is IE easier to connect to Office
than Mozilla is? I thought that XPCOM had a way to connect to COM on
windows platforms, is that wrong?

Anyway, the real question (for me, I can't talk for others) is where to
"invest" time to search for a long term solution.

Now, sorry, but IE, MS Office or even OpenOffice don't seem like a long
term solution, but a short term hack.

> 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 ;-)

Well, this very same argument holds for mozilla :)

> 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:

Ok, good, let's get real-world experience on the table first.
 
> 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.

Nothing new here and this doesn't stop me from thinking about a good
solution. I mean: people used to write content with paper, right? but
this didn't stop them to use computer-based word processing (rather the
opposite since it's the PC killer app even today) even if this required
training.
 
> 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)

No, no, wait a second: you're getting my picture totally wrong.
"convinent for developer" is *NOT*! It would be much more convenient
(for me as a developer) to use an xslt stylesheet out of openoffice or
RTF xmlized (using something like upCast, for example) rather than
building an entire new editing system and new languages that define the
process.

Also, keep in mind that "convenient for users" in this very case means
"convenient for Mr. Bill Gates pockets".

Let's be realistic: Cocoon + CMS + editing will not replace Word in
small offices or shops. No way. It will replace it in big newspapers,
big/medium sites and has the potential to open new markets where the
cost of a publishing solution is not tied to the 250000$ you have to pay
for Vignette.

Still, I'm not blind and I do see that the expense of retraining
existing people will very likely exceed that sum anyway, but this is the
case with *all* publishing systems which are more semantically stronger
than Word (or all other WYSIWYG stuff).

So, is this system hard to sell? I don't know. I only know that I've
been requested such a complete vertical system so many times that I see
a decent market for it, despite the "unconvenience" of intrinsic
impedence mismatch between so-called offices solutions (which appear
convenient at first, but give you anything but problems later on).

> 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.

I agree with that and this is the gray area where most of us will
probably earn the money anyway, even if using hacks that start forcing
users to use fixed templates, then take a wild-guess about what the
semantics is.

As in all transition periods, there are forces that want to evolve and
forces that want to keep things the same.

Don't know about you, but you can count myself in the first group.
 
> 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.

You're stating the obvious, but I don't see your point: in the system I
envision, the workload might not be reduced (well, editors, in fact,
edit and Cocoon won't edit for them!) but can allow people to
concentrate on what they like to do and avoid them the nasty parts (even
saving on the wrong place of the disk can be an evidence of concern
overlap!)

I don't see how allowing somebody to do what she/he likes and avoiding
stuff that she/he doesn't like or know can be considered as increasing
workload.

I would personally say the exact opposite, even if this requires
training and new routines to be learned on my side.
 
> 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.

Yes, I would say so.
 
> Considering these factors it seems reasonable to support Michael's proposal - using OpenOffice
(OO) as an editor agent.

Oh, hope you didn't get me wrong: my RT stated that I "personally" won't
spend time on that solution because I'd rather spend my time on a
longer-term and a more semantically-solid one, but I do agree that in
the short term it makes sense to try it out, so I won't stop anybody
from trying it and, possibly, donate it here.

> 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.

Sure. In the "migration" case, I totally agree this is the best choice
between the different "hacks" we can think of.

> 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 ;-)

Talking about this, there are a number of things the OO guys can do to
provide better support for us doing this: for example, allowing
templates and styles to be "read-only" (so that users don't mess around
with it) and allowing us to replace/delete all the existing default
styles (which is not possible now).

With these two features, our XSLT "wild guesses" might well turn into a
reasonably solid back&forward path to OO. But I'm not sure how the OO
guys will like this.
 
> 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?

Oh, for sure it's a dream come true for many, but much is you dreaming
of this to be a good solution and this actually "being" a good solution?

Don't worry, I thought OO was the right solution until a few weeks ago,
but then I started to see that either OO changes its design roots (and
this will hardly change with millions of existing lines of code) or I
change direction for the long run.

At the same time, nobody said that both ideas can't coexist on the same
system and provide different entries for different people.
 
> 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.

I know I don't look like a manager, nor think like a manager, nor act
like one (nor earn their money either!), but I'm not being un-realistic,
but I think I'm being over-realistic: it's the OO integration which is
"convenient for both the developer and the current user"... but it's not
convenient for the service these two groups provide.

And, guess what: people buy convenience for them (also called
"services") not convenience for the people that works for the company. 

For example: if the fact that editors use Word reduces the effectiveness
of a semantic search on the site, people might go someother place where
the search is better. They see the result, not the process that leads to
it.

Now, this said: there could be environments where people are more
productive/happy if they use Word or Word-clones (normally people
already very used to them), while there are other environments where
people are more productive/happy if they work with in-place editing.

There are even environments where people are more productive with VI or
Emacs :)

So, my goal is to support all of them, but from my point of view, I find
it more appealing to empower those users that never had editing
experience before (or hate Word as much as I do!).

> Anyway - both of these perspectives _should_ definately be the areas of our overlapping
concerns in order to continue the trend of cocoon's success  ;-)

Absolutely :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message