Suggestions for improving the manual

I understand that there may be some discussion on the content of the dt 3.o manual somewhere on Facebook. But for those of us who hasn’t yet bent to said intruder of our privacy, that discussion is unknown. I therefore convey here some input I have come up with from reading the first pages:

The 6 pages with detailed technical information on the binaries is not what should meet a potential new user. Just leave the slightest reference to the binaries here initially and point to an appendix for further details. (The new reader should rather meet the Overview and then quickly proceed to User Interface.)


1.3.2.1 (Introduction to basic developments steps):

“This section will guide you through the basics of developing an image in the darkroom view.” No, it doesn’t. It gives an overview of some of the elements/processes involved, and it should initially make reference to the more detailed info in Chapter 3.

In the listing of General Features in Ch. 1 “Overview” it is initially stated “Fully non-destructive editing.”. This may or may not mean anything to a newbee, (and is further touched upon first at page 13 in ch 1.3.3 “Exporting images”). I suggest that the meaning of this is developed somewhat further quite initially in ch. 1.3.2.1,( e.g. a new second section, or a rewrite of the third section where the concept of History Stack is explained). Here and/or in the Overview in Ch 1, should the potential user learn something fundamental and basic about the relations between the “development of images”, the image files, the XMP files, the database files, the History Stack and when a new file with lasting changes is created.


It would be very good if keyboard shortcuts (at least the central, non-context sensitive ones) could be listed in an appendix, so that we may print it or otherwise have the list easily available as we do our initial fumbling with dt. – And on top of that list should of course be “H” for getting the eminent new context sensitive list of shortcuts …
And, please, do include “shortcuts” in the index /pointing to ch. 1.2.6).
(While tinkering with v. 2.6 I knew several times that there was a shortcut I could use to do things easier, but could not remember easily/quickly retrieve the relevant information from the manual.)

1.2.6: “If you want the shortcut window to stay opened, there is a button [icon] right of the window.” Yes, right, but it is not intuitive to understand how to click it, as the pressing of “H” deactivates the cursor… I found that I had to preposition the cursor in the button area, an then click many times before activating it.


1.3.1.1: “When importing from disk, you can import either a single image or a folder.”. I think that to add " … or a folder (with or without subfolders)." already at this stage, may possibly alert the beginner to an issue that may have important practical consequences.

When the issue of imports are further adressed in sect 2.3.1, shouldn’t one mention also the possibility of changing the import defaults regarding subfolders and jpgs in the Preferences dialog box?


If the basic concepts of
– the basic differences between a sensor registration and the psychological retina/brain registration
– the different EV-ranges in eye, sensor, display and paper - and the need to align/compress and then selecting where we chose to “spend” the available EV-range
– the various sources of error/noise in haze, lens, sensor and the reversal system of correcting them before adressing topics of psychological perception of an image
could be explained very shortly initially in ch 1.3(.2), I think that for many of us starting to get to grips with an image editor/darktable, it would be easier to understand what is going on and what one tries to achieve.

3 Likes

Why not check out the source and make these changes yourself? You’ve pretty much already done the work.

1 Like

As a darktable newbee who is just about to grasp some of the bare basics (possibly) and one not with English as mother tongue, I’ve been somewhat hesitant in this respect.

I’ve looked at github, but am not sure what the process is like for the development of the user documentation. Can you point me to some info on how to contribute without messing anything up?

you can‘t mess up stuff - if the pull request might mess up something it won‘t be merged :wink:

OK. I’ll then have to find out what a “pull request” is and how it works. Luckily I have somebody in my close family (who is already fed up of being his fathers local tech support …) who will have to give me some answers to this.

I realize that my complete newbee perspective causes some questions, that others may also have, to get to grips with the dt beast, and that I possibly can contribute by seeking to have those questions answered in the manual.

(Be prepared for some “stupid” questions in the near future, though … )

The easiest way is to 1) get a github account, 2) fork darktable into your account, 3) make changes to the relevant files, 4) commit them to your fork and 5) issue a pull request back to darktable. Okay, not trivial, I guess… :smile:

I think it’s a good process to learn, even if you’re not a programmer. There’s a lot of prose on github managed collaboratively in this manner, not even related to programming…

2 Likes

@EspE1 I finally took the GitHub plunge several months ago. I was contributing but it involved someone passing on the message or remembering what I suggested.

The steps are quite simple actually as @ggbutcher started writing about. What I found awkward was the web interface, which I didn’t find intuitive. Some controls are hidden for the sake of minimalism and a few things require a few extra clicks to get at. Anyway, if you run into any trouble, give us a shout here. (I think most people use CLI git, which is much more powerful and easier to use than the web interface.)

Git is hard, but I think editing single files with Github is okay.

  1. Sign up at github.com
  2. Open https://github.com/darktable-org/darktable/blob/master/doc/usermanual/overview/overview.xml
  3. Click in the pen to the right of the history button
  4. Change whatever you want to change
  5. Under propose file change at the bottom, write briefly what you did
  6. Click on propose file change
  7. Click on create pull request
4 Likes

Readme says a contributor should change the document status to ‘draft’ when proposing a change.
https://github.com/darktable-org/darktable/blob/master/doc/usermanual/README

Another question: The file format is DocBook. Are there any recommendations for an editor on Linux?

I believe there is a draft type PR.

I’d just like to link this enlightening post on documentation:

https://www.divio.com/blog/documentation/

I’m going to be aiming for this for Filmulator’s docs.

3 Likes

There is too much overlap between a How-To and a Tutorial.

For your average docs project, you have 3 types of information: conceptual, task, and reference.

If you concentrate on writing minimally, you’ll be able to combine a concept topic, a few task topics, and some references into something a user can read to use your software.

My interpretation of “how-to” is that it should be very brief, limited to a single task, and have nothing but the steps.

A tutorial should run through the whole workflow and provide background info and such.

So a tutorial is a series of how-tos?

A how-to teaches the reader how to achieve a goal.

A tutorial tells the reader what some recommended goals are, and shows how to achieve them.

There will be redundant information, but they’re targeted at different audiences and thus it needs to be presented differently.

Thanks. I’ve been outlining a book about photography and post-processing, and it’s interesting to see how other people approach it. I also do user assistance for work.

@EspE1 Thanks for making detailed suggestions about the sequence in which a new darktable user encounters information. Most doc gets written by people who are intimate with the package they are writing about, and it’s very easy to assume knowledge that hasn’t been presented yet. When someone new is able to recognize these sequence errors, it’s gold.

I suggest that you go ahead and contribute your proposed changes via pull requests. If there are any language errors, then someone can submit corrections, so don’t worry about that. And, honestly, I had no problems understanding your English.

Thanks for all the useful input on github - it may be useful also for other projects.
I hope to have time within a couple of weeks to follow up on the darktable user manual.

As for the content of the manual and e.g. differentiations between How Tos and Tutorials, I do think that a manual would normally be the main source of information for how to use the product to achieve the goals of the user (-- for those of us who bothers to read anything at all, that is, and don’t just go ahead on a trial and fail basis – too often ending in failing, or at least only in a partial success). The format should therefore be (within reasonable limits) anything that helps users in achieving their goals.

Regrettably too often manuals are written by engineers who approach the manual from the perspective of the constructor, while users normally set out from a quite different starting point. (The darktable manual far from being the worst example of this.)

I believe that very often a certain level of understanding of basic concepts is important for efficient learning, and that manuals needs to provide such understanding where appropriate. I have myself found some important information on darktable in this respect from the discussions here, including some of the videos, and will aim for some suggestion for improvements in the manual by inclusion of some of these topics.

I’m pretty sure that any help improving the manual is welcome.

I do see the current dt documentation more as a reference document, where I can lookup details. The number of people how read manuals is rather limited.
Would be interesting what the discussion on FB really is about (I lost my PW for FB).