Need of a documentation framework for LibreOffice?

Hi Marc, *,

(...)

Hi Andreas thanks for the note.

Yes, the communication to the website developers by the documentation
members should be very open and frank. I think the people who are going
to put up the Drupal site are very willing to cooperate and to build
pretty well whatever you wish, if the capability is there.

that's fine.

I think it is too early to propose two cms's but we should take a look
and be critical or each Plone and Drupal and see if both can match what
they do and after this see if there is support offered by either one of
the CMS's to tweak more for what is best to make your jobs easier. Let's
take a look at both so that the best option/decision be made.

I'll encourage the Drupal developers to join the document mailist to
make things easier.

+1

BTW ... we are getting more offers for Drupal development help so the
help will be there. We have a lot of Drupal development people who are
eager to get to work on the Drupal site.

Would you know if there is a lot of Plone developer help? We should also
keep this in mind too.

I currently know another member from the German team. We managed the Authors-Website
together. But I had not asked on the website or other lists yet.

In the meantime I created some more demo-stuff. I build inside the same environment a
sub-instance (independent) and a second main instance:

http://pumbaa.ooodev.org:9080/LOTest/LODevelopment
http://pumbaa.ooodev.org:9080/Authorstest

The first is with user selfregistration.

Regards,
Andreas

Thanks, I'll take a look. Is there anyway that someone on the documentation team to sketch out the workflow. You have developed this over a few years and we don't really have a workflow to work with. This would help to demistify workflow.

Marc

Hi Marc,

Hi Marc, *,

(...)

[...]

Thanks, I'll take a look. Is there anyway that someone on the documentation
team to sketch out the workflow. You have developed this over a few years
and we don't really have a workflow to work with. This would help to
demistify workflow.

I'll try to write down our workflow once I'm back home and send the
message to the list. :slight_smile:
Btw, if you want, you can add me to the development team as well. :slight_smile:

Sigrid

Thanks Sigrid. It looks like the Drupal site development is about to go full-tilt. It would be great if documentation members would start a wishlist of features and we will see if these can be implemented.

Cheers

Marc

Hi all,
I am one of the members involved with the website team. The workflow
diagram would be great in order to kick off discussions about
implementation. Also a description of the structure of the
responsibilities and permissions required for doc development would be
great.

This is the time for blue sky dreaming because at this point anything
is possible in the community.

Michael Wheatland (Wheatbix)

Will Drupal's book module be used for the user manuals? Or will they still
be edited in ODF then "uploaded" as the web-based documentation?

Hi Jeff,

first a wish from my side: please don't sent the complete email you are answering to
with your post. Because this is a mailinglist, you need only to resent the parts,
that are needed to understand your comments.

Will Drupal's book module be used for the user manuals? Or will they still
be edited in ODF then "uploaded" as the web-based documentation?

I think, we should use for the creation of user manuals the software we are
delivering to our users. We can then use our software to convert the documents to PDF
and publish them on the website. Most people don't need the odf-versions.

Regards,
Andreas

Andreas,
I do not disagree with you with the creation of user manuals in LibreOffice.
There has been no decision regarding the use of Drupal yet, but...
The Drupal book module allows the upload of ODF and PDF files as well
as copying the contents of that document into the webpage that holds
that document, in effect resulting in a version controlled html copy
of the document and file together in one official place.

This might be very useful in the future for links from the LibreOffice
help menu/system.

I think it might help in both documentation development and end user
ease of use.
Just an idea to ponder on.

Michael Wheatland (Wheatbix)
www.wheatland.com.au

Hi Andreas et al:

I am a big proponent of ODF files and as a teacher promote these to my student (grades 4-8). It would still be nice to have he .odf versions here and there to show people that the creation of these were done on LibO in a serious work environment.

But sure, .pdf would be nice.

Jeff -- re: using the Book module for the user manuals, yes we were looking into this. You could suggest another module if you had one in mind.

The sky is the limit for everything on Drupal.

Marc
I am also on the Drupal Dev Team

I'll second the proposal that both ODF and PDF files should be available
for downloading.

For most people, and most purposes, the PDFs are fine.

The virtue of the ODFs is that users can easily add additional
notes/documentation to their copy. My perception is that having the ODF
makes it slightly easier for people to grok creating and using styles.

Jeff -- re: using the Book module for the user manuals, yes we were looking
into this. You could suggest another module if you had one in mind.

The sky is the limit for everything on Drupal.

Hi Marc--this doesn't count as a Drupal module because it's an entirely
separate application, but I had purchased KBPublisher (
http://www.kbpublisher.com/) for a project I was working on several months
ago and we ended up not using it. I had purchased the "Small Biz" one. It is
a dedicated documentation application which supports a "book" type layout.
You can see a demo of it here: http://www.kbpublisher.com/kb/1/

I don't know how firm you guys are on using Drupal, but I have a license
that I am not using for this software, and I wouldn't mind donating it to
the project (I have no use for it). So, for what it's worth, it's available
for use if you guys want it.

Jeff

Jeff, as I have mentioned there has been no official decision made on
using Drupal at the current time.
As for being 'set' on using any one system, I think the vast majority
of us can agree that free open source software is the way to go.
There will be discussions within the website group as to the backbone
of this once the workflow and other requirements are set.
Thanks heaps for the offer!

Michael Wheatland (Wheatbix)
www.wheatland.com.au

Hi everyone,

I'm also on the website team,

The workflow diagram would be great in order to kick off discussions
 about implementation. Also a description of the structure of the
 responsibilities and permissions required for doc development would be
 great.

This is a most have, thanks for pointing it out.

The Drupal book module allows the upload of ODF and PDF files

Ok, with the Upload module.

as well as copying the contents of that document into the webpage that holds
that document,

I didn't know that :smiley: How can this me done? To had that requirements
(modules/tweaks) to the wiki.

in effect resulting in a version controlled html copy
of the document and file together in one official place.

+1 with the Diff module.

Cheers

Hi everyone,

Hi Marc--this doesn't count as a Drupal module because it's an entirely
separate application, but I had purchased KBPublisher (
http://www.kbpublisher.com/) for a project I was working on several months
ago and we ended up not using it. I had purchased the "Small Biz" one. It

is

a dedicated documentation application which supports a "book" type layout.
You can see a demo of it here: http://www.kbpublisher.com/kb/1/

Free software using not-free software.... mmm I'm not sure this is the kind
of message LibreOffice want. But thanks for your offering.

Drupal is quite strong, the demo site you showed help me out to go search
this functionality.

After two hours investigating :S I did found something similar:

http://drupal.org/project/booktree

And the demostration here:

http://uccio.org/booktree

As it is a list, it is easily styled.

I did also found this other helpful modules:

This will help allowed users to modify the outline of a book easily:

http://drupal.org/project/outline_designer

Adding this other two:

http://drupal.org/project/flat_book
http://drupal.org/project/tableofcontents

Will could get a nicely book ready to get printed:

http://drupal.org/project/print

Or using the export feature of the book standard module.

:smiley:

Hi everyone :smiley:

> as well as copying the contents of that document into the webpage that
holds
> that document,

I didn't know that :smiley: How can this me done? To had that requirements
(modules/tweaks) to the wiki.

Found it :smiley:
http://drupal.org/project/odfimport

So cool :smiley:

Cheers

Maybe the drawing I created some time ago[1] (according to the
description given from Jean resp. the oooauthors list) can be helpful
for discussion. Feel free to use or change it. Note, that it may be
inaccurate or outdated.

Verbal description (AFAIR):

There are 2 main workflow pathways: A simple one for internal documents
and another one leading to externally published documents.

The internal path only has 2 states: draft & published internally.

The external path includes 3 different document states:
internal draft,
pending review (which means, submitted for publication),
published externally.

Transitions are, of course, submission, publication, and retraction (the
latter leading back to draft state[?])

L10N: Documents from any state might give rise to translation
activities, which again would open the same (or a similar) workflow for
the (now localized) document.

The main 2 problems in the (folder based) Plone system IMHO was to find
a document (where is the newest version?) and to get a quick overview
over the project state (how many documents are in which state, how many
untranslated documents, etc.). Hence, keeping track over the project
had to be done mainly by a human (i.e. Jean :wink: ).

Also missing are "minor" state informations e.g. "checked for software
version X.Y" or "indexed" or "branding updated" or similar (which is a
minor point but nice2have, and could be done e.g. by tagging).

Nino

[1]
http://wiki.services.openoffice.org/wiki/User:Nnino/Drafts/Oooauthors_Workflow

Thanks for the help Nino. We will also take a look at this.

Marc

Maybe the drawing I created some time ago[1] (according to the
description given from Jean resp. the oooauthors list) can be helpful
for discussion. Feel free to use or change it. Note, that it may be
inaccurate or outdated.

Nino, thanks for posting this. Not only does this illustrate the challenges of creating / updating documentation (which others may or may not be aware of), but it may also give us time to reflect on this process and see if there are solutions available that could at least help make it slightly less tedious.

- Gabriel

Yes, and if you leave your comments on this thread, we will look at this from the point of view of a Drupal website. We will tailor it to your needs. We can make it work the way that you want.

Marc

Hi everyone,

Thanks Nino, that's just great.

> Thanks, I'll take a look. Is there anyway that someone on the
> documentation team to sketch out the workflow. You have developed
> this over a few years and we don't really have a workflow to work
> with. This would help to demistify workflow.

Maybe the drawing I created some time ago[1] (according to the
description given from Jean resp. the oooauthors list) can be helpful
for discussion. Feel free to use or change it. Note, that it may be
inaccurate or outdated.

Verbal description (AFAIR):

There are 2 main workflow pathways: A simple one for internal documents
and another one leading to externally published documents.

The internal path only has 2 states: draft & published internally.

The external path includes 3 different document states:
internal draft,
pending review (which means, submitted for publication),
published externally.

Internal published documents are owned by (who can edit it) a user, a open
group or a closed group (membership)? What is the difference between users
who can edit/create internal documents and those who can edit/create
externally published documents?

Transitions are, of course, submission, publication, and retraction (the
latter leading back to draft state[?])

L10N: Documents from any state might give rise to translation
activities, which again would open the same (or a similar) workflow for
the (now localized) document.

The main 2 problems in the (folder based) Plone system IMHO was to find
a document (where is the newest version?) and to get a quick overview
over the project state (how many documents are in which state, how many
untranslated documents, etc.). Hence, keeping track over the project
had to be done mainly by a human (i.e. Jean :wink: ).

Also missing are "minor" state informations e.g. "checked for software
version X.Y" or "indexed" or "branding updated" or similar (which is a
minor point but nice2have, and could be done e.g. by tagging).

No problem, this can be done with "Taxonomy" feature within Drupal. Also
with "Views" we can generate reports on that information. What kind of
reports would you like to have?

- List of internal documents, ordered by date. (each document, "node", as
revisions, so no problem, almost like a wiki).
- List of internal documents, grouped by workflow state.
- List of internal documents, filtered manually with terms (published for X,
Y, etc).
... What more?

I really think we are going to need a Dashboard on the website so users
can accommodate their work or interest on their dashboard.

Cheers

Note/Question: Should I cross-list?