hi all, firstly, it's not me asking that question. it's the users. here's the situation.: we have developed a ZClass that caters for the publishing/serving of news items. we already have contents done in quark, pagemaker and other formats. users (editorial) currently cut and paste from the source. when the users saw that they have to cut and paste, they asked why? and they pointed to frontpage, pagemill, etc as a solution. now, we don't want that, but how can we explain the benefit of zope over the others. i have read the zope against cf, vignette thread, but that's too high level for the users to grasp, me think. so, really, what's the benefit of using zope instead of the others; esp for the non-techies. p/s - maybe it's our failure in providing a better solution in exporting contents from window$ apps that cause this question. help, pointers, docs, welcomed. -- ------------------------------------------------------ http://www.kedai.com.my/kk Am I Evil?
Hi "-", At 9:17 Uhr +0800 27.01.2000, - wrote:
hi all,
firstly, it's not me asking that question. it's the users. here's the situation.:
we have developed a ZClass that caters for the publishing/serving of news items. we already have contents done in quark, pagemaker and other formats. users (editorial) currently cut and paste from the source.
when the users saw that they have to cut and paste, they asked why? and they pointed to frontpage, pagemill, etc as a solution.
Well I guess the failure is sticking with the "old" way of publishing - beeing print oriented. Print by far is the slowest medium today, the fastest is defenitely the Internet, when it comes to mass media. So for any publisher the task should be to move new, fresh content to the Internet and see that the other desired media follows as soon as possible. This way you will probably look for an Internet application that's db-based and open to the rest of the world. Editors would publish their content to the web application and after review, the content is published to the world! Doing solutions to bring the content to XPress or other publishing software is fairly easy then. So the crux is to bring the content to the ideal form. What system is better suited to edit contetn for such a publishing process than Zope? I think if you are taking the Internet seriously as a channel for your publication, it's time to rethink your publishing process Internet-based! On the other hand, I don't really see your point... when using Frontpage, your people would still be cutting and pasting... so what should be better with FrontPage or PageMill??? It get's even worse as the editorial staff has to work in a graphical environment and they will tend to try to change things, wich get's really bad for you technical staff without any real work beeing done (don't tell that to your editors...) BTW, a friend of mine offered a tool, a plugin for XPress that allows you to layout pages as XML and directly post it to a web application like from a form. This is best suited for applications like catalogs, but might work with a news layout as well... Can't remember the name, though, look for it at <http://www.hexmac.com>. Regards from Germany Jochen
Have you tried letting them in via FTP and/or WebDAV? Or possibly constructing an upload form for new documents that makes use of a file attachment?
From a user's perspective, there is little benefit to using Zope rather than FrontPage+IIS. All they know is that they can't use the "Publish" button. They don't really care about much more than that.
I think the most compelling argument to *management* would be that you've come up with a highly flexible solution to your problem in a far lower amount of time at a far lower cost than if you had used an equivalent commercial solution. I have nothing but anecdotal evidence to back this claim based on my time as an ASP developer, however. A probably less compelling argument is that Zope is completely open-standards-based, whereas nobody really knows exactly how Front Page does its magic. That said, your job should probably be to make it bone-simple for your end users to publish stuff using Zope. This may take a bit of programming. Perhaps construct an upload application which allows them to upload an HTML file which gets parsed for identifying characteristics and gets placed in the "right" area automagically or some such thing. It's definitely possible to make it pretty easy for your users to do stuff quickly. Weaning them from the publish button isn't easy, but it can be done. - wrote:
hi all,
firstly, it's not me asking that question. it's the users. here's the situation.:
we have developed a ZClass that caters for the publishing/serving of news items. we already have contents done in quark, pagemaker and other formats. users (editorial) currently cut and paste from the source.
when the users saw that they have to cut and paste, they asked why? and they pointed to frontpage, pagemill, etc as a solution.
now, we don't want that, but how can we explain the benefit of zope over the others. i have read the zope against cf, vignette thread, but that's too high level for the users to grasp, me think.
so, really, what's the benefit of using zope instead of the others; esp for the non-techies.
p/s - maybe it's our failure in providing a better solution in exporting contents from window$ apps that cause this question. help, pointers, docs, welcomed.
-- ------------------------------------------------------ http://www.kedai.com.my/kk Am I Evil?
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
-- Chris McDonough - Digital Creations, Inc. Publishers of Zope - http://www.zope.org
On Thu, 27 Jan 2000, Chris McDonough wrote:
Have you tried letting them in via FTP and/or WebDAV? Or possibly constructing an upload form for new documents that makes use of a file attachment?
I know that this is probably going to meet with some resistance :-) but perhaps you could propose an emacs editing solution? I use efs (ange-ftp works the same) now, after finding out about it on this list only a few days ago, and far from hitting 'publish' -- I just save the document on the server, and it's live. You will want to rebind ALL the keys for them first, of course.
From a user's perspective, there is little benefit to using Zope rather than FrontPage+IIS. All they know is that they can't use the "Publish" button. They don't really care about much more than that.
I don't know what kind of content you're dealing with, but you may want to illustrate something simple, such as a document with automatically-inserted standard_html_header and standard_html_footer stuff in it, so they can see that they can maintain a consistent l&f w/o the standard associated mess that's required on most sites, with little or no formatting of their own. --- The Tao is like a glob pattern: It is masked but always present. used but never used up. I don't know who built to it. It is like the extern void: It came before the first kernel. filled with infinite possibilities. [glyph@twistedmatrix.com]
On Fri, 28 Jan 2000, Glyph Lefkowitz wrote:
On Thu, 27 Jan 2000, Chris McDonough wrote:
Have you tried letting them in via FTP and/or WebDAV? Or possibly constructing an upload form for new documents that makes use of a file attachment?
I know that this is probably going to meet with some resistance :-) but perhaps you could propose an emacs editing solution? I use efs (ange-ftp works the same) now, after finding out about it on this list only a few days ago, and far from hitting 'publish' -- I just save the document on the server, and it's live.
i have no experience with emacs. i have tried it a few times though. is it available for win$ too? i use linux at home and at work. but i'm not the one who's going to update the site :). users are heavily depended on win$ guess i'll have a REAL look at emacs now, and who knows, maybe it's time to give the users a better OS.
You will want to rebind ALL the keys for them first, of course.
will emacs work with ZClass objects? i once ftp into zope, but can only see the root dir. can't see any ZClass object.
I don't know what kind of content you're dealing with, but you may want to illustrate something simple, such as a document with automatically-inserted standard_html_header and standard_html_footer stuff in it, so they can see that they can maintain a consistent l&f w/o the standard associated mess that's required on most sites, with little or no formatting of their own.
how is it with your users? do editorial users muck around with the design? i would think that editorial should stick to reporting. and if they want new feature, just tell the programmer. ------------------------------------------------------ http://www.kedai.com.my/kk Am I Evil?
hi all, i've been (and am) trying to convince people here of the zope way for some time (vs. iis / frontpage or dreamweaver). people here publish their data with frontpage or dreamweaver and some kind of template system for the layout, or (print-only) they use an old, proprietary system which i have the honour of exporting the data out of (into oracle which zope (and other systems) read from). i was successfull mostly if the area/data concerned was rather structured (eg. newspaper system, data always with title / lead / fulltext / author etc.). the argumentation mainly is something like '(more or less rigid) structure vs. freeform', 'structure' being zope, 'freeform' being dreamweaver/classical fs-based webserver. i think it's easy to find arguments for structured publishing if the data you deal with has some inherent structure -- * content/code separation * able to (manually) search on specific fields * automated search, making possible other link structures than the tree structure of the fs approach * able to change layout simply, personalisation of layout and more i guess. there's two things i think would be good to accomplish -- * making publishing of structured data as simple and fast as possible * developing more generic structures to match the data that is not-that-structured. or so i think. the "why-cut-n-past" problem below would fall into the first category i guess. my users cut-n-paste (no complaints so far). but i think it should also work if you managed to get data into *some* structure, eg. my dumb-ass approach would be to let the editors put their titles between <h1> ... </h1>, lead be <h2> .. </h2>, author a different text color, body jsut plain text, anything. just so they then can upload the document and that document gets parsed so it can be read / edited / searched / etc. later on. tell me what you think of this. ow, that mozilla build has finished _finally_. gotta play with m13 (alpha!) now :) peter. kedai@kedai.com.my wrote: hi all, firstly, it's not me asking that question. it's the users. here's the situation.: we have developed a ZClass that caters for the publishing/serving of news items. we already have contents done in quark, pagemaker and other formats. users (editorial) currently cut and paste from the source. when the users saw that they have to cut and paste, they asked why? and they pointed to frontpage, pagemill, etc as a solution. now, we don't want that, but how can we explain the benefit of zope over the others. i have read the zope against cf, vignette thread, but that's too high level for the users to grasp, me think. so, really, what's the benefit of using zope instead of the others; esp for the non-techies. p/s - maybe it's our failure in providing a better solution in exporting contents from window$ apps that cause this question. help, pointers, docs, welcomed. -- ------------------------------------------------------ http://www.kedai.com.my/kk Am I Evil? -- _________________________________________________ peter sabaini, mailto: sabaini@niil.at -------------------------------------------------
On Fri, 28 Jan 2000, Chris McDonough wrote:
Have you tried letting them in via FTP and/or WebDAV? Or possibly constructing an upload form for new documents that makes use of a file attachment? ftp is a no-no :) webdav, i have to look at.
That said, your job should probably be to make it bone-simple for your end users to publish stuff using Zope. This may take a bit of programming. Perhaps construct an upload application which allows them to upload an HTML file which gets parsed for identifying characteristics and gets placed in the "right" area automagically or some such thing. It's definitely possible to make it pretty easy for your users to do
that is in the wish list. the only thing i can think off now is lumping all existing contents in one dir, use lynx to update the appropriate properties in the appropriate ZClass automatically (cron(?)) using manageEdit, manageAdd or others. or store data in an RDBMS. but i lost out on keyword search. i would like to keep things in zodb for now.
stuff quickly. Weaning them from the publish button isn't easy, but it can be done.
it can be done, but after i'm black and blue :) thanks
At 09:45 AM 1/28/00 +0800, - wrote:
On Fri, 28 Jan 2000, Chris McDonough wrote:
That said, your job should probably be to make it bone-simple for your end users to publish stuff using Zope. This may take a bit of programming. Perhaps construct an upload application which allows them to upload an HTML file which gets parsed for identifying characteristics and gets placed in the "right" area automagically or some such thing. It's definitely possible to make it pretty easy for your users to do
that is in the wish list. the only thing i can think off now is lumping all existing contents in one dir, use lynx to update the appropriate properties in the appropriate ZClass automatically (cron(?)) using manageEdit, manageAdd or others. or store data in an RDBMS. but i lost out on keyword search. i would like to keep things in zodb for now.
Could something like xml-rpc be used to accomplish this task? Would it be possible for there to be some task which bundles up the various content, puts it into an form suitable for xml-rpc and then just contact Zope and have it execute the xml-rpc content? James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
participants (6)
-
- -
Chris McDonough -
Glyph Lefkowitz -
James W. Howe -
Jochen Haeberle -
Peter Sabaini