An external comment on the English language PL manual

Here everybody can post his problems with PhotoLine

Re: An external comment on the English language PL manual

Postby greenmorpher » Wed 07 Mar 2012 01:22

bkh wrote:
greenmorpher wrote:Incidentally, three of the problems with the manual are not German > English translation but rather conceptual.

That's just what I wanted to say – imo, the translation isn't the main problem – but while I can spot enough mistakes in the manual, it's hard for me to judge how much a native speaker might mind. Writing a manual by going through menu entries and toolbars isn't a very good way of writing a manual – a concept and task oriented approach would be much better but is also much more difficult to do.

There are a few more points which might need attention, and which might be easier to fix.

1) different terminology for similar or seemingly similar concepts, for example: selection – mask – lasso , mask – layer mask – clipping layer, alpha channel – transparency – opacity – intensity


As I've said before -- whether we like it or not, Photoshop has become the standard and sets the standard in this field. Regardless of whether we like that or not or the terms used in Phothop re the most exact descriptors or not, PL needs to use those terms, as does every other raster editor. Likewise Illustrator and vector. If PL uses such terms, incidentally, it is easy for people to use tutorials for these other programs an apply the lessons to PL.

bkh wrote:2) the index of the manual is poor (e.g., there is no entry "Antialiasing", and the only reference is the "Antialias" button while it should also refer to the Attributes panel)


Yep, I've raised a number of such problems over time. I suspect the index was built done manually. In fact, automatic indexing then mkanual editing down of the result is much better.

bkh wrote:3) a glossary is missing (the explanation about antialiasing and small palettes should probably to there)


BUT also in the text. In manuals, it's important to have redundancy so when a person is doing something and needs the information, the information as it applies to that specific process is available right there, in front of them. BUT the same information is also needed in a general context e.g. a glossary, so a person can go to that for explanation apart from when they are in process of doing something which involves that information. So information needs to be written in, then the whole thing edited back so the redundancy doesn’t bury eveyrthing (and make the manual 20,000 pages long!).

bkh wrote:
greenmorpher wrote:And just reading it right here, does this antialiasing apply only to vectors?

No, it also applies to bitmap layers when their pixels aren't aligned with the pixels of the background layer. In fact, the manual entry should also state that the button only affects layers whose antialias setting is "Default" and which aren't contained in a group whose setting isn't "default".


And right there is a failure of the manual -- it doesn't tell us all we need to know when providing a general explanation. It provides only part of the explanation of the tool when it should provide all of it.

The point made about developers not writing manuals is generally valid -- although Ole Kvern and the Freedhand book is the exception that proves the rule -- he is both a gifted developer and writer and graphic artist. He worked on PageMaker and FreeHand with Aldus, and currently is with Adobe working on InDesign.

In general, though, if small developers want their work to gain more recognition and customers, they need to go to the next step and employ a writeras good as they are to put together the manual -- or at least to edit it.

As for the limitations of translations -- translating is a highly skilled business. I have supervised and directed translators in multilingual journalistic and broadcasting settings and done some translating myself involving two Papua New Guinea languages. I understand the difficulties. In a manual, the language actually can be imperfect but that will be okay provided the concepts and structure are right and -- in this case particularly -- there are plenty of graphics.

This is a graphics program -- the language that needs to be used is the language of graphics. Not words -- pictures! With a minimum of words.

Cheers, geoff
greenmorpher
Mitglied
 
Posts: 622
Joined: Tue 29 May 2007 14:42
Location: Melbourne, Australia

Previous

Return to Discussion about PhotoLine

Who is online

Users browsing this forum: CCBot/2.0 and 0 guests