Greg wrote:
Well, you were bemoaning the lack of a "real, full, screen word processors and HTML editors, with spell checking, macros and lots of other goodies." That client (and performancing and...) gives most of what you were complaining about.
Sorry, my fault here. What I meant is that it doesn't make sense to have _one_ different "real/full editor" for every CMS, or every "rich text" use case one has to work with.
This is what I find really absurd. It is like using a different mail client for every mailing list you subscribe.
It would be handy to know more details about your situation:
Right now I have some hundred opendocument files. Length is anything from 1 to 100 pages. structure is relatively simple, almost no tables or graphics. After importing those, I'll start to write new material regularly or import it from other external sources (my own mail archives, for example). How often I'll have to update which percentage of pages I don't really know now.
So there are a lot of different inputs, but I could (I already am!) writing myself a different X -> HTML script. Is the next step, ie how to import that in Drupal from the command line, which is missing.
What I see is that Drupal, Wordpress, and basically every blog/cms I know of is implicitly designed for author(s) who publish (very) short texts, only once in a while.
Ok, I'll re-assert my point. Imagine your requirements in a multi publisher environment.
I don't have to imagine that. This thread is about a website I am building, and will run, all by myself. But I am also a member of other multi-author portals ran exactly like you say, done with Drupal, SPIP, Plone and others. Each site with different needs, each already existing (=I can't have it changed to drupal), each with its _own_ darned version of the text editing interface..., all mutilated, different buttons or names for the same task, different spelling checkers (= I have to re-define an acronym or custom term in ANY CMS I have to use, all while I did the same in OpenOffice years ago...)
Multiple people editing multiple text files on their client side and running scripts that directly import them into the system. That's what you want, right?
No, I have these admittedly weird and advanced needs only for a portal which I'll run myself, as said above.
However, my co-authoring experience in those other portals I mentioned, while closer to your scenario, still sees several of us working OFF LINE for the same reason: the online interface, whatever the CMS is, sucks so badly that:
* we exchange by email successive OpenOffice revisions of anything longer than one page * when we agree on that, we flip a coin to find the unlucky one which has to import it in the CMS GUI * generally, only _minor_ editing, like correcting typos or updating single URLs, is done directly in the GUI.
Well, how do you control versioning? How do you control the individual preferences ...How do you sync a local copy back with the server copy (since there are multiple editors...)?
In your scenario (~wikipedia, that is _looooooots_ of occasional authors who all publish occasionally, publish only one or a few (short) pages, and almost never interact with each other) I agree with you that the current CMSs do a more than decent job, and that other architectures probably wouldn't work.
I'm not sure I've ever heard/seen anyone do what you're
talking about.
people use all kinds of CMS for a wide variety of tasks including very long and highly formatted documents that get revised on a regular basis (have you seen the drupal handbooks, for instance?).
I have the drupal handbooks bookmarked and printed out. I am using them daily these days. I consider their quality (as one ORGANIC, COHERENT corpus of usefully interrelated information (*)) pretty low, and a good example of what I am saying: even if the single authors are good and committed, they are limited from their tools: the current generation of CMSs is not designed for (what I consider) serious, continuous work.
I don't remember if I already said it, but I am sincerely enjoying this discussion, it's not my intention to troll, and I don't mean to whine or make a joke of anybody's hard work.
I am just saying that the quality and usefulness of Drupal and other tools, while very great, is not exactly what is commonly perceived: I like what I am learning through this discussion, which is really helping me to understand several sw design concepts.
Ciao, O.
* regardless of formatting, and I'm not even referring to the single pages which often are quite good
On 7/4/06, dondi_2006 dondi_2006@libero.it wrote:
Sorry, my fault here. What I meant is that it doesn't make sense to have _one_ different "real/full editor" for every CMS, or every "rich text" use case one has to work with.
This is what I find really absurd. It is like using a different mail client for every mailing list you subscribe.
Well, that's what the different APIs are supposed to give you. And note that Performancing provides the same interface and works with a gaggle of different APIs which means it works with a pretty large group of blog engines. If you see necessary improvements in Performancing, just let them know. They're very interested in improving it and they even run their site on Drupal :)
It would be handy to know more details about your situation:
Right now I have some hundred opendocument files. Length is anything from 1 to 100 pages. structure is relatively simple, almost no tables or graphics. After importing those, I'll start to write new material regularly or import it from other external sources (my own mail archives, for example). How often I'll have to update which percentage of pages I don't really know now.
So there are a lot of different inputs, but I could (I already am!) writing myself a different X -> HTML script. Is the next step, ie how to import that in Drupal from the command line, which is missing.
It's not missing, it's just done using a lot of different input formats than you've got.
What I see is that Drupal, Wordpress, and basically every blog/cms I know of is implicitly designed for author(s) who publish (very) short texts, only once in a while.
Ok, I'll re-assert my point. Imagine your requirements in a multi publisher environment.
I don't have to imagine that. This thread is about a website I am building, and will run, all by myself. But I am also a member of other multi-author portals ran exactly like you say, done with Drupal, SPIP, Plone and others. Each site with different needs, each already existing (=I can't have it changed to drupal), each with its _own_ darned version of the text editing interface..., all mutilated, different buttons or names for the same task, different spelling checkers (= I have to re-define an acronym or custom term in ANY CMS I have to use, all while I did the same in OpenOffice years ago...)
It sounds like you want the ability to publish from OpenOffice.org to these different blog engines. Why not write that?
Multiple people editing multiple text files on their client side and running scripts that directly import them into the system. That's what you want, right?
No, I have these admittedly weird and advanced needs only for a portal which I'll run myself, as said above.
And as you said further above
"I disagree here. I don't think the intended *number* of authors matters at all. What I see is that Drupal, Wordpress, and basically every blog/cms I know of is implicitly designed for author(s) who publish (very) short texts, only once in a while."
My contention is that your offline command line import tool would fail miserably in a multi editor environment. And I don't think you've said anything to change my mind on that.
So are you talking about one author or a lot or...It's tough to find the right solution when you keep changing the requirements/focus. And frankly, I think you've gotten all the help/advice that you can and just need to continue writing the stuff.
However, my co-authoring experience in those other portals I mentioned, while closer to your scenario, still sees several of us working OFF LINE for the same reason: the online interface, whatever the CMS is, sucks so badly that:
- we exchange by email successive OpenOffice revisions of anything longer than one page
- when we agree on that, we flip a coin to find the unlucky one which has to import it in the CMS GUI
- generally, only _minor_ editing, like correcting typos or updating single URLs, is done directly in the GUI.
"Sucks so badly" doesn't help us improve it. You want full screen - that can be done in your theme file or using some of the WYSIWYG editors already. You want spell checking that uses the same dictionary file on all your sites. That seems best implemented as a browser extension so your dictionary is in the browser across the sites and not installed on the server. You want rich editing - done! So, what features, more specifically, make it "suck". Once we know, someone (maybe you) can fix them.
Well, how do you control versioning? How do you control the individual preferences ...How do you sync a local copy back with the server copy (since there are multiple editors...)?
In your scenario (~wikipedia, that is _looooooots_ of occasional authors who all publish occasionally, publish only one or a few (short) pages, and almost never interact with each other) I agree with you that the current CMSs do a more than decent job, and that other architectures probably wouldn't work.
I'm not sure I've ever heard/seen anyone do what you're
talking about.
people use all kinds of CMS for a wide variety of tasks including very long and highly formatted documents that get revised on a regular basis (have you seen the drupal handbooks, for instance?).
I have the drupal handbooks bookmarked and printed out. I am using them daily these days. I consider their quality (as one ORGANIC, COHERENT corpus of usefully interrelated information (*)) pretty low, and a good example of what I am saying: even if the single authors are good and committed, they are limited from their tools: the current generation of CMSs is not designed for (what I consider) serious, continuous work.
and your asterisk:
- regardless of formatting, and I'm not even referring to
the single pages which often are quite good
While they have their problems, the Drupal handbooks are always getting better and always welcoming new writers. I don't see how the handbooks show any sort of systemic deficiency - sure, they have problems, but I don' t think those problems would be solved if peopled had a command line import or an OpenOffice.org "Save to BloggerAPI" option. Again, if you see that then please state it specifically so it can be fixed.
I don't remember if I already said it, but I am sincerely enjoying this discussion, it's not my intention to troll, and I don't mean to whine or make a joke of anybody's hard work.
I am just saying that the quality and usefulness of Drupal and other tools, while very great, is not exactly what is commonly perceived: I like what I am learning through this discussion, which is really helping me to understand several sw design concepts.
Well, the current CMS input mechanisms are exactly what I perceived. I think you need some citations to blog posts beyond your own point of view to be able to say that CMS input mechanisms is weaker than commonly perceived.
Regards, Greg
-
dondi_2006 -
Greg Knaddison - GVS