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


On Mon, 2011-07-04 at 03:27 -0400, Marc Paré wrote:

Le 2011-07-04 00:01, Jean Weber a écrit :
On Mon, Jul 4, 2011 at 13:50, Marc Paré<>  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
it here:  I
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.



For documentation, I would prefer the document to use the same style
throughout. Most people will not change the "factory" default color
settings unless they are connected to the OS defaults. The possible
difference between OS versions would be OS dependent layout and
rendering of the icons. 

Jay Lozier

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.