Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site nsc.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!nsc!chuqui
From: chuqui@nsc.UUCP (Chuq Von Rospach)
Newsgroups: net.news,net.news.notes
Subject: Re: Information Overload and What We Can Do About It
Message-ID: <3274@nsc.UUCP>
Date: Tue, 17-Sep-85 16:24:57 EDT
Article-I.D.: nsc.3274
Posted: Tue Sep 17 16:24:57 1985
Date-Received: Thu, 19-Sep-85 05:32:23 EDT
References: <10381@ucbvax.ARPA>
Reply-To: chuqui@nsc.UUCP (Chuq Von Rospach)
Organization: Uncle Chuqui's Lemming Farm
Lines: 92
Xref: watmath net.news:3948 net.news.notes:8

In general, Erik is right on the mark. He and I seem to be coming to more
or less parallel conclusions about the same problems, as I've been working
for about the last two months (on and off) on something I'm calling NNTN
(Not Neccessarily The Net). It matches Erik's thoughts to a high degree, so
rather than bore you with lots of verbiage (for once) I'll just make a few
quick comments. 

In article <10381@ucbvax.ARPA> fair@ucbvax.ARPA (Erik E. Fair) writes:

>1) I can arrange to read netnews at a higher baud rate
>	(instead of 1200 baud, how about 9600 or 19200?).

I've actually found that reading at 1200 baud is better, faster, and/or
more efficient for me (with rn) because I get more bloodthirsty about
zapping stuff.

>	I N F O R M A T I O N   S T R U C T U R E

>Right now (with the exception of rn & notes) netnews articles are
>presented to the user in the order they arrived on the system. This is
>not optimal. To create structure in the way that netnews articles are
>presented, we can start (as rn does) with the Subject line, and follow
>that along, presenting articles whose subjects match. This gives us the
>thread of a discussion.

This isn't quite accurate. rn shows articles sorted by newsgroup preference
sorted by subject line sorted by arrival, and other news programs show
articles sorted by newsgroup by arrival.

>		F I L T E R I N G   M E C H A N I S M S 

>Consider the following information that might be useful
>to filter by:
>
>author		(also known as the `bozo' filter)
>site		(they're all bozos on that bus)
>date		(kill articles that are four days old)
>time		(kill articles composed between 0000 and 0600?)
>transit-time	(kill articles that took more than x days to get here)
>length		(anything too small or too big)
>newsgroups	(in a multiple group posting,
>		  skip if `net.flame' is one of the other groups)
>keywords	(suppose that postnews mungs up a set of keywords
>		  from the body of the article when it was first posted...)

One of the things that looks very attractive to me right now is
disassociating the concept of a 'newsgroup' from the user interface
completely. The ONLY thing the user should see is the subject line. Right
now all news programs do their primary key using the newsgroup when the
primary piece of information of interest is the subject. I suggest trashing
the concept of a 'newsgroup' completely, and switching to having a set of
distributions (world, continent, country, region, state, city, and site,
and let the program worry about the details of that they are), a set of
'required keywords' [known system-wide, at least one required per message]
and a set of 'optional keywords' chosen by the user. 

One thing you can then do is define a default distribution to a required
keyword as well. net.flame could translate into {region,flame} and
net.unix-wizards would translate into {world,unix|expert} or some such.
Newsgroups can then be mapped into the required keyword set, and the
filtering mechanism will do that part of the work for you. You no longer
have to worry about seeing the same 'M'arked message popping up in both
net.news and net.news.adm because you don't see the groups anymore, you
just deal with the messages.

>		W H A T   D O   W E   D O   N O W ?
>Clearly this is a database function
>that should go into rnews and expire for update & maintainance, rather
>than in the user-interfaces.

One other thing that ought to be considered is moving the filtering
mechanism out of the user interface. One of the important design elements
of NNTN is that there is now a NNTN_reader and an NNTN_daemon for a user --
the daemon spawned when you log on. There is not only a system database,
but there is a user database as well. The daemon deals with the system
database, updates the user database and does 'biffing' as requested, and
the reader program reads. This gets rid of the irritating waits when rn
needs to rebuild the .newsrc stuff, uses group or glocal kill files, or the
'k'ill key, since it is all done background.

The other things I've found about the user interface is that there is no
reason why news and mail ought to have separate programs/interfaces.
Whether the message is news or mail should be part of the
filtering/priotizing setup, but is irrelevant to 99.44% of the user
interface. A new filtering bit would be whether it is public or private
based, but whatever interface deals with news should deal with email as
well.

-- 
Chuq Von Rospach nsc!chuqui@decwrl.ARPA {decwrl,hplabs,ihnp4}!nsc!chuqui

Take time to stop and count the ewoks...


Brought to you by Super Global Mega Corp .com