Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: open
Are there any known issues I should be aware of before proceeding?
Thanks for your time.
We've tried to use C2 with the FTP-server from ArgoSoft, with the result that C2 crashed every time it tried to connect to the FTP-server. With C3 there was no problem.
We've asked ArgoSoft to correct an error in their FTP-server, to fix the problem.
Besides that, I would recommend Contribute because it's very easy to deal with and you can use templates from Dreamweaver in Contribute also.
It is definitely possible to let clients edit their sites with Contribute while still retaining control over the underlying layout and structure, but you need to make sure that the underlying structure is "Contribute friendly." Here is some of what I've learned through my clients who use Contribute:
#1, in the Dreamweaver template, you want to separate the editable areas out into multiple individual editable areas. You want to define an editable area for the headline. A separate one for the body copy. A separate one for the image. A separate one for the caption for the image. And so forth. Do not give your clients one big editable content area and fool yourself into thinking they'll be able to enter headlines, bodycopy, images, etc., in the correct places. They won't. You need to restrict their options to allow them to do only what they're supposed to do, and take them by the hand and show them exactly where these various elements are supposed to go.
#2, wherever it's reasonable, you want to put structural markup tags outside the editable areas. For example, in your Dreamweaver template, don't do this:
<!-- TemplateBeginEditable name="Headline" --><h1>Headline</h1><!-- TemplateEndEditable -->
Do this instead:
<h1><!-- TemplateBeginEditable name="Headline" -->Headline<!-- TemplateEndEditable --></h1>
You'll get a silly warning from DW, but just ignore it. This kind of structure is what you need to prevent your Contribute users from turning h1s into h3s, or paragraphs, or unordered lists, or what-have-you.
Here's what my Contribute users were doing: They select the headline that they want to change, then they hit delete, then they type in the new headline. Well, guess what? When your h1 tag is inside the editable area, they just deleted the h1 tag along with the headline. Now when they type in the new headline, it's not an h1 anymore. The Contribute user has no idea how to make that headline an h1 again -- they don't even know that there WAS an h1 tag applied to the original text. All they know is, their new headline doesn't look like what was originally there, and they have no idea how to make it look like it's supposed to. When you put the h1 tag outside the editable region, the user can only delete the text, and when they type in their text, it's still enclosed by the h1 tag.
When the editable area is contained inside a <p> tag or an <hx> tag, Contribute will not allow the user to create new paragraphs, or insert a list or a table, or any other block-level elements. So obviously this technique can't be used for the main editable area, since the main editable area will almost always consist of more than 1 paragraph. But wherever an editable area can be that tightly defined, it should be -- including main headlines, subheads, images, etc.
#3, make liberal use of DW's repeating regions and repeating rows wherever appropriate, but don't make the whole repeating region editable (see my tip #2 above). Create individual editable areas within the repeating region so that you can retain control over the structure and formatting of the individual elements within the repeating region. As an example, I have several clients who have event listings on their web site -- membership meetings, receptions, lectures, etc. This kind of thing changes frequently and is perfect for clients to do their own updating. I've set up those pages with repeating regions that contain individual editable areas -- so that the client can click the little + button to add a new event, and what they get is a new listing with the date, location, details, etc., and each separate element is inside its own editable area. That way, the client can change the date but not muck up the date formatting. They can change the location, but not muck up the location formatting. And so forth. Even clients who are very computer-illiterate have had no trouble "getting" the idea of clicking the + button to add an event, and clicking the - button to remove one.
#4, if you use different link styles for the navlinks and for the content area of the page, set up your link styles so that the navlinks have your special style class applied but the links in the content area use the "default" link style. This allows the client to add a link in the content area and not have to remember to apply any special class or formatting to it; it will just automagically have the correct style. You, the developer, are perfectly capable of using classes or ids to style your navlinks, but don't expect that your clients are capable of using such classes and ids. They're not.
#5, corollary to #4, set up default styles in your stylesheet for as many elements as possible - headings, paragraphs, lists, images, etc. For every type of element your client might use on the page, set up a style for that element. You cannot expect your clients to remember that they're supposed to apply a certain class to their lists, for example. Just create a style for the list element that will apply to any list the client creates.
#6, be prepared to sit down with your client and teach them some things. Teach them that when they're linking to an external site, they have to use the entire "http://www.example.com" syntax in their links, not just www.example.com. Teach them about file naming -- for images, and for documents that they might link to, such as pdfs or Word docs, you have to teach them not to use spaces in filenames, not to use # signs, slashes, or other such characters. Teach them to use only A-Z, a-z, 0-9, hyphen and underscore. Period. Teach them this about a dozen times. Eventually it'll sink in.
#7, more teaching: If they're going to be adding images to their site, you need to teach them how to resize the image in an image editor before they place it on the page with Contribute. Contribute allows you, the site administrator, to restrict the size of an image by filesize (Kb) but not by dimension. So you have to impress upon your client that they simply can't place a 1500-pixel-wide image on the page. Give them explicit dimension restrictions, and teach them how to resize their images. Teach them that they should not use Contribute to resize the image, because that simply sets the image's height and width attributes, and we know what happens when you let the browser resize an image. With some clients (you'll know which ones) you should just insist that they have to send you any images they want to add to their site.
#8, more teaching: Teach them how to edit the titles (and other meta tags) for their pages. It's quite easy to do in Contribute, but not something the average client even knows to look for.
#9, make it clear that once they begin editing their own site, if they muck things up to the extent that you have to go in there and clean it up, that is billable time. Sure, with some clients, you'll be happy to occasionally spend 5 minutes fixing a formatting problem, but with other clients (you know which ones) you'll be getting calls daily regarding things they've messed up. You want to bill for this time. You want the client to know upfront that they will be billed for this time. You want the client to know that just because they're using Contribute to edit their own pages doesn't mean they'll never have another bill from you again for site maintenance.
#10, you need to become really really careful about re-syncing your local files before making any sitewide template changes. Early on after we started clients using Contribute, I once wiped out a client's many hours of work editing his site. He needed a template change, and I (idiotically) thought that he hadn't done any editing to his site since I last re-synced. It turned out he had edited nearly every page. Fortunately, it also turned out that we had "make backups" turned on in Contribute's settings, so I was able to restore his work, but that was, of course, not billable time on my part, and I had to eat it. I had to go through and individually restore every page from within Contribute, then re-sync in Dreamweaver, then make the template change again, and then re-upload everything. Bah! (Tip #10a: Turn on Contribute's "make backups" setting, even though it slows everything down.)
#11, use server-side includes for the main navlinks and other unchanging parts of the site. Then #10 becomes less critical, because you can make a sitewide nav change without resyncing the entire site. You just edit and upload your nav include file, and you're done, without worrying about what your client has edited.
#12, be prepared for a variety of mysterious connection problems and other issues. Contribute works fine most of the time, but it will occasionally manifest mysterious problems - can't connect to server, can't edit the page, can't create new repeating regions, etc.
In summary, Contribute works reasonably well with certain clients and certain types of sites. You have to learn through trial-and-error which ones are which. And you have to learn how to set up your templates in Dreamweaver to minimize the chances of your clients blowing things up. I have a number of clients successfully using Contribute to update their sites, but I've stopped "pushing" Contribute as a solution. I'll only set up clients with Contribute if they specifically request it. It's a PITA. Clients don't want to pay you for the time you need to spend upfront to make the site Contribute-friendly. They don't want to pay you for the time you spend cleaning up their mess. They don't want to pay you for the time you need to spend educating them about various things. They don't want to pay you for the time you spend troubleshooting the mysterious connection problems and other issues. They think that once they've spent the $150 to buy Contribute they'll never have to pay you another penny for site maintenance. Make it clear to your clients -- upfront -- that Contribute support is billable time. Some clients will end up paying you just as much for Contribute support as they would have paid you to do the site maintenance yourself.
We have Contribute running on 3 sites that I have aquired (I.E. need to re-build). This will come in very handy when I am re-jgging the templates, CSS and SSI. I hadn't considered many of the points you have raised > the 'default CSS' tip is an excellent time saver :). Cheers.