Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.