[Fwd: Re: moving the website out of CMSMS]

Laurel A. Williams laurel.williams at utoronto.ca
Tue Nov 24 17:28:44 UTC 2009


Forgot to cc this to the list.
Laurel

-------- Original Message --------
Subject: 	Re: moving the website out of CMSMS
Date: 	Tue, 24 Nov 2009 10:32:39 -0500
From: 	Laurel A. Williams <laurel.williams at utoronto.ca>
To: 	Jess Mitchell <jessmitchell at gmail.com>
References: 	<4B02F54F.5010701 at utoronto.ca> 
<3a7c8e890911171132q78826285g7bb7f80b85f0603c at mail.gmail.com> 
<ee4dcf0b0911171152s593c1a65ubd613502b8c95551 at mail.gmail.com> 
<E981DC3C-116C-456B-B61E-DE79720F3087 at media.berkeley.edu> 
<A8CC2231-E173-493A-BDE8-D7D26EBB030E at rsmart.com> 
<72576C64-ECAF-423B-B0E2-DF3BF58CB7CE at gmail.com>



Hi Jess,

I'm not sure what the answer is. I like the ease of use of a CMS, but I 
don't think that we actually use CMSMS to it's full effect. I'm 
reluctant to suggest we use another CMS or even Wordpress because I 
don't really think they are the right tools for the job.

It would be very easy to provide the common code blocks of the current 
website using plain old php within the next week or two - since the php 
is basically just html it is very easy to maintain. On a less urgent 
timeline, we could follow that up by integrating fluid components to not 
only provide the common code blocks, but also use the pager component 
for the news page, re-implement the UI Options demo on the website, etc.

As for the priorities you've listed below, I think this plan would be 
able to accommodate most of the elements listed. With the website saved 
in the svn, it will be easier to work on a freshened design and updated 
text without impacting the live site.

Integration with the wiki is a whole separate problem that I'm not sure 
how to address. I think you might need to elaborate on the problem a 
little bit.

Laurel

Jess Mitchell wrote:
> Dear All,
>
> I wanted to say a few things in this thread but wanted to wait until 
> the kernels of corn had slowed their popping frequency.  So, here's my 
> question:
>
> Can we build up our website without a CMS with the following requirements:
> accessible
> pithy and easy to navigate
> dynamic -- audio and video are already here -- as are great Fluid 
> components
> easy to update for team members
> nimble -- able to incorporate new Fluid components as they come online
> For me the priorities for our web presence are:
> freshened look and feel
> freshened content (incorporate Fluid Foundation work, sensibly make 
> clear the different Fluid projects and Fluid products)
> no downtime
> no spam
> no DOS
> an integration plan for the wiki -- folks who go to the wiki should 
> not "fall out of" the website
> sensible urls (e.g. fluidproject.org/demos 
> <http://fluidproject.org/demos>)
>
> So, I ask again, can we build this site without a CMS and accomplish 
> these priorities?  Or, as Jonathan said, will a modified Wordpress get 
> us there?  In other words, what is the best, lowest cost to entry 
> solution?
>
> Best,
> Jess
>
> On Nov 19, 2009, at 12:20 AM, nate.angell at rsmart.com 
> <mailto:nate.angell at rsmart.com> wrote:
>
>> FYI: One of the best spam-protection, comment moderation tools out 
>> there is Mollom, which integrates with wordpress and drupal, among 
>> others. 
>>
>> On Nov 18, 2009, at 9:08 PM, Eli Cochran <eli at media.berkeley.edu 
>> <mailto:eli at media.berkeley.edu>> wrote:
>>
>>> 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 / jhung.utoronto at gmail.com 
>>>> <mailto: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 <mailto: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
>>>>     <mailto: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
>>>>
>>>>
>>>>
>>>>         _______________________________________________________
>>>>         fluid-work mailing list - fluid-work at fluidproject.org
>>>>         <mailto:fluid-work at fluidproject.org>
>>>>         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 <http://www.fluidproject.org/>
>>>>
>>>>     _______________________________________________________
>>>>     fluid-work mailing list - fluid-work at fluidproject.org
>>>>     <mailto:fluid-work at fluidproject.org>
>>>>     To unsubscribe, change settings or access archives,
>>>>     see http://fluidproject.org/mailman/listinfo/fluid-work
>>>>
>>>>
>>>> _______________________________________________________
>>>> fluid-work mailing list - fluid-work at fluidproject.org 
>>>> <mailto:fluid-work at fluidproject.org>
>>>> 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 - fluid-work at fluidproject.org 
>>> <mailto:fluid-work at fluidproject.org>
>>> To unsubscribe, change settings or access archives,
>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org 
>> <mailto:fluid-work at fluidproject.org>
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>
> ------------------------------------------------------------------------
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
>   
-------------- 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/20091124/0d7c58ed/attachment.vcf>


More information about the fluid-work mailing list