moving the website out of CMSMS

[Laurel A. Williams]

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.

>
>
> * 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?
>
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?!

> * 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.
>
> * 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
>
I guess I don't want to repeat myself much more but I would love to hear 
what others think!

Laurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: laurel_williams.vcf
Type: text/x-vcard
Size: 269 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20091118/5168eee5/attachment.vcf>