I may be biased as a MODX developer with enough knowledge about how everything in the systems work to be able of using a simple table with properties to find out what the exact name of that limit property was - or was it depth? I’ve been helping out with the docs for a while but that is stuff that I do in spare time (or time that I can’t put myself to work - which, as I’m a freelancer/company owner, is spare time to me) and I can’t dedicate a certain number of hours per week to it.. it’s just whenever it goes.
Now I personally feel that the quality of documentation is on a good enough level to be a reference
. With reference I mean that when you have the general perception, general idea, all you need is a nudge in the right direction. Being the name of a property, a definition of an access control or just on what tab you can find what.
I guess that’s the reason it is perceived as sucky mostly. People without this "frame of reference" don’t know what to do with certain things, or how to achieve a certain goal. Heck, something as simple as a "parameter" or "property" can lead people new to the system wondering what to do.
Perhaps that’s where the term documentation
should be introduced. Something that, like Crawford said,
Quote from: bridgecourt at Jun 16, 2011, 07:23 PM
... means that I should be able to follow instructions (even if I don’t fully understand the technical code behind them) and (without it assuming I know to do things that are not written in the doc) it should work and function.
Step by step, holding hands on every turn and most importantly: copy/paste & working. Aimed, perhaps, at someone who never used MODX before.
But then again, some parts of the documentation require two totally different documentation pieces: end-user manuals and development documentation.