xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/25/91)
[note crossposts, followup] mathews@hadar.cs.Buffalo.EDU (Ryan Mathews) writes: > But I just have to ask one question: > Don't you think we're creating too many groups? No, quite to the contrary, I think we are creating far too few, and our news maintenance and news reading software is poorly set up for the growth which should occur to make up for this. My reasoning is based on weak data, but to the best of my ability to determine, in the last five years, the volume of postings has risen 25-fold, while the number of newsgroups has risen only tenfold. That makes each newsgroup 2.5 times as crowded on average as was the case back when it was still (barely) possible for a single human being to read the entire net as a full time occupation. I attribute this deficiency of organizational improvements to the cumbersome newsgroup creation process. Once having determined that the net needs to get back to a much finer split of newsgroups to give readers any hope of reading interesting material without wading through ten times as much uninteresting material, why should anyone but the current readers of a newsgroup be involved in the partition of that group into subgroups? The rest of the net has only three possible responses when presented with a vote for an unfamiliar group: 1) ignore the vote; 2) vote in ignorance; or 3) vote NO on the "principle", however misguided, that there are "too many newsgroups". What is needed instead is a re-examination of this whole question, and the creation of software and operating paradigms to satisfy the following poorly met needs: 1) Index the net, so that groups of interest can be found by keyword searches; even a full text search of the entire online news spool, while slow as mud, would be a help in this direction. This would actually _lessen_ the need for group creation, by showing the user that topic X is already heavily discussed in newsgroup Y, and so doesn't need a newsgroup of its own to get a discussion going. 2) Index and automate feed sys file maintenance, so that, while all group propagate to those who want to read them, uninterested sites are omitted from carrying, and to the extent possible from passing, unwanted newsgroups. Among other things this will require a much denser set of interconnections for the net than now exist, and software to accomplish the much more complex feed contact protocols and expiry protocols needed. This will save scads of spool space and telecomm charges. 3) Change the news base to a hypertext style, to limit the actual volume used for passing context material in followups. This would save space, and if actually presented by some news readers as hot buttons, would also dramatically decrease reading time for a subscriber following a thread who already has the context in mind and doesn't need to see it again. 4) Present newsgroup choices hierarchically, to let the user view the actual newsgroup organization, and to limit screen painting time for newsgroup selection; change from a typing to a pointing interface. The more I read news, the less satisfied I find myself with _any_ particular order of presentation of newsgroups; I tend to read in different orders on different days or even different hours of the same day. None of the current interfaces I've seen make random access to newsgroups easy. 5) Take much more advantage of user-local processing power; this one is tough because of the wide variety of news reading hardware, but lots of stuff that I have to access over slow dial up lines repeatedly during my session could be downloaded silently to a database on my local hardware while I read other articles, and painted on my screen much faster (about 30 times) from local store. This would actually _decrease_ the communications load on the host machine. 6) Create an easy to use compliment to kill files: interest files, such that only files that meet some positive criterion are presented for reading, rather than negative criteria being avoided. As an example, show me articles containing at least five of twenty keywords, or articles starting new threads. Make a global facility that pulls forward articles from _anywhere_ I subscribe, or even anywhere at all, containing ten of twenty particularly hot keywords, and presents them to me before I enter any newsgroup, in case that is all I have time for right now. 7) Improve the software to cope gracefully with lots more newsgroups, with much deeper hierarchies, with longer, less typable, fully qualified newsgroup names. For example, I just found out that one of the two leaf site packages for my local hardware has a very hard limit of 30 characters in a fully qualified newsgroup name, because it makes that a directory name rather than using a hierarchical directory structure. Unfortunately, my local site already has several newsgroups whose fully qualified name is longer than 30 characters! Naturally typing one of these behemoths in rn or trn to jump directly to the newsgroup is a royal pain. There are lots more ideas along the same direction. The net has become an information overload for any one person, and even individual newsgroups are such for many of us. Lacking better access mechanisms, finer newsgroup partitioning is at least a start. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>