Re: [libreoffice-website] [SC] Decision about CMS

Quick of the top of my head thoughts, written in line as I read.

> ========================
>
> [libreoffice-website] CMS requirements / suitability testing
>
> Christian Lohmaier
> Wed, 06 Oct 2010 23:39:10 -0700
>
> Major points any CMS must fulfill:
>
> * Create static pages
> In the past, on the OpenOffice.org website with SourceCast (now named
> CEE) we often had the problem of the site going down because of the
> amount of requests. A pure php driven site, even with php-accelerators
> very likely will put too much load on the server.

- Should the CMS have the ability to interface with a cvs system, used
to maintain these static pages - even if the CMS offers a way to create
static pages it is hard to conceive of not having people contribute
pages created outside of it. 

- load can overwhelm poorly integrated sites, even if some of the pages
are static - of course this can me mitigated even further by looking at
using static pages where it is planned to receive the vast majority of
entry into and exit from the site, either from that single static page
or through a well thought out path that leads to same. 

- If however you have a nice static entry location, but then to do much
of anything the users will be pushed into displaying content from, or
sending input to, the CMS system then the benefit is reduced.

> * User-Firendly URLs
> People want to be able to guess what a link is about. Pointing someone
> to http:://example.com/<randomnumber> is bad, better point to
> http://example.com/user-faq
> Also important for search-engines and the like

- Yeah OK - details for any good implementor to be given as part of the
task, I don't agree with all the arguments there but I understand them
and believe just about any system can be set for that - is it worth the
added load on the systems, and implementation time, in the end...many
feel so and I suppose then it is.

> * Support for Translations
> Key pages should be available in multiple languages, the CMS should
> support managing those (without having the editor keep the list of
> translations in sync, without the editor needing to update all
> translations with a new link)

- define managing


> * Support for subsites
> As LO is a huge project, with lots of different areas where work is
> being done, the CMS should support multiple subsites. (like for
> example on OOo the various native-lang projects, the marketing,
> distribution, etc. projects, that have different focus and needs)

- yes ( I think this is a red herring as no package is being considered
were this is a concern )


> * sufficiently sophisticated user-rights system
> Not every user should have the possibility to change every aspect on the 
> site. Some parts are reserved to be edited by admins, some areas are 
> free to be messed-around by community members. Specifically, it should 
> support a review/approval workflow.

- OK
> * user friendly editor
> Probably not so much of a concern, as many will use the same tinyMCE,
> but nevertheless an important topic

- ambiguous - either is an import topic (factor in choice) or it is, not
so much of a concern. (need to chose) [I would go with the "not so
important", as most offer a workable baseline of funtions]

> Those are the basic requirements
>
> Areas it does not need to provide:
>
> * an own wiki
> Specialized wiki-software is always superior

- Should the two work together, could you embed the output of one into
the other, can you use the CMS to create wiki pages?

> * own Forum
> See wiki

- see above - pretty much all decent BBS now are such that they can be
embedded. It is still a separate system and can be used such of course.

> * random other addition (blog, whatever)
> see wiki / we have dedicated planet

- and it would be great to have the ability to build my own personal
"Planet" - so if I work on, or an tracking, issues, activities or user
opinions expressed in social media service sites, I could construct my
page to display this aggregated view - the issues, and activities and
even projects that I might be interested in today may be different from
those 3 months from now - so I would prefer that this not be a static
choice of data stream sources. 

- I am of course expanding the definition of planet there, just used for
artistic flairt :>)

Drew

> ========================
>
> Having now the specs., we have narrowed down the choice to Silverstripe 
> and Drupal.
>
> Here are the demo sites:
>
> Silverstripes: http://pumbaa.ooodev.org:7780/ -- advocated by Christian 
> Lohmaier
>
> Dupal: http://www.mywebclass.org/~bhorst/contact -- advocated by Keith 
> Williams
>
>  From here we should first examine if both of these fill the basic 
> requirements as laid out in the specs up above.
>
> Marc



-- 
E-mail to website+help@libreoffice.org for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/website/
All messages you send to this list will be publicly archived and cannot be deleted