From Newsgroup: comp.infosystems.gopher

Reading about Gopher on Wikipedia I wondered about the emphasis on
hierarchy:

| It offers some features not natively supported by the Web and imposes
| a much stronger hierarchy on the documents it stores.

| Gopher's hierarchical structure provided a platform for the first
| large-scale electronic library connections.

| A file-like hierarchical arrangement that would be familiar to users.

| A Gopher system consists of a series of hierarchical hyperlinkable
| menus.


Navigating around Gopherspace I did not come across other structures
than also known by web sites that have meaningful content or index
listings at each path/level/element of their URL.

Could it be that current Gopher clients do not offer the same
hierarchical features than some older ones?

The screenshots konquerer-tree and mozilla listed in the following
resource show a tree with expandable (and collapsible) branches:

gopher://gopher.quux.org/1/Software/Gopher/screenshot

Are there clients and gopherholes that allow to navigate like this?

Is this the hierarchy feature that is meant in the Wikipedia article? https://en.wikipedia.org/wiki/Gopher_(protocol)

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Erin <erin@home.invalid> wrote:

Reading about Gopher on Wikipedia I wondered about the emphasis on hierarchy:

| It offers some features not natively supported by the Web and imposes
| a much stronger hierarchy on the documents it stores.

| Gopher's hierarchical structure provided a platform for the first
| large-scale electronic library connections.

| A file-like hierarchical arrangement that would be familiar to users.

| A Gopher system consists of a series of hierarchical hyperlinkable
| menus.

Navigating around Gopherspace I did not come across other structures
than also known by web sites that have meaningful content or index
listings at each path/level/element of their URL.

In short, you need to have a new directory to add a gophermap,
whereas on the web you can put all the web pages of your website
in one directory and just make the heirachy of sub-pages visible
to users within the web pages in some non-standard way. Or you can
serve the whole site from behind a server-side script and use a
page ID URL parameter system which might not support directories
at all.

So on the web you can put put separate pages about software, gopher
browsers, and the WSGopher32 browser, either like this: http://www.example.com/software/index.htm http://www.example.com/software/gopher_browsers/index.htm http://www.example.com/software/gopher_browsers/WSGopher32/index.htm

Or this:
http://www.example.com/software.htm
http://www.example.com/gopher_browsers.htm http://www.example.com/WSGopher32.htm

Or this:
http://www.example.com/software.php?id=0 http://www.example.com/software.php?id=12 http://www.example.com/software.php?id=79

On Gopher though, if the first two pages are to contain links
(therefore are gophermaps - item type 1), they have to be in their
own directory. So assuming all pages have links, on gopher you
would need to have:
gopher://gopher.example.com/1/software gopher://gopher.example.com/1/software/gopher_browsers gopher://gopher.example.com/1/software/gopher_browsers/WSGopher32

By consequence, you can always navigate up the menu heirachy
without needing to follow explicit links in the gophermap that
you're at. This _can_ also be the case on the web, but it often
isn't.

Could it be that current Gopher clients do not offer the same
hierarchical features than some older ones?

I've used one on Windows XP which showed gophermaps in a tree
structure. Much to my frustration I've mis-remembered the name and
had zero success finding it again now. I did trip over a couple of
much earlier clients for Windows offering the same feature though,
as shown in these screenshots:

https://www.jumpjet.info/Offbeat-Internet/Gopher/Clients/OS/Windows_3x/PNLInfo_Browser_for_Windows/snap.gif
https://www.jumpjet.info/Offbeat-Internet/Gopher/Clients/OS/Windows_9x/WSGopher32/snap.gif

The screenshots konquerer-tree and mozilla listed in the following
resource show a tree with expandable (and collapsible) branches:

gopher://gopher.quux.org/1/Software/Gopher/screenshot

That link gives me:
'/Software/Gopher/screenshot' does not exist (no handler found)

Are there clients and gopherholes that allow to navigate like this?

I remember that the author of the lost browser that I used (I might
come back with its name in a day or two) bemoaned modern
gopherholes adding 'back' type links, because this messes up the
tree view a little, but generally all gopherholes can be browsed
quite efficiently that way if the client supports it.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

| It offers some features not natively supported by the Web and imposes
| a much stronger hierarchy on the documents it stores.

| Gopher's hierarchical structure provided a platform for the first
| large-scale electronic library connections.

In Gopher, a thing you retrieve from the server is either a menu or a
file of some sort. (Searches produce menus.) During the heyday of
Gopher, HTML wasn't particularly common (or well supported in clients,
iirc) in Gopherspace, though it was possible to deliver HTML. You _can_
make the sort of mesh-like links in Gopher that are the primary mode of
the WWW, but since you can't really practically deliver content _and_ navigation in the same fetched thing, organization tends to be a lot
more hierarchical.

A lot of us had extensive discussions in our own shops and at the early Gophercons about how to deal with the fact that every person has a
different mental map to the world than. We actually had a group of
librarians at the first Gophercon (specifically to keep us honest) who
were heard to mutter about it being like library school kindergarten,
watching us flail about.

There are a few reasons why pure hierarchy doesn't work very well. The
above noted mental map thing is one. The fact that knowledge is messy
is another. Another is that bald monkeys don't seek information very rationally, and user interface design is basically the art of dealing
with that. Back then, finding the way to take a desired action (as
opposed to information seeking) was not as front and center as it is on
the web today, but it strongly affects user interface design as well.

The WWW is a multidimensional mesh (mess? ;)) where anything can link
to anything else. Early hypertext systems envisioned links being bidirectional, but didn't anticipate the democratic nature of the WWW,
where it'd be difficult to get all the reverses set up. You _can_ use a mesh-like technology (HTML links) to build a hierarchical organization,
but the user interface aspects mean its rarely done.

Real libraries deal with the information seeking side in several ways.
Call number systems are a way of creating serendipity: related stuff
lands close together on the shelf. Cataloging makes it possible to find
things via multiple paths (for libraries, titles, authors, various kinds
of subject groupings, etc) and to find related things that can't be
shelved in two places at once. (Electronic resources are easy to
"shelve" in multiple places, books are not.)

De
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Fri, 6 May 2022 19:31:26 -0000 (UTC), Erin wrote:

I wondered about the emphasis on hierarchy

The screenshots konquerer-tree and mozilla listed in the following
resource show a tree with expandable (and collapsible) branches:

gopher://gopher.quux.org/1/Software/Gopher/screenshots

Sorry to have the link wrong. Plural got lost in my original post.

Are there clients and gopherholes that allow to navigate like this?

gopher://gopher.quux.org/g/Software/Gopher/screenshots/konqueror-tree.gif gopher://gopher.quux.org/g/Software/Gopher/screenshots/mozilla.gif

Thanks for the interesting input, Kev and Dennis!

I'm more aware now, that each directory can only have a single gophermap, which helps to reflect the hierarchical file system on to Gopherspace.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Fri, 06 May 2022 18:21:43 -0500, Dennis Boone wrote:

knowledge is messy [...] The WWW is a multidimensional mesh (mess? ;))

We like to get lost in either, I guess.

Early hypertext systems envisioned links being bidirectional, but
didn't anticipate the democratic nature of the WWW, where it'd be
difficult to get all the reverses set up.

I always found the idea of bidirectional links fascinating, though it'd
be difficult for popular pages to present all the in-links somehow.

Real libraries deal with the information seeking side in several ways.
Call number systems are a way of creating serendipity: related stuff
lands close together on the shelf. Cataloging makes it possible to find things via multiple paths (for libraries, titles, authors, various kinds
of subject groupings, etc) and to find related things that can't be
shelved in two places at once. (Electronic resources are easy to
"shelve" in multiple places, books are not.)

I see; we could have all the texts in one directory (consistent naming
might be an issue), and have multiple directories only to have various gophermaps - one for each author, another to list by date, subject, ...

Since that would mean a lot of manual editing of gophermaps (or some
content management system which weren't popular then) Gopherholes
probably sticked to have simple server side creation of lists of texts
in a file directory, as in FTP.

Similarly, I found the following entry a nice read, stating that type 1
text documents (with i lines for plain text) might be annoying and that

Gopher is not the Web

gopher://gopher.unixlore.net/0/glog/gopher-annoyances.md
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 2022-05-06, Erin <erin@home.invalid> wrote:

Could it be that current Gopher clients do not offer the same
hierarchical features than some older ones?

The screenshots konquerer-tree and mozilla listed in the following
resource show a tree with expandable (and collapsible) branches:

This is a very interesting observation. I didn't use that old Gopher
clients but I'm thinking that way of presenting full tree could be in
conflict with the base idea of Gophermaps - to be bandwidth efficient.
It could takes long time, and much of transfer, to resolve full tree of
full site.
So probably it was only visualization of, for eg. recent navigation, to
have ability to going back (one or more level).

The second thing could be interesting for you is, what I've read
probably here, that there were some early version of Opera with similar functionality for WWW. They tried to simulate structure-like Gophermap.
But as I remember the author, not many pages were supporting it (it must
be special annotation in HTML structure for do this).

Sz.
--
.-=-. Szczezuja; on the small-net:
( S\ \ gemini://szczezuja.space/ - gemlog & tinylog
`--' / gopher://sdf.org:70/0/users/szczezuja/ - phlog
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

In short, you need to have a new directory to add a gophermap,
whereas on the web you can put all the web pages of your website
in one directory and just make the heirachy of sub-pages visible
to users within the web pages in some non-standard way.

I meant to comment previously that building maps was often not the
way gopher was served. In many cases we did just drop files in a
directory.

De
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Sat, 7 May 2022 14:16:36 -0000 (UTC), Szczezuja.space wrote:

On 2022-05-06, Erin <erin@home.invalid> wrote:

Could it be that current Gopher clients do not offer the same
hierarchical features than some older ones?

The screenshots konquerer-tree and mozilla listed in the following
resource show a tree with expandable (and collapsible) branches:

This is a very interesting observation.

Mosaic from like 25 years ago might have it, too?
It seems to be installable as snap (haven't tried it myself): https://snapcraft.io/mosaic

some early version of Opera with similar functionality for WWW

Good old times when the Web predominately served well structured text documents :) HTML3 for instance defined an "Up" navigation element:

| Using LINK to define document specific toolbars
|
| An important use of the LINK element is to define a toolbar of
| navigation buttons or an equivalent mechanism such as menu items.
|
| LINK relationship values reserved for toolbars are:
|
| REL=Home::
| The link references a home page or the top of some hierarchy.
| REL=ToC::
| The link references a document serving as a table of contents.
| REL=Index::
| The link references a document providing an index for the current
| document.
| REL=Glossary::
| The link references a document providing a glossary of terms that
| pertain to the current document.
| REL=Copyright::
| The link references a copyright statement for the current document.
| REL=Up::
| When the document forms part of a hierarchy, this link references the
| immediate parent of the current document.
| REL=Next::
| The link references the next document to visit in a guided tour.
| REL=Previous::
| The link references the previous document in a guided tour.
| REL=Help::
| The link references a document offering help, e.g. describing the
| wider context and offering further links to relevant documents. This
| is aimed at reorienting users who have lost their way.
| REL=Bookmark::
| Bookmarks are used to provide direct links to key entry points into an
| extended document. The TITLE attribute may be used to label the
| bookmark. Several bookmarks may be defined in each document, and
| provide a means for orienting users in extended documents.

https://www.w3.org/MarkUp/html3/dochead.html

Not sure if the current HTML specs still support those META elements for navigation -- maybe:

https://www.w3.org/TR/xhtml-modularization/abstraction.html#dt_LinkTypes
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 2022-05-06, Dennis Boone <drb@ihatespam.msu.edu> wrote:

Real libraries deal with the information seeking side in several ways.
Call number systems are a way of creating serendipity: related stuff
lands close together on the shelf. Cataloging makes it possible to find things via multiple paths (for libraries, titles, authors, various kinds
of subject groupings, etc) and to find related things that can't be
shelved in two places at once. (Electronic resources are easy to
"shelve" in multiple places, books are not.)

Are there resources/books explaining the "UX motivation" behind
cataloging systems? Your post is a great insight into early hypertext organization thanks.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Are there resources/books explaining the "UX motivation" behind
cataloging systems? Your post is a great insight into early hypertext organization thanks.

Hmm, I don't have a handy suggestion.

Some large libraries have collections of library science materials; if
you have such a library near you, finding those shelf areas and looking
for cataloging materials there might be a start. I suspect that the
Internet Archive may have some materials, though their search may not be
very effective at winnowing the results down.

Library Science BS and MS programs nearly always teach classification
and cataloging as part of the course work. I suspect there's probably
some helpful material in one the typical foundations course too.

Sorry I can't just name an author/title.

De
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Dennis Boone <drb@ihatespam.msu.edu> wrote:

In short, you need to have a new directory to add a gophermap,
whereas on the web you can put all the web pages of your website
in one directory and just make the heirachy of sub-pages visible
to users within the web pages in some non-standard way.

I meant to comment previously that building maps was often not the
way gopher was served. In many cases we did just drop files in a
directory.

I guess the web and Gopher do act the same in that respect, but
when you add links in a HTML document the enforced tree structure
that the Wikipedia page talks about breaks down. Of course you can
also serve HTML pages over Gopher, but that's not the original
design.
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Computer Nerd Kev <not@telling.you.invalid> wrote:

I remember that the author of the lost browser that I used (I might
come back with its name in a day or two)

Little Gopher Client. For Windows, Linux, and Mac OS X: http://runtimeterror.com/tools/gopher/
--
__ __
#_ < |\| |< _#
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Sat, 07 May 2022 19:39:48 GMT, meff wrote:

On 2022-05-06, Dennis Boone <drb@ihatespam.msu.edu> wrote:

Real libraries deal with the information seeking side in several ways.
Call number systems are a way of creating serendipity: related stuff
lands close together on the shelf. Cataloging makes it possible to
find things via multiple paths (for libraries, titles, authors, various
kinds of subject groupings, etc) and to find related things that can't
be shelved in two places at once. (Electronic resources are easy to
"shelve" in multiple places, books are not.)

Are there resources/books explaining the "UX motivation" behind
cataloging systems?

S. R. Ranganathan and Faceted search might be a name and topic to start looking, coming from either side, historically or current UX metaphor.

https://en.wikipedia.org/wiki/S._R._Ranganathan https://en.wikipedia.org/wiki/Faceted_search
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On Sun, 8 May 2022 05:58:10 -0000 (UTC), Computer Nerd Kev wrote:

Little Gopher Client. For Windows, Linux, and Mac OS X: http://runtimeterror.com/tools/gopher/

Wow. The sidebar listing all resources available via visited ones hierarchically makes navigating Gopherspace quite intuitive. Thanks!

From the page:

The biggest feature it has compared to most other Gopher clients is
the browser sidebar which maps the gopherspace as you go, taking
advantage of Gopher's hierarchical nature. Or at least it tries to,
since many modern gopherholes today treat Gopher menus as HTML-lite,
adding back links and such. Still, it helps to navigate faster than
without it.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

On 2022-05-08, Erin <erin@home.invalid> wrote:

S. R. Ranganathan and Faceted search might be a name and topic to start looking, coming from either side, historically or current UX metaphor.

https://en.wikipedia.org/wiki/S._R._Ranganathan https://en.wikipedia.org/wiki/Faceted_search

Thanks for the recs. I'll take a look.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.infosystems.gopher

Erin <erin@home.invalid> wrote:

Good old times when the Web predominately served well structured text documents :) HTML3 for instance defined an "Up" navigation element:

| LINK relationship values reserved for toolbars are:
|
| REL=Home::
| The link references a home page or the top of some hierarchy.
| REL=ToC::
| The link references a document serving as a table of contents.
| REL=Index::
| The link references a document providing an index for the current
| document.
| REL=Glossary::
| The link references a document providing a glossary of terms that
| pertain to the current document.
| REL=Copyright::
| The link references a copyright statement for the current document.
| REL=Up::
| When the document forms part of a hierarchy, this link references the
| immediate parent of the current document.
| REL=Next::
| The link references the next document to visit in a guided tour.
| REL=Previous::
| The link references the previous document in a guided tour.
| REL=Help::
| The link references a document offering help, e.g. describing the
| wider context and offering further links to relevant documents. This
| is aimed at reorienting users who have lost their way.
| REL=Bookmark::
| Bookmarks are used to provide direct links to key entry points into an
| extended document. The TITLE attribute may be used to label the
| bookmark. Several bookmarks may be defined in each document, and
| provide a means for orienting users in extended documents.

https://www.w3.org/MarkUp/html3/dochead.html

Not sure if the current HTML specs still support those META elements for navigation -- maybe:

Such links are valid HTML5 (I check from time to time), but I don't think sites use them much these days. There used to be extentions for Firefox
(and before that, Mozilla) that would use <link rel=""..." to construct a visible site menu, but since they keep changing how extensions work (and
thus, obsoleting a bunch of existing ones in the process), there aren't extensions left that do will support such links. Sad, because it was always nice when I came across a site that did that [1].

-spc

[1] My own blog <http://boston.conman.org/> still generates such links,
on the off chance they become use again.
--- Synchronet 3.21d-Linux NewsLink 1.2