Seth
You've done an excellent job of stating one of the most compelling
problems facing a web developer.
Some observations:
1. You really can't separate content from the programming necessary
to present that content... in any but the simplest sites (i.e little
or no programming).
2. HTML, browsers and client-side scripting are not robust or
compatible enough to do more than an "adequate" job of presentation.
3. The increasing demand for dynamic content, richer content and
better user interaction only exacerbates the problem.
4. Many of the content creators use the Mac Platform, most of the
programming and interactive web content tools exist only on the PC
platform and only for MSIE.
5. It is difficult (impossible?) to find content creators proficient
in both Desktop programs (Word, Quark, Photoshop, etc.) and web
presentation (HTML, CF, JavaScript, etc).
It really is a problem!!!
That said, here is the way I address some of the issues that you mentioned:
I use an independent hosting service to host both client sites and my
own development site.
I have complete access to my own development/production sites and all
client sites.
Each client client has access to his own site only.
Thus, the burden of restricting the client to his own site falls upon
the host service.
During development of a client site:
1. the databases are deployed on the client site
2. Programming is deployed on my development site
uses the db on the client site
uses proprietary programs on my development/production sites
uses proprietary development tools on my development site
3. As client programs are debugged (and paid for) they are migrated to
the client site.
4. Proprietary programs remain on my production site and are invoked
from the client site
5. If the client destroys his own site, he pays someone (me?) to recreate it!
Content Management:
Wherever I can, I provide simple (non-HTML) browser/platform
independent programs to manage content.
1. The content is entered (pasted) into form fields (usuallu copied from a WP).
2. Images are uploaded and named via form fields
3. Links are uploaded and named via form fields
4. Basic layout manipulation is approximated with JavaScript routines within
the pre-defined layout constraints of the page being modified. (The
JavaScript interactively generates some html, and adds the headings, fonts,
etc that will ultimately be provided by the CF programming).
5. The page is previewed, then saved in an "inactive" state (not viewable to
site visitors)
6. Usually, another person will review the CF program generated version of the
"inactive" pages for content and layout then activate or rework them as
necessary.
This works reasonably well for a large percentage of the clients'
need to have control over content... things such as:
Preparing publication (book, magazine, etc) articles for the web
Creating "New" news-type content
Managing Supplier/Product Spec Sheets, Listings etc.
HTH
Dick
At 4:13 PM -0400 7/3/2000, Seth Petry-Johnson wrote:
>List,
>
>A growing number of my company's clients are pushing for the ability to
>maintain the content (i.e. text, basic HTML, images, etc) on their sites.
>This really isn't that big a deal in and of itself, but these sites are
>growing more and more complex, and there is no longer a simple separation of
>"content" (i.e. the text or simple HTML itself) from its "presentation" (in
>this case, the CF logic that runs to personalize navigation systems, page
>headers, etc).
>
>Up to this point we have been simply granting clients FTP access to their
>directory on the server and telling them not to change anything that begins
>with "<CF". This is a TERRIBLE thing, and I've been fighting to move away
>from this ever since I started.
>
>Anyways, I was wondering how some of the other players out there deal with
>this sort of request from a client. One the one hand I don't want ANYONE
>but someone from my company touching the CF code, but I can understand a
>client's desire to have control over their site. I wouldn't want to pay
>$50-$75 per hour for simple HTML changes either.
>
>In particular, I'm looking to evaluate possible solutions against the
>following metrics:
>
>1) Security: giving a client FTP access to a shared CF server is obviously a
>bad idea because one client could, either on purpose or by accident,
>adversely affect other hosted sites by crashing the CF service, uploading
>templates that use CFFILE, etc. As a general rule we don't let clients
>upload CF files to the server, but this is not enforced by anything other
>than a verbal contract with the client. Whatever solution I find has to, in
>some way or another, adequately shield one client from the actions of
>another, which means unrestricted direct file access is a no-no <g>.
>
>2) Protection of intellectual property: we have a series of pre-written
>"modules" (calendar, classified ads, etc) that we sell to our clients.
>Since these are sold as pre-written applications, the client does not gain
>any ownership of the code. FTP access to the site again poses a problem
>because it makes these templates directly available to the client. A savvy
>HTML/CF author working for the client might steal this code and re-sell it.
>
>3) Cost: I'm looking for a relatively inexpensive solution right now (i.e.
>please don't recommend Spectra <g>). Neither us nor our clients are
>particuarly interested in paying huge sums of money for a feature-packed
>solution at this time.
>
>I don't necessarily need ALL aspects of each page available to the client to
>change. Certain parts of the site, such as CF-enabled navigation systems,
>can remain under my company's control. With all of these things in mind,
>does anyone out there have any pointers for me? Either links to prewritten
>applications or ideas on "rolling my own" system are welcome.
>
>Thanks in advance,
>Seth Petry-Johnson
>Argo Enterprise and Associates
>
>------------------------------------------------------------------------------
>Archives: http://www.eGroups.com/list/cf-talk
>To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_tal
>k or send a message to [EMAIL PROTECTED] with
>'unsubscribe' in the body.
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
