Re: [documentation-dev] Recruiting for on-line help
G. Roderick Singleton wrote: Members of the project should be aware that Uwe Fischer [EMAIL PROTECTED] is recruiting on other lists such as dev@openoffice.org, OOoAuthors and [EMAIL PROTECTED] Please track down these messages if you want to get involved. Thank you, ger Looks like I have a bad habit of not posting on my favourite mailing list. I must apologize. Here is my mail again: Recently we asked for ideas on the OOo mailing lists how we can improve the installed Help of StarOffice and OpenOffice.org. One good idea was to add more links that point to external documents written by the community. Currently, at the end of many Help pages you find Additional information or See also ... sections. These links stay within the installed Help system, or they link to portal pages like documentation.openoffice.org which will work without page not found errors for quite a time. Given the ever changing availability of external documents with regards to version, operating system, and language, as well as their Web locations, a database approach seems to be appropriate. Now we want your feedback about the following proposal a) the Help Viewer already knows about the operating system, version, and language of the installed Help. Additionally, the user will be able to select additional languages to read external documents that are only available in those languages. And the user will be able to disable the Web search for additional documents, and to redirect the search to a folder on the local file system. One idea is to offer a drop-down list box with the main languages. The current Help language already has a check mark by default, and the user can select more languages. Enable external Web Help: (none) v english german french ...etc... Choose (none) to disable Web Help from the Internet. An additional check box locally installed documents can be enabled to display links to documents that are stored in a given folder on the hard drive. Every user can store own documents here, which must contain some meta information to be shown at the right location of the Help. b) The current Help page gets some additional entries in the More Information... or See also... section. These new entries are visible only if Web Help is enabled and if such help is available. If the Web Help is enabled and if the current shown Help page contains a link to the new Web Help feature, then the Help Viewer connects to the server over the Internet. The Help Viewer sends the following information: - the current Help page - the current version of the Office software - the current operating system - the selected languages for external Web Help The server evaluates this information. If any Web Help document is available for the current page (topic), version, operating system, and language, the respective link or links are returned. These links will be shown in the See also... section. The user can click the link to load the external document. If no suitable document is found, the server returns the following text: For this Help page we have no external document at this time. You may consider changing your langauge selection at Tools - Options - ...etc... Visit documentation.openoffice.org if you want to write an external Web Help document for the current topic. The server evaluates the Help pages and languages for which Web Help was asked. These data will be published periodically. The information helps to improve internal and external Help offerings. c) There is a database running on the server. The community maintains the database. When for example a Language Project has some new documents, the respective links will be added to the database. There might be a Wiki to simplify adding and editing the hyperlinks together with meta information about visible text, language, version, operating system. A script will update the database based on the Wiki information. This is what I propose. Now please let us discuss this concept. Give feedback if you want it in such a way and if you think it can be done. Then we need to find some community members who really do all the work. What do you think? Regards Uwe -- [EMAIL PROTECTED] - Technical Writer StarOffice - Sun Microsystems, Inc. - Hamburg, Germany http://www.sun.com/staroffice http://documentation.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [documentation-dev] Recruiting for on-line help
Hi all, Uwe Fischer wrote: G. Roderick Singleton wrote: Members of the project should be aware that Uwe Fischer [EMAIL PROTECTED] is recruiting on other lists such as dev@openoffice.org, OOoAuthors and [EMAIL PROTECTED] Please track down these messages if you want to get involved. Thank you, ger Looks like I have a bad habit of not posting on my favourite mailing list. I must apologize. Thanks Uwe for this really interesting proposal. This needs several work to make it available I imagine, but for the projects who already have several documentations ready it will improve interaction between the OLH and the local documentation projects. I'm also forwarding your mail to the NLC as our native lang projects are also concerned and some of their leads might not be subscribed here. I'll invite them to pursue the conversation here. Kind regards Sophie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [documentation-dev] Recruiting for on-line help
Hi all, I'm answering between your lines : Uwe Fischer wrote: [...] Currently, at the end of many Help pages you find Additional information or See also ... sections. These links stay within the installed Help system, or they link to portal pages like documentation.openoffice.org which will work without page not found errors for quite a time. Given the ever changing availability of external documents with regards to version, operating system, and language, as well as their Web locations, a database approach seems to be appropriate. Yes, +1 :-) Now we want your feedback about the following proposal a) the Help Viewer already knows about the operating system, version, and language of the installed Help. Additionally, the user will be able to select additional languages to read external documents that are only available in those languages. And the user will be able to disable the Web search for additional documents, and to redirect the search to a folder on the local file system. ok, however, I'm not sure if the operating system is needed here. Most of the time, the differences between one system or another are explained inside the documentation we provide. One idea is to offer a drop-down list box with the main languages. The current Help language already has a check mark by default, and the user can select more languages. Enable external Web Help: (none) v english german french ...etc... ok Choose (none) to disable Web Help from the Internet. An additional check box locally installed documents can be enabled to display links to documents that are stored in a given folder on the hard drive. Every user can store own documents here, which must contain some meta information to be shown at the right location of the Help. I really like this idea, this will allow companies to use their own documentations database. b) The current Help page gets some additional entries in the More Information... or See also... section. These new entries are visible only if Web Help is enabled and if such help is available. If the Web Help is enabled and if the current shown Help page contains a link to the new Web Help feature, then the Help Viewer connects to the server over the Internet. Ok, The Help Viewer sends the following information: - the current Help page - the current version of the Office software - the current operating system - the selected languages for external Web Help The server evaluates this information. If any Web Help document is available for the current page (topic), version, operating system, and language, the respective link or links are returned. These links will be shown in the See also... section. The user can click the link to load the external document. Should we decide of a common file format ? If no suitable document is found, the server returns the following text: For this Help page we have no external document at this time. You may consider changing your langauge selection at Tools - Options - ...etc... Visit documentation.openoffice.org if you want to write an external Web Help document for the current topic. Will this message be localized ? The server evaluates the Help pages and languages for which Web Help was asked. These data will be published periodically. The information helps to improve internal and external Help offerings. yes, great idea too. Will it be mentioned somewhere that this documentation is contributed the n-l projects ? I think this could attract more people to contribute to our documentation projects. c) There is a database running on the server. The community maintains the database. When for example a Language Project has some new documents, the respective links will be added to the database. There might be a Wiki to simplify adding and editing the hyperlinks together with meta information about visible text, language, version, operating system. A script will update the database based on the Wiki information. It seems a good process to me. This is what I propose. Now please let us discuss this concept. Give feedback if you want it in such a way and if you think it can be done. Then we need to find some community members who really do all the work. I'm recruiting people in the FR community in order to help (but you know it's vacation time...) Shall we use the script (allfiles.tree) that Frank Peters has done to help us debugging the localized OLH files as all the page files are referenced with it ? Kind regards Sophie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [documentation-dev] Recruiting for on-line help
Hi Sophie, Sophie Gautier wrote: Hi all, I'm answering between your lines : me too If any Web Help document is available for the current page (topic), version, operating system, and language, the respective link or links are returned. These links will be shown in the See also... section. The user can click the link to load the external document. Should we decide of a common file format ? my initial thought is that the system will open the linked document. So it doesn't matter if it is OpenDocument or PDF or HTML or some exotic ancient format like doc. On the other hand it would be good to open the external document within the Help Viewer. In this case it should be in HTML 3.2 format, because this is what we currently see there. But this approach may need additional changes to the Help Viewer, while just sending out the link should work right now. If no suitable document is found, the server returns the following text: For this Help page we have no external document at this time. You may consider changing your langauge selection at Tools - Options - ...etc... Visit documentation.openoffice.org if you want to write an external Web Help document for the current topic. Will this message be localized ? sure yes, great idea too. Will it be mentioned somewhere that this documentation is contributed the n-l projects ? I think this could attract more people to contribute to our documentation projects. yes, there should be a special heading preceding all external links. It can tell the user that the following links are external, will open a browser or PDF viewer, and that the community has written them and that the user can contribute, too. I'm recruiting people in the FR community in order to help (but you know it's vacation time...) Shall we use the script (allfiles.tree) that Frank Peters has done to help us debugging the localized OLH files as all the page files are referenced with it ? don't run too fast ;-) It's just a proposal at this time. Regards Uwe -- Uwe Fischer Senior Technical Writer Tel: x66756 Sun Microsystems, Inc. Tel: (++49 40) 236 46 756 Nagelsweg 55mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [documentation-dev] Recruiting for on-line help
Uwe Fischer wrote: Hi Uwe, Given the ever changing availability of external documents with regards to version, operating system, and language, as well as their Web locations, a database approach seems to be appropriate. Yep, good idea. I take it the db would be hosted by Collabnet ? Now we want your feedback about the following proposal a) the Help Viewer already knows about the operating system, version, and language of the installed Help. Additionally, the user will be able to select additional languages to read external documents that are only available in those languages. And the user will be able to disable the Web search for additional documents, and to redirect the search to a folder on the local file system. Sounds good. One idea is to offer a drop-down list box with the main languages. The current Help language already has a check mark by default, and the user can select more languages. Sounds good. b) The current Help page gets some additional entries in the More Information... or See also... section. These new entries are visible only if Web Help is enabled and if such help is available. If the Web Help is enabled and if the current shown Help page contains a link to the new Web Help feature, then the Help Viewer connects to the server over the Internet. This sounds good too. The server evaluates this information. If any Web Help document is available for the current page (topic), version, operating system, and language, the respective link or links are returned. These links will be shown in the See also... section. The user can click the link to load the external document. If no suitable document is found, the server returns the following text: For this Help page we have no external document at this time. You may consider changing your langauge selection at Tools - Options - ...etc... Visit documentation.openoffice.org if you want to write an external Web Help document for the current topic. The server evaluates the Help pages and languages for which Web Help was asked. These data will be published periodically. The information helps to improve internal and external Help offerings. c) There is a database running on the server. The community maintains the database. When for example a Language Project has some new documents, the respective links will be added to the database. There might be a Wiki to simplify adding and editing the hyperlinks together with meta information about visible text, language, version, operating system. A script will update the database based on the Wiki information. This would be one way of making it IMHO easier for people to contribute, plus have the added advantage of a document presentation structure that could be inherent in the wiki front-end, so that at least the help entered via the wiki would have more or less the same 'get up'. This is what I propose. Now please let us discuss this concept. Give feedback if you want it in such a way and if you think it can be done. Then we need to find some community members who really do all the work. Well, the French n-l doc project list has been pretty active already, and there are quite a few docs that could be entered into the system. However, I do wonder about selecting based on OS. Most of the problems encountered are OS-agnostic. The only real differences occur with things like installation, printing, fonts, and the like. As Sophie has pointed out, we try where possible, to make our docs platform independent or at least include relevant sections for each similar family of OS. It would be a shame to have to split them all up again. I take it that there will be some kind of flag system when you enter the doc database that will enable you to set the search parameters you are talking about ? Is this what you meant by metadata ? Alex Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
