Are you assuming that someone is going to want to wander thru cyberspace
wanting to read what other people like to read? It sounds that way.
Perhaps indeed the non-tech folk will want to travel that way - sort of
the tourist approach. As a tech, I hate to admit that I do this occasionally
- I will see someone advertise their home page of pointers in their
.signature and I will go take a peek.
> get it. We need a way of maneuvering through these mountains of FAQs.
> and the current Usenet tree hierarchy is *extremely* burdensome.
What type of maneuvering are you thinking of - a parallel to wandering
thru the public library, looking for something to read, or going to the
library to find a specific book that you want? In the latter case,
the usenet group hierarchy is exactly what I want - I go to the
directory for the group where such a topic would be found and I look
at the FAQs in that directory to find one answering the question I want.
Sure it would be nicer if all the FAQs were WAIS'd so that I could just
type a question - I don't think this is being done right now because
of the size of the database - anyone out there interested in dedicating
a few gigabytes to that database? Seems like it would be VERY useful!
> It appears to me that we have missed the basic distinction between
> POINTERS TO INFO and ANSWERS TO QUESTIONS that FAQs represent. In the
> former case, the FAQ is extremely burdensome in the current form. In
I agree there is a distinction. What is the specific problems you have
though for the use of the FAQ for pointers - I use both techniques in
my comp.lang.tcl FAQ and as long as I don't have typos, I think that
the pointer technique works out very well. In particular, the hypertext
version of my FAQ lets folks go right to the source from the text.
> to utilize in hypertext form. But *nothing* on rtfm.mit.edu supports
> traversing `pointers to info' painlessly, unless you think that CD and
> LS are `painless traversing'.
RTFM isn't a hypertext server - so one should not plan on using it in
that way. It could be used as the 'home' of files to which a hypertext
server (elsewhere) can point to info. I don't see the problem with that.
It seems to me that you want one server to serve all types of data - that
just isn't going to be practical. What we need to do is to distribute
the load around the net - let gopher servers do their thing, WWW servers
do their thing, and when one comes to the end of a chain of pointers to
a pointer to a flat file, then point off to the ftp servers . gopher
and www will hide the current hierarchy from the user, allowing them to
do searches, clicks, etc. to get where they want to go.
> T.Fine points out that people like to *browse*, and that they are
> *browsing* like crazy on his server. This whole idea of CDing and GET
> is so @#$%^&* non ergonomic and nerdlike. Gopher is so popular because
> it lets humans traverse and surf information with the mere glance of an
> eye, swish of the wrist, and click of the button.
Note 1 that T.Fine's server is a WWW server. Two - Gopher and WWW,
in the browse mode, is doing the cd/get's for the user - the commadns
are still going on. Again - separate the hidden structure from the
user's interface. In the future, perhaps someone will distribute intelligent
internet agents where one will just verbally or by script say 'Go get me
info on C++' and the software will access WAIS databases, and go
directly to the file, avoiding cd's and get's altogether.
> Therefore, I propose that we come up with a new classification of FAQs,
> what might be called POINTER PAGES. a PP is nothing but a big hypertext
Why not just call them personal home HTML pages? That's what are evolving
out there in cyberspace/the web. Take a look at folk's home pages out
there and you will see that. But to be honest, I would almost NEVER
use something like this to try to find something- I would use one of
these personal pointer pages to explore. But to find things, I want
instead to go to a text search server - like the meta indexes on the web -
to have it do the hunting for me. Going the PP route just means there
is even MORE documents one has to browse before finding the particular
something useful that is out there.
> servers with a minimum of hassle. And the best PPs will become the most
> popular, and people can create PPs to PPs ad infinitum.
With millions of people on the web popular is going to become
meaningless - I mean, look at the 'popular' tv shows. Millions of people
may indeed want to watch the Superbowl - but it wasn't something that I
wanted to watch. And in many cases, there are many arguments that the
quality of tv suffers because the networks try to anticipate what will
be 'popular' and caters to that lower common denominator. I wouldn't
want to see the same thing happen on the net - but it's going to (aka
Prodigy, Delphi, Compuserve, etc.).
> But look how much hassle it is for anyone today to come up with their
> own favorite list of services and put it on a server!? you have to
> virtually be a gopher guru and own your own FTP site. The beauty of
Nope - I would never run a gopher only server - I would just compile up
one of the HTTP servers and run a corner of the Web if I could get
permission here.
> I would like to see a set of sites and operators who are committed to
> allowing *anyone* to come up with their own PPs and put them on their
> servers for the benefit of all humanity. Send me mail! I will keep a list!
All it requires right now is a place to ftp the page - there are many
such ftp servers available. Hundreds - if not thousands.
> *anyone* can submit to with a *minimum of hassle*. Let's amplify the
> best features of the system! rtfm.mit.edu being the only site for
> *public submitted information* IMHO is an extreme bottleneck. We could
Actually, there are many other sites which also maintain archives. The
problem seems to be either they don't advertise or else we as FAQ owners
don't advertise the alternate systems.
--Larry W. Virden INET: lvirden@cas.org Personal: 674 Falls Place, Reynoldsburg, OH 43068-1614
[
Usenet Hypertext FAQ Archive |
Search Mail Archive |
Authors |
Usenet
]
[
1993 |
1994 |
1995 |
1996 |
1997
]
© Copyright The Landfield Group, 1997
All rights reserved