[drupal-docs] Idea - move help text out of code into database
Charlie Lowe
cel4145 at cyberdash.com
Fri May 13 06:33:17 UTC 2005
I think whether or not the documentation is hardcoded or not is up to
the development team. What we need to do is facilitates the process by
which we can hand off to them the documentation that they need. They can
then decide whether to handcode it or not. This is sort of why I
suggested a sort of single-sourcing approach. Previously (although I
can't find it now), someone suggested an outline for the handbook for
modules. This is what I would do (sorry I can't find the other one;
google desktop failed me ;)
Introduction (on the main page, just 1-3 paragraphs)
- Overview of features
- In depth explanation (just for some modules)
- HowTo's (if available)
- Configuration tips/troubleshooting (if available)
This is obviously open to revision, but the idea is that this would be
the main structure for all the items listed in the "Drupal modules and
features" section (http://drupal.org/node/279), including core and
contrib modules. Some of these items above might end up with subpages.
Not all modules would need this in depth a structure. But, the
Introduction and Overview of features would be constructed such that it
fits in the admin/help. In some instances, developers might choose to
include more (but we can leave that up to them).
Then, when we update the documentation, we post an issue for developers
to plug it in as a revision to the admin/help. They take it from there.
Whether or not it is hardcoded in doesn't matter for us as documenters.
Developers can decide what is the easiest way to implement it. We just
have to provide it.
For an example, this piece of documentation for the sprint fits that model:
http://dev.bryght.com/t/wiki/BookHelp
It has an introduction, overview of features, and a howto.
This also gives us our plan for development. The introduction and the
overview has to be done first. We add in howto's if they are available
or we happen to be writing them anyway for some other purpose. But we
don't worry about developing more docs until those are done first.
We also may reach a point where we limit how much is included there: how
much "howto" and configuration tips, etc. More important than the volume
of documentation is that we arrive at a place where we can maintain the
documentation, be able to update it readily for new releases. So for
instance, a documentation sprint at codefreeze for a new release, where
our first priority is to update all the introductions and overviews so
that it can go into the admin/help.
Charlie
puregin wrote:
> I'm going to re-float here on both lists the idea of having each
> module's help texts provided within the Drupal database, as opposed to
> being hardcoded in.
>
> Advantages: the help text documentation would be
> - easier to maintain
> - easier to translate
> - easy to tailor to user's experience level and preferences
> (tag each helptext with a 'User experience level" vocabulary
> and select the text according to the user's preferences)
>
> I think it would make the code easier to maintain also.
>
> Code review and documentation review could occur
> independently.
>
> Comments?
>
> Djun
>
More information about the drupal-docs
mailing list