We should solicit input from the OFBiz SI community.
I would think that they would want end-user documentation in a form that
they can easily brand and customize.
This makes me think that DITA would be a good source target since it
would allow SIs to produce customized and branded documentation in
different formats including on-line help and manuals in PDF.
They could override or enhance individual topics as required.
They could change fonts, layouts, logos and colors to suite their
corporate image or brand it in the customer's scheme without having to
touch the content.
Translation is easier in DITA.
Ron
On 24/05/2015 7:41 AM, Sharan-F wrote:
Hi Ron and Todd
Thank you both for the feedback and I've taken a look at the links you
mentioned. (I think this could be useful in the other discussion thread I
created around the online application help and the idea of extracting it
from OFBiz so that it could be maintained, updated and then re-introduced or
packaged separately as another project deliverable or an addon. Ron - I have
a feeling of what you're going to say here....:-)
When I created this discussion thread my main focus was on getting some
agreement on the help content and we are beginning to talk about available
technologies to manage it, store it and make it accessible. I agree that
these are all valid points and linked to creating a the complete strategy.
A while ago I started putting this together
https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmaphttp://
<https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmaphttp://>
so it is something that can be developed as we progress and get more
information.
I'd really like to get some movement on improving the OFBiz end user
documentation. I started with a re-organisation and consolidation of the
Technical Documentation which is complete, so now we have the content
updated, we can decide what to do with and how to manage it (i.e tools,
format etc).
The End User documentation isn't at that stage yet so I wanted to get at
least some agreement about the minimum it could contain so that we could
start building a structure around the content.
I'd like to use a similar approach that I used for the consolidation of the
Technical Documentation and in this case we will be merging data from at
least 2 other workspaces plus the wiki into (hopefully) a single coherent
user guide.
At a high level this is where I'd like to go using what we have in place now
(i.e. Confluence)
1) Let's agree some minimum content and structure for the end user wiki
documentation
2) We review what we already have that fits into those categories and
structure
3) We identify any areas where documentation is missing
4) We create documentation for the missing areas
5) Once we have a complete guide then we can decide on what technology we
use to manage it going forward.
I know it's only small steps (though some of these tasks may be significant)
but I hope it will take us in the right direction so that at least we have
something useful that our users want.
Thanks
Sharan
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/DISCUSSION-OFBiz-End-User-Wiki-Documentation-tp4668872p4668952.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
