[gopher] Re: Gopherness

[Jay Nemrow <jnemrow@xxxxxxx>]

Cameron Kaiser wrote:

>>- Putting "up" or "previous menu" items in menus which points into your 
>>personal "data island".
>>    
>>
>
>This is controversial to me. I do understand the ideal nature of such
>a thing where a menu can be composed of multiple resources on multiple
>servers and still appear as if it were a unified single menu. This is
>one thing Gopher menus do better than HTML pages.
>
>On the other hand, on summary sites or menus that take only bits and
>pieces, it's hard for a user to see what else a server offering menu item
>X might offer them without such navigation. Say menu Y had a link to Z, a
>document about George Washington's toenails. The server offering Z might
>also have a document on his fingernails, but it's harder (obviously by no
>means impossible, but certainly not convenient) to find that out, and
>menu Y will not give you that unless it also connects to the fingernail
>document.
>
>This was part of why I added the U-turn icon to Overbite menus, but the
>interface is incomplete because it only appears on menus. In fact, I've
>been weighing turning the U turn icon into a XUL overlay so that people can
>do that from any document.
>
>Probably the best middle ground for this is, indeed, to have the client
>offer such "up" options.
>
I have put myself in a position of doing this "up" menu item in my own 
server as well.  This is definately something that www flexibility does 
better than Gopher strictness.  I still consider this trying to put a 
www server-centric silo scheme atop a gopherish "bits from here and bits 
from there into a larger context" way of operating.  Gopher really 
encourages people to set up their own servers and make thier own menus 
based on their own interests and perspective, perhaps pointing to menus 
located elsewhere in contexts the content owners never originally 
planned or perhaps intended.  WWW has gotten big into exercising some 
control over the owner's content and how it is accessed, while Gopher 
provides that spunky freedom that says, "Gopher provides no mechanism to 
keep this from happening, so you can get away with it."

I have been toying with trying out a convention of only pointing to 
menus on other servers, not to individual texts or files, thus forcing 
me to treat menu containers as the basic unit of interaction, all 
contained texts and files just forming part of the unit.  I miss 
something by disassociating a picture from its menu container, so I 
should always point to the container.  This doesn't solve Washington's 
toenails precisely, but may allow for keeping texts and files within a 
context.  If I were creating a menu of internet curiousities, I would 
certainly want the menu on Washington's toenails but not be concerned 
with including sibling menus that talk about Washington's dentures or 
other things, which may all be under a "Facts about Washington" menu on 
your server.  Content creators could be about creating interesting menu 
containers, and others could spend their time creating new higher-level 
menus that include references to these menu containers, thus forming new 
associations.  People who want more on Washington would need to consult 
Veronica if they got to "his tonails" via "internet curiosities".  

Gopher has but two directions basically to go: drilling deeper or 
"back-the-way-I-came".  www gives you potentially unlimited links on 
every page, which ends up putting you somewhere that was probably just 
the most tantilizing destination.  Gopher encourages focus on what you 
are after by drilling down through (hopefully) logical menus, www taunts 
you constantly to abandon your original purpose and wander about, 
hopefully to a paying advertiser ala google-ads.  Basically, the "up" 
menu item is encouraging "surfing" behavior by distracting users from 
their original intent.  I guess it gets down to what we want Gopher to 
be: a limited precursor to the superior web (in which case it should be 
abandoned in favor of the web, which most people did), or some very 
focused tool that can help you get to your intended information in as 
few steps as possible (doesn't sound fun, does it?  Gopher was created 
by universities for their needs and it basically stayed there.)

So, I hear what you are saying and I myself have pretty much done as you 
have done in creating a bit of intra-server navigation tools.  I am 
going to work to eliminate my "up" menu items.  I am going to try to 
avoid being the "most visited" gopher server on the internet, as I think 
that is a disservice to the group (and I am certainly not accusing you 
or anyone else of such a "winner-take-all" mentality).  I want to 
connect to as many other menus on other servers as I can associate together.

> Worrying about How Things Look on the Client Side
>  
>
>
>Coming from the Mac world, I do tend to have symptoms of 'the interface
>is king' disease, but I think the limited oeuvre of Gopher menus should
>keep this down to a dull roar.
>
>I don't think, however, this should restrict people from making innovative,
>slick looking clients. As long as those clients support a standard text
>display as Gophers are uniformly formatted for, go for it. After all, that's
>how we got GopherVR. :)
>  
>
I absolutely agree!  What fun is life if we can't be creative?  I hope 
nothing I say gets percieved as "restricting" how people should do 
Gopher.  (I am sending the Gopher police over to your place after they 
are done ransacking my server!)  This is just how I plan to do my Gopher 
servers and clients and my justifications.  Everyone else can say "You 
are a lunatic" and do as they please.  I just try to understand what the 
protocol is after and how to work within it.  If you have the CPU cycles 
and the video bit density, GO for IT!

>>-The Server Does All the Work
>>    
>>
>
>I think this is an extension of your PDF note above, which I basically
>agree with. It may be a bit much to expect a gopher server to, say, transcode
>or at least translocate every sort of video into a standard container, just
>for an example, and we still have the problem of determining which types are
>truly elemental (other than the Big Ten). In fact, even the Big Ten are
>arguably NON-atomic by such a standard, since some of them can be derived
>easily from other types, but they have the weight of history behind them.
>  
>
Actually, I guess I am more an advocate for simple clients.  Servers can 
be as big and burly as you please.  I think only of those c64 and zx81 
gopher clients out there and trying to come up with atomic audio/video 
formats they can handle (yikes!).  I might not be able to get a server 
(at this moment) to convert from one format to another on the fly, but I 
can do the conversion on another computer and put the resulting 
"universal" version on the server.  The basic reason for this is to give 
a one-to-one correlation to a few item types.  For example, we already 
have "g" items for GIFs and all images could be converted to GIFs for 
use on gopher - no other  item types needed for images (though gif is 
proprietary, which I don't like).  The c64 client only needs a GIF 
viewer to have the whole expanse of images in gopherspace (I think there 
is a few GIF viewers available)!  That was the point: not to add new 
item types when you can convert to a universal accessable (in this case, 
viewable) form.  You can always have different formats available for 
people who want them, but those can be 9s and the basic picture can be 
viewed by everyone as a GIF and people can then decide if they want to 
download the picture in a different format.

Something like audio or video, which was never included in the gopher 
spec, could have a universal format established and be given a item 
type, but I am not enthusiastic because older clients on older computers 
probably could not handle such things anyway.  If I want to watch video 
or listen to audio, I go to www with a modern computer and I don't ask 
for gopher to try and compete with that.  If it just must be on a gopher 
server, I can render any audio as a lyrics text or printed sheet music 
and I can render any video as a screenplay text (not that I think this 
is a complete substitute at all.)

Personally, I wouldn't bother with audio and video - GIFs for images, 
binary files for other media things.  Of course, you can always put up 
twelve different formats of "Monty Python and the Holy Grail" and serve 
it with gopher, but I hope you will include some GIF stills (the rabbit 
taking off Bors' head is a favorite of mine) and the screenplay text in 
that menu container for us poor souls that still use TI99/4a(s) at 
times!!  I would surely put such a menu in my root!

Jay Nemrow