moving the website out of CMSMS

Tue Nov 17 21:48:07 UTC 2009

Hi all,

I agree with Jonathan and Alison that it's worth taking some time to  
explore our needs and use cases. This thread seems like a great place  
to do that. Laurel, Jess, Jacob and others, I'd love to hear your  
thoughts on how we currently use our Web site and any short/medium  
term needs that you think will arise.

Here's a list of other questions and thoughts that have emerged for me  
from reading this thread:

* Accessibility is not an option for us on our site--we struggle  
enough with tools like Confluence and JIRA that are problematic for  
many users. Let's not add any more. Our Web sites should be robustly  
accessible and flexible. And also simple. :)

* 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.

* 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

On 17-Nov-09, at 3:09 PM, Alison Benjamin wrote:

> Good afternoon,
>
> I agree with Jonathon that it depends on what is trying to be  
> accomplished! I am personally happy with the site as-is as a  
> frequent "end user". That said I also think that it would be good as  
> Laurel points to show off as much of Infusion "in action" on the  
> Website (I am not sure how much this is the case now). As Everett  
> points out having a site that is accessible for users that create  
> content is also important. If we did go with drupal, it would be a  
> great opportunity to make some Infusion modules for that CMS.
>
> Thanks,
> Alison
>
> On Tue, Nov 17, 2009 at 2:52 PM, Jonathan Hung <jhung.utoronto at gmail.com 
> > wrote:
> I think what we choose will depend largely on what we want to  
> accomplish.
>
> If we're looking to build custom features, deliver a lot of content,  
> and desire a lot of control over the presentation, then Drupal may  
> be a good choice.  (If we're ambitious and have the resources,  
> Drupal would be an excellent choice to bring together the Wiki, and  
> Jira into a cohesive location.)
>
> If we're looking for collaboration, then MediaWiki may be a good  
> route?
>
> But if we're wanting something simple to get the message across,  
> then a slightly modified Wordpress is effective.
>
>
> But my question is: What are we trying to accomplish through the  
> website? The answer may help us decide what we do next.
>
> - Jonathan.
>
> ---
> Jonathan Hung / jhung.utoronto at gmail.com
> Fluid Project - ATRC at University of Toronto
> Tel: (416) 946-3002
>
>
>
> On Tue, Nov 17, 2009 at 2:32 PM, Jacob Farber <jacob.farber at utoronto.ca 
> > wrote:
> Is there a reason we're only thinking in terms of CMSMS or not  
> CMSMS? What about other, more powerful cms's?
> Jacob
>
> On Tue, Nov 17, 2009 at 2:11 PM, Laurel A. Williams <laurel.williams at utoronto.ca 
> > wrote:
> Hi all,
>
> For some time now, we've been discussing moving the website out of  
> CMSMS. I'd like to start a discussion of the pros and cons of doing  
> this and also talk about some techniques we could use for  
> accomplishing the task if we decide to do it. Here is the jira task: http://issues.fluidproject.org/browse/FLUID-3355
>
> Advantages that CMSMS gives us:
> 1) The ability to allow various community members to post to the  
> website with specific roles such as editor, administrator, and  
> designer. We do not take advantage of this ability right now. The  
> only people who edit the website all have admin access and there are  
> very few accounts.
> 2) CMSMS allows us to use fixed templates for the header, footer and  
> other common code blocks so we don't have to edit and maintain  
> common code blocks on each page.
> 3) CMSMS provides some add ons, such as the news pages, breadcrumbs,  
> menu generation and rss feeds with very little work. It also  
> provides a maintenance mode for when we are doing upgrades (a site  
> down message is displayed.
>
> Disadvantages:
> 1) Being constrained by CMSMS has made editing somewhat onerous for  
> experienced web app developers. The CSS is stored in the DB in one  
> place, the common code chunks in another, the content for individual  
> pages in another place. The interface for editing the pages is not  
> very user friendly for people who are used to tweaking html in text  
> editors or using their favourite html editing environment.
> 2) CMSMS continues to evolve and updates are tricky. There is always  
> a danger of breaking the site when we upgrade and not upgrading puts  
> the website at risk for security flaws.
> 3) Having the website in CMSMS does not allow us to version the site  
> or revert changes easily.
>
> So, if we are merely using CMSMS because of advantages 2 and 3, we  
> should think about alternative techniques.
>
> Some thoughts:
> a) We are a javascript focused project - maybe we should use  
> javascript to tackle these problems. This could have the advantage  
> of allowing us to showcase the Fluid framework on our own website.  
> Colin suggested using something like Kettle to manage various  
> includes. Jess also suggested I develop a 'menu component'.
> b) I've been doing a lot of PHP lately for the builder. PHP is  
> another option. I think its main advantage is that it would be quick  
> to swap over the current CMSMS site to PHP.
>
> I am sure the community has lots of ideas to contribute on this  
> subject, so looking forward to your thoughts.
>
> Laurel

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org