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]
