httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Re: 2.0/manual/howto/htaccess.html etc.
Date Thu, 01 Aug 2002 22:54:47 GMT

Hi Kess,

>> There are no links yet. The front page is getting a little cumbersome
>> with all the links, and I was not actually sure where to add the link.

In my opinion the start page tries to serve several purposes:
 a) Be easy enough to use and not too filled up with links
 b) Link to every important article.
So with every new article "b)" may enforce a new link and make
the goal of "a)" more difficult to achieve.

And some of the links on the start page are there because they
point to important documents (did anyone ever try to evaluate
the http://httpd.apache.conf/ access_log and check the access
frequencies of all the pages?), and others because they are
necessary in early stages of user experience, and others just
because there may not be any other reasonable place for them
(like the platform specific notes that I would remove from the
start page - one link to their index page might suffice, if
they were placed inside a common directory).

I think the start page is a good "bookmark" style page, but it
is not optimized to teach the user which documents are available
- this might rather be the task for the links in the grey table
beneath the Apache feather.
So I would suggest to create a "howto/index.html" page and add
a sixth table cell to this dark grey table. Maybe even some of
the current howto links of the right column of the main page
might then vanish and make the start page less loaded again?

> Maybe we think to hierarchical. What about the following?:
> Grouping the howtos at the main index page into 5 or 6 main topics which
> link to a section at a new howto/index.html. Each section contains the
> links to all howto pages related to this topic.

Anyway, I never really understood the difference between a
"howto" article like "howto/cgi.html" and a non-howto article
like "content-negotiation.html"; all I know is that "on the right
side of the start page there are most of those valuable concept
articles that one should have read first of all, especially
before ever reading any of the directive descriptions".
For me, the "howto"s are no natural group of documents - or
they should rather include some other articles as well, like
all that are named under "Using the Apache HTTP Server" on the
right side of the start page.
But if they should be considered as a separate group, why not
give them their own light-grey headline, best with a link on
it to their "howto/index.html" page?

> The same howto may be linked within more then one group and may
> have with different link descriptions.

I don't quite get the idea here. Do you mean "linked from
within documents of more than one group" or "have more than
one link with different link description to the same file"
(which then would easily confuse some readers)?

> This would allow a more intuitional navigation.

How nice - it's revolution time, talking about alternatives
for such an established thing as the navigation concept. ;-)

As I see it, the nature of the links between Apache documents
is currently mainly links from inside the document text.
Except for the starting page, not a lot of the documents has
some explicit "navigation" section like the one you suggested
(if I got you right) which would make all "related" ;-)
documents available from within each document of the group.

To additionally supply such a "context navigation" might be
a good idea; it would allow for some more sequential travel-
ling through the documents, while currently there is hierar-
chical navigation the one to be used in most cases.
The Apache manual is already a web, not a tree; but there
are many more ways to group the articles. One might be to
group all "howto"s together; another one might be to group
all articles of "related" topics together. If so, I would
rather like to find a link to "suexec.html" inside the
"howto/cgi.html" article than a link to "howto/auth.html"
which is "technically simular" but not "related by content".
I am fully aware of the fact that it would be difficult to
define which topics are "related", as there may be many
different opinions about that.

Two possible requirements for such a context navigation:
a) It should be ready at hand without too much scrolling
   (maybe like a separate column of the document body -
   I just had a nice little project where they taught me
   how to do table-like layout without tables ;-)
   The layout for such a group of links to "similar"
   documents (let's coin another term for it) might be
   the same as the layout of the
   page - a list of links on the left side in a separate
b) It should be generated automatically if possible, i. e.
   the group structure of the "related" articles should
   somehow be available for a program.
I don't know how the current "sitemap.html" document is
maintained but I am afraid any additional navigation that
would have to be updated manually at many different places
would mean a lot of work.
(My sitemap file
is generated by my own Perl script, thus I don't maintain
anything there; and if I wanted to insert HTML navigation
elements into a lot of related documents I would try to
use SSI/CGI for this purpose. Actually, I am doing so at
where the "source files" indeed are Server Side Includes
but are fetched by some Perl script via HTTP/LWP::Simple
and stored into static HTML files - I am doing rather similar
things as the XML->HTML conversion tools, only with my own
little programs and on a lower level, using Apache as the
One of the XML to HTML generation freaks might possibly
write some lines about whether adding auto-generated parts
relating to _more_ than one document into each HTML output
file would be possible using the current transformation
tools - the information in question is now distributed over
XML files and even directories and would have to be fetched
automatically, can any XML tool do that?

Regards, Michael

(aware of the very futuristic aspects of this posting)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message