* 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?
was thinking about how you handle rewrites, but that assumes you need
to. like I said off the top my head - maybe wrong here.
* 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
- alright I think we are on the same page here also...
* 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
Simply means that I believe _all_ of the tools being looked at meet the
requirement fully - so yes it is a requirement, but doesn't much help in
making the decision between two packages, when both fully meet it -
that's all - and of course if you think that is not true, that one is
better then other on this particular point - then it just a Yes (and
drop the red herring part)
[...]
* 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]
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.
I think we are together now
- You feel this is a serious and deciding consideration.
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.
Ok - I believe I got you thee - and we are on the same page -
* 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.
again we agree - I am only referring to the ability of the different CMS
packages being considered to implement this embedding - of course that
is only a point for decision, if it something that would be used.
* 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.
Disagree - I think the social media comment is getting you off on the
wrong leg here - as least to understanding what I am trying to describe.
I would like to display all isssues, in a given status, for a given
module.
I would like to see the latest changes made to wiki pages, for the pages
I am watching.
I would like a search box on my page that I can configure to some extent
- perhaps to search the wiki / forums / static pages for some string.
I would like to see the latest blog posting by Christoph Noack - but not
someone else.
I would like to display that last 5 emails from some set of ML.
I would like the ability to see the specs in some directory type
structure that I'm working on.
I would like to be able to drop some third party widgets onto my page.
Do I dream to lofty a dream for my personal dashboard.
Finally ( I would like ) - these are my likes not must haves, with
regards to requirements.
Why in the CMS -
I see that an issue, a defect, just cleared - I would love to go to the
forum, called up in a window, and post to the thread where the user
reporting the problem to begin with will see my comment.
I see that an issue, a RFE, just cleared - I happen to be the one trying
to keep a What's new page on the wiki up to date. I would love to open
that page for editing, right in window in my dashboard, add my
information and save it.
Can I build my own mashup for all this stuff with the current systems
(or those I see being brought up) I suppose so - can I really integrate
my actions in this page, with content creation and within the access
control systems in these different servers, from my mashup
page...doubtful, but maybe that is just my lack of skills.
Anyway - trying to not be a drag here either...just letting my
imagination run while I still can.
Thanks for taking the time
Drew
--
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
- Re: [libreoffice-website] [SC] Decision about CMS (continued)
Re: [libreoffice-website] [SC] Decision about CMS · leif
Re: [libreoffice-website] [SC] Decision about CMS · Marc Paré
Re: [libreoffice-website] [SC] Decision about CMS · Benjamin Horst
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.