Nowadays, software documentation appears to be something superfluous and we should feel lucky (or even grateful) if one is delivered with the software we are using. One thing is for sure, software documentation rarely appears to be considered as a part of the software development process itself. It has become something that is often written after the fact, just in case. However, this is a wrong approach. When I was teaching software development, I always told my students that even if they had produced a working code, the job was still not done if they had not correctly commented the source code and if they had not written an accurate and comprehensive documentation.
The documentation is like the software specifications : it describes accurately how the program behaves and how it can be used. It’s not only a manual, it’s also a reference. Software and documentation must be in sync.
Any change in the program modifying its behavior or its interface has to be reflected immediately in the documentation.
Reversely, the developers should always make sure that their code behaves accordingly to what the documentation describes.
If the software doesn’t behave as described in the documentation, there’s a bug to fix. Either in the documentation or in the code.
Software documentation has to be written by a technical writer (it’s a real job) who is involved in the development process from the beginning.
Software documentation should be available in permanent (static) form, not only as online contents. It has to be accessible at all times. So, a PDF version should systematically be available and synchronized with the online version if any. We all agree that paper documentation is no longer a good choice for many reasons. However, this doesn’t mean that we no longer need a real and comprehensive document.
Videos and blog articles do not form a documentation by themselves. They complement it but should not replace it.
The quality of the documentation is a part of the product’s quality.
I certainly wouldn’t say that DxO’s policy regarding documentation doesn’t comply with any of the above but I think that there’s room for progress. For example, it’s impossible to say if the available documentation is in sync with the product. There’s no version number in the online doc and the PDF version of the DPL doc always has version number 1.0. Also, I recently posted about the automatically generated PDF version of the Nik v3 doc which is merely a failure (obviously, nobody had a look at it - and given the price of the update, we could expect something more serious).
I do not agree with the “modern” vision of software documentation. Many say that a good software doesn’t need documentation. This is wrong. Especially when comprehensive books about the software are not available on the market. The up-to-date documentation is the reference allowing to facilitate the discussion between users and support. This is a part of the contract. If documentation and software don’t match, one of them has to be fixed.
I agree with you in all points and i have also learned to document technical environments, workflow and functions to give anybody an overview, or a “helping hand”.
And yes, with every version of an environment or software you have to modify the documentation, set a major or minor version number and you have to distribute it to the important recipient in our case the DXO Users.
The attempt with the question mark within the function to give a short overwiew is good beginning, but then you get a hint to the user manual, and if it is not actual???
But I have seen more worst documentation in the last years
Actually, the PL3 PDF documentation can be obtained from the online documentation page. Go to it and click on the 3 dots button at the right of the language selection dropdown in the blue bar. From there you can export the full documentation as a PDF file.
Unfortunately, this PDF appears to be generated automatically and has a lot of formatting quirks. The table of contents in the PDF reader is say, exotic and at 100%, the font size is too small. All this gives it an unprofessional look.
Actually, I think that an updated PDF version of the documentation should be installed with any new version. Looking back at the long history of DOP/DPL since version 1, If I remember well, this was the case in older versions. Not sure, though.
Ok I’ve got it under https://help-photolab3.dxo.com/de/home …haven’t noticed the 3dots before.
I would like to got the MAC Version PDF too, can anybody share the link
Thanks
I was referring from within the website, not from within the program.
In the program I did find the html-version but never had thought of such a difficult way to get the pdf. Google was faster.
Still left that there’s is no manual to find via the website.
I should have also mentioned that a good documentation can be a very effective marketing teaser. Very often, when I hesitate to install the trial version of a software, I look for the documentation to have a feeling about how it works. If the documentation is easy to find and well written, this is an encouragement to further explore that software.
i my mind a good documentation is layered in three sections:
1 - global view of what’s in there: getting your driverslicence so to speak.
in text-manual, movieclips and small popups behind the “?”
2- a detailed documentation how to use those functions.: getting comfortable in your with options loaded car to create a optimal workplace. (the urban driver in buzy traffic)
3- a technical documentation: the one who explains how things work in a more deeper manner. like what’s ASB do and ESP and how they interact in certain moments. (race licence.)
So you can stop at any moment at a level your comfortable with.
Video’s are a good supportive media: like watch and see, then read some more about what interested you to learn it’s controls. it’s a visual example what’s possible and how to get some results but less functional for learning the details because it’s to fast or to slow or … pick yours.
Short video clips connected on the tool “?” are great for explaining the functionbuttons.
Indeed a paper/hardcopy does help to make notes and reminders on the side line when studying.
Yes,
Affinity books are great, or for Lightroom the books by Scott Kelby.
You got a theme or photo, you got an aim, and you are guided through the tools and settings
They explain failures you possible could make and you got killer tips and tricks.
I like the videos by Dan Hughes because they are structured, and for me as non english native speakers it’s important that the trainers don’t have a strong slang.
I remember the time I started working with Lightroom and I love the videos by Julieanne Kost . Short videos with mostly one theme you can follow and then apply the workflow to your own photos.
I agree I also found the Affinity documentation and video’s good. Videos short to the limited point of the exercise, a training video rather than a multitude of bits a pieces. The few PL videos I have watched, apart from all have been on a Mac while most users appear to be Windows, should have been 2 maybe 3 much shorter ones each covering one thing as the Affinity ones that I have watched do.
. Short videos with mostly one theme you can follow and then apply the workflow to your own photos.