[gopher] Re: Gopherness

["Matthew Holevinski" <eylusion@xxxxxxxxx>]

To Jay:

May I quote you?

"  This is what happens when how something
looks is much more important than content.  The modern world-wide-web is
increasingly content-free, more a springboard for advertisements and
snappy graphics or a cool interface. "

/me bows in humbleness

I couldn't of said it better myself. I have reached the limit of my
tolerance for all things
Googlesque, and increasingly corporate websites that have absolutely
no reason for
existence or better ones life 1 iota. Google must have the absolute
worst search engine
in the world. I believe I read this one article by a fella who listed
100 search engines I'd
never even heard of before and listed reasons why each one was better,
and after browsing
like 50 or so, I agreed on each note. Everything has become too
convenient, and coming from
and IT background when you try to make things convenient or
over-simplify software or resources
"like" Google, all you get is crap. So far I think I've only tried to
use Veronica once, and had no luck
finding 1 topic I searched for. But not knowing anything about
Veronica, and how it searches or how
a CSO operates, probably leads me to believe, that as of right now
Veronica is probably > me, and
being that I can Google just about anything (all completely
non-related to what I search for), logic
leads me to believe Veronica > me > Google. I don't know how that is
relevant, but I think
what I'm getting at is the content thing. What little gopher material
that is out there is all probably
more content packed than anything you will find using a website like Google.

!!Gopherness!!
Is something I think I like, where can I get a t-shirt or ball cap. I
don't want to be labeled as one of
those guys that wants to say gopher is better than everything else,
and wants to keep it for myself.
Which some days I am admittedly, but when you remember typing
uploading html 1.0 compliant
websites that you worked hard on all by yourself, now everyone has a
website with absolutely nothing
of any worth or value. Gopherness should remind people of simpler
times when data was fed to you in
text, small, quick, and efficient. If your attention span wasn't long
enough to read a 20 page dissertation
on George Washington's toenails, well then that was your loss. I don't
know if they exist but if I could find
or create a Gopher portal, that I could use to retrieve information I
was looking for, like sports scores I believe
was mentioned, or local weather forecasts, local events, or hell maybe
even a Gopher Conference news board.

Now that we are seeing machines with 4 processors each having 8 cores,
and 16 gigs of ram or whatever, it's
a shame it takes every bit of that to run say a simple web browser
which can easily take up a couple hundred
megs of memory at any given time depending on amount of tabs. I miss
the days of small footprints, streamlined
code, miniature applications, sleek and yet elegant information served
up quickly. Where have those days gone?

I can't take another banner ad, another pop up window, or another
voice-enabled flash advertisement telling I've won
not 1 but 2 free ipod nano's.

Ohh, and hey Cam, what are the details on that Vintage Festival, I
think that would be a blast.

Matthew Holevinski



On Sat, Jul 19, 2008 at 11:32 AM, Cameron Kaiser <spectre@xxxxxxxxxxxx> wrote:
> Nice essay. I'll just intersprinkle my own particular comments:
>
>> - 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.
>
>> - Adding an Endless Array of New Item Types for Every New Thing that
>> Comes Along
>> This is a www disease that has spread to gopher.  Browsers (and their
>> associated plug-ings and "readers") grow exponentially eating up storage
>> space and connectivity bandwidth.  This is because browsers are "smart"
>> clients that access essentially simple servers.  Most of the
>> intelligence is in the ever-bloating client.  Gopher is (or should be)
>> the opposite:  a smart server that contains all the intelligence and a
>> relatively simple client that only moves among menus, displays ASCII
>> text, and downloads files.
>
> We sort of beat this to death in the item types discussion :) but I do
> agree I would prefer a simple client and more work on the server side. Where
> I still think item type expansion is needed is for those things where the
> client might want to do more with a particular resource, or in the case of
> fat clients, but I think I've already said my piece. :)
>
>> - Creating "Wrappers" for Things that Don't Easily Fit the
>> Menu/Text/File Model
>> This is just laziness oftentimes.  If something cannot be rendered to
>> menus or texts simply, it get shoved into a binary file.  MIME is a
>> wasteland of different reditions of often common things, requiring
>> seperate readers for each type.  Most PDF files are predominately text
>> with a few pictures or other such things in them.  A Gopher rendering
>> would be a menu that points to a text (that contains the PDF text) and
>> binary files (that contain pictures and the other things from the PDF
>> file), which allow a person to read the text without dealing with the
>> pictures until the person deems it necessary.  No "reader" needed until
>> you want to deal with pictures, for example. The Gopher server (as the
>> brains of the operation) should convert such binary things into common
>> formats that can be read by the gopher client itself or by a few small,
>> launched "reader" programs.  You can put up the PDF file as a possible
>> download, but don't make it something everyone has to download to figure
>> out if they need it - that is bandwidth waste.
>
> This is a good suggestion and one to consider implementing.
>
>> - 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. :)
>
>> - Clients should be Created for every Computer
>> The whole point of providing information to others is to make it as
>> accessible as possible.  Having to make choices in computers based on
>> the fact that "it runs the web browser I need to use" is a sad state.
>>  If I want to view local sports scores on my old c64, that should be
>   ^^^^^^^^^^^^^^^^^^                    ^^^^^^^^^^^^^
>> possible.
>
> Um ... stay tuned to the Vintage Computer Festival this year. :)
>
>> - Rendering Everything into Either a Menu, an ASCII Text, or a
>> Downloadable File
> [...]
>> - Rendering Everything Else to a Handful of Established Types.
> [...]
>> -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.
>
>> - Use Menu Titles that Stand Alone
>
> Yes, I fully agree with this and try to do so. It also makes Veronica-2 more
> efficient since titles will be more keyword-rich. Right now it uses a bucnh
> of heuristics for keyword-deficient titles.
>
> --
> ------------------------------------ personal: http://www.cameronkaiser.com/ 
> --
>  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@xxxxxxxxxxxx
> -- LOAD"STANDARD DISCLAIMER",8,1 
> ----------------------------------------------
>
>
>