Hi all,One of the key reasons to use a CMS is because it allows us to permit greater numbers of people to contribute to the website, and provides control access for users based on roles. It allows people who aren't all that familiar with HTML, css, etc. to contribute to the website without a huge learning curve. At the moment, we do not have numerous people contributing to our website and we do not take advantage of the roles available in CMSMS at all. Basically we just use the CMS as a website framework to provide the elements I mentioned in my email - common code blocks, rss feed, menu display, news, etc. Previously, we may have had community members who kept the website text up to date, etc. who weren't all that html saavy, but that isn't the case right now.
It isn't clear to me that we need the capabilities of a CMS for the fluidproject website, based on its current use. Allowing lots of people to edit the website doesn't seem to be one of our requirements at this time. It would be nice, however, if the people who do edit the website, could do so without the constraints of using a CMS, unless there is a good reason to do so. I haven't thought of one yet, but others may have ideas.
I'll address some of Colin's points inline tomorrow.
Yes, you can link to static css elsewhere. CMSMS has a technique for editing "templates" (basic html common to each page) and attaching css which stores the html markup and the css in the database. You can minimize the use of these techniques using tactics like linking to static css, but then, why would you bother using the CMS if you wanted to do this? Why not just use something else?!* Laurel, can you elaborate more on this problem with CMSMS requiring CSS to live inside the database? Are you saying that we can't just link to static CSS files on the Web server?
* Custom content types and feeds: it seems to me that we don't have much need for strongly typed notions of content. Many content management systems enable custom types to have first-class status within the system, for example articles or calendar events. So far, our site is generally simpler and more Webbish. Most of our content consists of HTML, CSS, and media such as video, audio, and images. We want to be able to more easily link in dynamic content as needed, and ensure that we don't ever have to cut and paste markup, CSS, or code.Exactly my point. We aren't really using the tools. Is this because our website requirements do not include these tools, or is it because CMSMS doesn't do it well? I suspect it is the first option.
I guess I don't want to repeat myself much more but I would love to hear what others think!* In the past, we had one RSS feed consisting of news articles managed by CMSMS. An upgrade to their News module caused the feed's URL to break permanently, something that is unacceptable for any incremental version update. Upon reflection, we realized that we are probably better off to use our WordPress blog for RSS feeds anyway, rather than to have multiple feeds. So that simplifies things a bit.* The question of PHP vs. some custom JavaScript vs. a real content management system really comes down to what we need and how we use it. If we don't need access controls, news feeds, or other custom types, what sorts of advantages might CMSMS or Drupal or other system provide for us? Is it really the case that we just need something that can attach headers and footers to our pages for us? Or do we need more?* Performance and simplicity are probably essentials for a public Web site. If we see a surge of interest or popularity, it would be great to withstand a Slashdotting if necessary. Our community should be able to easily and naturally update content. Static HTML, PHP, or (arguably) super-simple JS are advantageous in this respect. That said, if we find ourselves having to roll custom code that we could otherwise reuse in a CMS, then we need something more robust.What do you think? Let's keep this conversation going! Colin
Laurel
<<attachment: laurel_williams.vcf>>
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
