Am 14.04.98 schrieb Marcus.Brinkmann # ruhr-uni-bochum.de ... Moin Marcus!
MB> No offense meant, but I find this sort of ordering very inefficient for MB> the users. If I need information about my SB AWE soundcard, where do I MB> look? sound and HOWTO. It#s very difficult to find a good structure. This is one of the problems of a lot of WWW sites. Maybe some of Christians ideas (/ users and /devel) are not bad. MB> The ftp organization has absolutely no connection about finding But it shows the needed sections. MB> information. It has something to do with finding packages/software, and MB> even here I often guess wrong when I look for a specific package via ftp. I#ve got the same problem, but in most cases this is caused by the maintainer, because he uses the wrong section. MB> This is the wrong approach. You should know that libraries don't sort MB> books by publishers, size or color. They arrange them not in alphabetical MB> order, too (alphabetical ordering is the *last* criterium). There are Really? In most libraries they#re sorted by topic (like our section) and alphabetical. MB> Algebra and so on. The third letter gives even more information. For most MB> books, you can say what information is in the book just by knowing the Well at our library at the TU HH there#re only numbers (10 digits) on the book. MB> The people that invent such structures take a lot care about this, and MB> they know why. Searching in a big library for information can be a pain. Why? You enter some interesting words and the computer finds some good books. I would never look on the number/code of a book. MB> ordering, but it does not take into count *one* of the important things MB> you need to make information easy accesible. I don#t know which is the best solution. Let#s start with the structure itself. We could discuss the other problems later. MB> We should not be too picky about a structure now: It will evolve when MB> documents are added. However, we should have a *solid* base for a starter. That#s it. A maintainer could always add new directories (see dhelps <dtitle>). MB> I think we have the following main levels: MB> Debian MB> Administration MB> Development MB> Using (weak word, has someone a better word?). Maybe you#re right. User, Applikation? But we need sections for something like FAQs, HOWTOs, books and magazines. How should we call this root section? MB> For example, all X related documents could be stored in a single tree X, MB> but the individual documents should also be find below Administration, MB> Development and Using. I totally disagree. The maintainer should split the X11 documentation like this admin/x11 devel/x11 or better devel/libs user/x11 MB> I see no problem in using several main branches: There could even be a MB> branch that has all Apllications (similar to the menu system), that 100 documents in one directory? A very bad idea. And I don#t like the system used by menu (or dwww). This will not work, if we have got hundrets of packages using such a system. MB> collects the documents related to a single program. Maybe this is what MB> Marco has in mind? I don#t understand this. Please give an example. MB> However, we should have one or two such main branches (maybe the one above MB> and the "Application" branch that are mandatory for every document. This MB> would mean that every document has to register at least once in each of I don#t understand this, too. MB> Note that this question is very related to the structure of the Debian MB> FAQ-o-Matic, and I think they could probably be build after the same model MB> (maybe this would give the faq-o-matic a push). Please also note that this MB> does not mean that we should take the structure from the faq-o-matic (I MB> wouldprefer the other way round ;) Could you please post the structure of this system. cu, Marco -- Uni: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED] http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
