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

Hi Drew, *;

On Tue, Oct 19, 2010 at 7:56 PM, Drew Jensen <drew@baseanswers.com> wrote:
> Quick of the top of my head thoughts, written in line as I read.
> > [...]
> > * Create static pages
> > [...]
>
> - Should the CMS have the ability to interface with a cvs system, used
> to maintain these static pages -

Nonono, the CMS should be able to create prerendered (=static) pages,
those pages are maintained with the cms and are updated when the
corresponding page(s) changes in the cms.

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

See above, no extra layer/tooling or a set of separate pages, but all
produced by the CMS.

And of course static pages should not be the only thing to prevent
load. But those static pages could for example be mirrored on a
fallback server, etc. as well.

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

Sure - for example the FAQ page on the demo is not static because of
the comment feature (it could be made static as well if one would
remove the cross-site forgery protection of the form).

> > * User-Firendly URLs
> > [...]
> - 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, [...]

Sorry, but I cannot follow: What added load?

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

Well, what I wrote in the parentheses: The system keeps track of them,
and adds corresponding links itself, the pages are not here and there
and nobody knows what translation already exist, but when you found
one translation, you have access/and overview to all translations

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

Again I cannot make sense of your comment. You agree ("yes"), and then
suggest that the reasoning is void/based on wrong assumptions ("a red
herring"), and give an explanation I cannot parse.
What package? considered What, by whom?
I'm lost with that comment.

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

Again I'm kind of lost: You tell you cannot request it and then say
it's not so much of a problem, and then go on to state that it's not
so important since most offer the same functionality.

I might understand it completely wrong, English is not my native
language, thus I'd better ask.

To clarify what /I/ meant with the requirement:
A user-friendly editor *is* important. A site that forces users to
insert the complete html manually will be no improvement compared to
the OOo website at all.
However I also noted that (in my opinion at the time, the demos I
looked at in the meantime unfortunately showed different results)
every reasonable CMS out there would provide such a user-friendly
editor, at least as an additional configuration option or similar.

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

The two have different target groups, and different usage patterns. So
you can of course link from one to the other, but I'm convinced it is
better to keep them separate instances.
Integration in ways of linking one to the other is of course welcome,
but I would never attempt to add a wiki to the CMS directly.

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

Still would be a separate instance, independent of (not provided by)
the CMS, and that is what I meant.

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

I disagree - why would you limit yourself to the website for this?
There are tons of RSS clients/readers out there, web based, download
based that offer this functionality.

> [...]

ciao
Christian

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