I don't know how useful this information is, but... I learned this afternoon that the jQuery web site is going to move from a MediaWiki based site to Word Press. The jQuery team claims the primary reason is to manage comment spam while allowing for a greater level of community involvement in their documentation. Apparently they felt that the moderation tools in WordPress provided them what they need.
- Eli On Nov 17, 2009, at 11:52 AM, Jonathan Hung 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 / [email protected] > Fluid Project - ATRC at University of Toronto > Tel: (416) 946-3002 > > > On Tue, Nov 17, 2009 at 2:32 PM, Jacob Farber <[email protected]> > 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 > <[email protected]> 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 > > > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work > > > > > -- > Jacob Farber > University of Toronto - ATRC > Tel: (416) 946-3002 > www.fluidproject.org > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work > > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work . . . . . . . . . . . . . . . . . . . Eli Cochran user interaction developer ETS, UC Berkeley
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
