Hello Alex I do understand the problem about getting information from developers, especially after 30 years in technical publications. Maybe one day developers will understand that they have to help the users actually use the product, probably when I have finally retired (being a pessimist now).
Good user guides and good help systems are a benefit to users and would reduce costs in supporting a product. After using Version 4.2 to create the Impress Guide, I think the Help has improved and does look a little more professional. Not perfect, but a step in the right direction. I have no experience at all in creating help files, so I shall not be volunteering my services. I am a book person. Regards PeterS On 26 Aug 2014, at 09:06, Alex Thurgood [via Document Foundation Mail Archive] <ml-node+s969070n412026...@n3.nabble.com> wrote: > Le 26/08/2014 07:58, PeeWee a écrit : > > Hi Peter, > > > > > In my opinion, the user guides and Help are the starting point for any > > other documentation/information about using LibreOffice. So, anybody who > > works on other documentation should check the user guides and Help so that > > the information is the same across all documentation. > > > > When writing the Impress and Draw Guides, I did check the Help of each > > module to make sure that information was reasonably consistent. It is not > > perfect and could be improved. > > > > The problem with relying on the built-in Help is that it is either > wrong, obsolete, or incomplete, especially where new features are > concerned. > > Currently, writing help files for the built-in Help system is an utter > nightmare, and involves being knowledgable in, and having the time to, > wade through a vary unwieldy set of XML conventions. The end result is > that no one wants to edit the Help files to keep them up to date. > Additionally, we encounter the well known phenonemon of developer > reticence about explaining how to actually use the new feature for which > they've just coded. Getting developers to provide meaningful code > comments is hard enough, because each has their own view on how much any > given other developer should be capable of understanding. None, as far > as I know (and I'm prepared to stand corrected), other than those > working on the Help system itself, have ever written an XML help file > for the built-in Help system. > > All of this makes it very hard to write accurate, up to date user > documentation, but the problem in itself isn't new, merely exacerbated > by the frenetic pace of development. > > > Alex > > > > -- > To unsubscribe e-mail to: [hidden email] > Problems? > http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette > List archive: http://listarchives.libreoffice.org/global/documentation/ > All messages sent to this list will be publicly archived and cannot be > deleted > > > > If you reply to this email, your message will be added to the discussion > below: > http://nabble.documentfoundation.org/User-guides-are-not-the-only-choice-tp4120242p4120266.html > To start a new topic under Documentation, email > ml-node+s969070n1645240...@n3.nabble.com > To unsubscribe from Documentation, click here. > NAML ----- Peter Schofield psaut...@libreoffice.org -- View this message in context: http://nabble.documentfoundation.org/User-guides-are-not-the-only-choice-tp4120242p4120271.html Sent from the Documentation mailing list archive at Nabble.com. -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/documentation/ All messages sent to this list will be publicly archived and cannot be deleted
