[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re^4: dhelp directory structure

On Wed, Apr 15, 1998 at 07:28:00PM +0100, Marco Budde wrote:
> Am 14.04.98 schrieb Marcus.Brinkmann # ruhr-uni-bochum.de ...
> Moin Marcus!
> MB> For some packages, there is no best match. Where should I put svncviewer?
> I don#t know this program.

It is a viewer for vncserver. In fact vncserver + a viewer (either
xvncviewer or svncviewer) will make a fully featured X server, so it is
appropriate for X.
> MB> In X11, because it can connect to an X server, in net, because it works in
> No, only programs like xfree or fvwm should go to this directory.

See above.
> MB> Just let us make sure that the up, next and back buttons do work properly.
> Please, no buttons. If you use buttons, the back button of the browser  
> itself will not work very well. But you can use something like <LINK> in  
> my latest doc-linux-de package. But this is supported only by lynx at the  
> moment (it#s part of HTML 3.2).

I know what you mean, those are META Tags. But let me tell you that some
people prefer links in the document, and some prefer to use the buttons of
the browser. I like "next" in info so that I don't need to go up and then
look for the next entry and then descend there.

However, this is an implementation detail and depends on the used document
reader, not on the document hierarchie (although the hierarchie can support
a certain way to navigate through documents. I will go into more details
about this later).
> MB> ? Did you ever wrote an index for a book? It is the most important part of
> Our system shouldn#t be an index but a content page! If you need something  
> like a book index you will use a search engine.

So you never wrote an index and never thought how it could be done good. I
know from some authors that they build their index manually (without help of
computers), and I have seen indices that weren't worth to be called so.
A search engine is much cheaper than an index.

Indeed as Manoj pointed out, it is not just a content page but also a way
to access the information.
> MB> a book that transfers information. I want to find the information I seek.
> All right.
> MB> I don't want to look for every possible section the program could be in. I
> That#s it. So we need a good structure and you will find the document  
> without a problem. I don#t like the idea of a book index, sorry. A online  
> help system has nothing in common with a book, if you ask me. And I have  
> never seen a help system that is structured like that. Can you give me an  
> example, please?

Well I tried to give examples how information can be accessed (index,
library management, etc). I didn't say that we should write an index, as an
index is a alphanumerical ordered lists of keywords. We more need a
"navigation", a structure that makes you descend to the right document by
> MB> > ? That#s part of the HOWTO directory.
> MB> a not supported isdn card. The HOWTO section is flooded with documents and
> MB> I only look in the HOWTO section if I already know that I need a HOWTO.
> But most users know where to find the documentation and others would use  
> the search engine.

A search engine is dumb (can you write an AI engine?). And I doubt that most
users know where to find documentation. I've heard of users that didn't know
that /usr/doc even existed. If you look in the HOWTO directory, you see a
bunch of files. I often need to read the top of several before I find what I
need. Well, I can use "grep" to find what I need, but many don't.

We do this for the user.

> MB> Marco, I simply fail to understand why you object to order the documents
> MB> in a senseful way.
> I don#t object. Maybe a structure like devel/x11 etc. is a good idea. But  
> I don#t like to register a lot of documents in more than one section. If  
> you do so, you have to register for example a book like the "Linux  
> Anwenderhandbuch" in all sections. That is nonsense. I cannot see an  
> advantage.

Not in all. Probably there is a section for general user manuals, that cover
a lot of diffrent topics ;)  But you can't deny that there are documents
taht fit *very nicely* in more that one section, and I would prefer to see
them in both. I am willing to guide unsure developers where to place
documents, create new sections if appropriate etc...

> MB> debian specific instructions to mainatin the system (info about init
> MB> procedure, kernel etc) are useful in debian and probably even a seperate
> MB> admin section.
> I think we should seperate upstream and debian documentation. Therefor I  
> would suggest the debian section.

We should seperate by content, not by origin or form. I'm not interested at
all if it is a Debian document or not, as long as it tells me the right
thing. But Debian documents will be clearly marked as superior ;)

Thank you for your input, Marco. Please see also my other reply to you, as
there I will go on now ;)


"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: