Le 2011-07-04 00:01, Jean Weber a écrit :
On Mon, Jul 4, 2011 at 13:50, Marc Paré<email@example.com> wrote:
Not sure if you read this but maybe you should take some time. Bernhard has
summed up all of the reasons that were proposed on uniformization on this
discussion thread in a recent post. Just in case you missed it, you may find
think he has put it all very eloquently and as plain as possible. I think
the reasons for writing up protocols are overwhelming.
I respectfully disagree with Bernhard that there needs to be the
uniformity between marketing screenshots and documentation
screenshots. And while it may be desirable to have uniformity among
the documentation screenshots, I don't think it's a big deal that they
are not uniform. We can develop the uniformity as we update the docs
for other reasons.
That said, I completely agree that having guidelines for documentation
screenshots is a good thing. Note: guidelines, not rules. Marketing is
a different matter: much more important there.
Quite honestly, this is exactly what we are looking at -- guidelines
that will allow members to tool up easier and to contribute.
If we are clear on what the basics are needed to contribute with
screenshots, then we will allow a group of individuals who, maybe not as
interested in diving in with the authoring/editing process of
documentation, but interested in helping out with the peripherals
involved in creating documentation.
If both the documentation and marketing/design teams happen to have
similar or divergent sets of guidelines really does not matter. It is
having a clear set of guidelines. IMHO, better if we can coordinate and
then share "screenshot contributors" between teams.
I also think that it would be strange if the documentation team were to
decide to allow different theme screenshots in manuals. I cannot think
of a quicker way to confuse readers than to allow this. Not sure where
David is suggesting here. Whenever I was asked to evaluate a set of
manuals for educational software, the team that I was on looked
seriously at the consistency and clarity of information being used
throughout the manuals. I don't believe we would ever adopt manuals that
would not have a consistent and clearly set method of documentation.
Documentation should really bring to the user a sense of familiarity
without being confusing. I think adopting different themes for
documentation would lead to unnecessary confusion for our users. But, if
the documentation team decides to go this way, then so be it.
Let's get the guidelines completed and I will try to get them set as
Gnome/KDE themes for easier setup so that we can offer people to
contribute and alleviate a bit of the authoring from our writers.
Impressum (Legal Info)
: 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