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


Le 2011-07-04 00:01, Jean Weber a écrit :
On Mon, Jul 4, 2011 at 13:50, Marc Paré<marc@marcpare.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
it here:
http://www.mail-archive.com/design@global.libreoffice.org/msg02537.html  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.

--Jean


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.

Cheers

Marc


--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent 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.