Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

AOL Usenet interface: a review

26 views
Skip to first unread message

Ron Newman

unread,
May 14, 1994, 12:24:56 AM5/14/94
to
This is not a humorous article at all, but "best of internet" doesn't
have to mean "funniest". It *is* one of the best-written, most
lucid posts I've seen in months. And it's about America Online,
which has been the subject of much discussion here in a.b.o.i.
It explains how the design of AOL's Usenet software
may have contributed to the problems many people feel AOL have
caused on Usenet recently.

Please do NOT discuss this article in a.b.o.i. Follow it up
in the original newsgroups, which I've placed in the
Followup-To: line.

----------------------
From: e...@titipu.resun.com (Edward Reid)
Newsgroups: news.admin.policy,news.future,alt.culture.usenet
Subject: AOL Usenet interface: a review
Date: Thu, 12 May 94 09:29:16 EDT(-0400)
Organization: Paleolithic Refugia
Message-ID: <0101006...@titipu.resun.com>
Reply-To: e...@titipu.resun.com (Edward Reid)
Lines: 326

I recently checked out the America Online interface to Usenet. These are my
comments on issues that affect the Usenet community as a whole. (Technical
issues only affecting AOL, I'll send directly to them.) As far as I know,
these issues apply to all of AOL, but I've only used it via the Macintosh
interface software. There may be some differences in the DOS or Windows
software, though I doubt the differences are important.

One purpose of presenting this review is the hope that other providers will
learn from AOL's experiences. Prodigy is three times the size of AOL, and I
suspect its culture is likely to cause more clashes in Usenet than we have
observed from AOL's culture.

Summary:

1) In general, the interface is straightforward and easy to use.

2) A small number of serious problems, and a larger number of minor
problems, are probably causing much of the disruption that has been
attributed to AOL users.

3) The inability to read and write articles offline is, to me, crippling.
I will not recommend AOL to anyone for Usenet access until this
situation is rectified.

What AOL has done right
-----------------------

It's only fair to start by pointing out that AOL has done a lot that's right.
At least on the Mac, it's a decent GUI interface. You can select newsgroups
from a hierarchical list and subscribe, or type the newsgroup name directly.
Double-click a newsgroup to open it and see a list of threads. Page through
the list using standard methods (page keys or scroll bar). Double-click a
thread to open the first article. Use on-screen buttons for basic operations
such as followup or read next article. Choose the font for display, and
resize and reshape the window after it opens -- no 24x80 pinholes here. Move
through the article with the scroll bar. No cryptic one-letter keyboard
commands. In short, navigation is very simple and is handled so as to make it
natural and easy in the AOL environment, and it's light years easier to learn
than even the best of the Unix newsreaders.

When you enter the "newsgroups area" you are presented with a list of
introductory documents and encouraged to read them. Some of these are the
standard Usenet new user articles, or minor modifications oriented to the AOL
environment. The standard netiquette guide is there, slightly altered to tie
in to AOL, under the title of IMPORTANT PLEASE READ. Others are even more
basic discussions of Usenet -- for example, "About Newsgroups".

The default subscription list includes news.announce.newusers, news.answers,
and news.newusers.questions. It also includes several local newsgroups (an
aol.* hierarchy) for questions, problems, support, test messages, etc.

And rather by coincidence, AOL has recently upgraded its interface to 9600
bps, so even reading long articles is quick. Articles are downloaded to the
user's PC or Mac when the article is opened, so paging through the article is
as fast as the local video once the download is finished -- yet you can start
paging as soon as the download has grabbed the next page. You can cancel the
download if you don't want the entire article (on the Mac, by using the
standard cmd-period).

This isn't to say everything mentioned above is hunky-dory. I could add many
caveats, especially the overly busy UI, but my point was to show that AOL has
done some things right.

In what follows, I've identified major issues as those which directly affect
the users' behavior in ways that are detrimental to the Usenet as a whole.
Minor issues make life more difficult for the users, but only affect the rest
of Usenet in that any user whose interface is poor will not be able to
participate optimally. It is worth noting that many AOL customers have
extensive experience with Usenet and are making these same concerns known to
AOL as customers.

Major issue: no offline news reader / writer
--------------------------------------------

An AOL user can save individual articles to local disk -- but only after
opening the article and waiting for the text to be sent completely. And then
each article gets saved in a separate file. The user can also create text
offline and paste it into a new article window. Obviously this does not
qualify as an offline newsreader. The result is that AOL customers, after
they use up their five hours per month that are included in the monthly fee,
are paying $3.50/hour to read and write news -- and to think about what they
write. The latter, I believe, has a profound effect on the way AOL users
interact with the net. They are paying for their think time, so they skimp on
think time. Followups from AOL users tend to be blunt rather than thoughtful.
I blame AOL, not its customers, for this.

AOL did not get into this situation naively. They have provided offline email
reading and writing for quite some time, and even provide automatic scheduled
retrieval and transmission of email. They could not possibly have missed the
fact that the same facility would be even more important for Usenet. I am
tempted to claim that they are trying to keep their customers online for as
long as possible (at $3.50/hour), but I'm reminded of Occam's Razor:
specifically that I should never ascribe to greed what can be explained by
incompetence.

This problem has not been lost on AOL customers, who are complaining
vociferously on the internal AOL newsgroups. (Yes, there is an aol.*
hierarchy accessible as newsgroups, not as AOL forums.) AOL technicians are
sympathetic, but management refuses to respond, so AOL's plans in the area
are unknown.

Major issue: no shortcut for email reply
----------------------------------------

When AOL displays the text of an article, it puts a "send response" button at
the bottom of the window. Sounds like a "reply", right? Wrong. "Send
response" posts a followup! The only way to send a reply (that is, by email)
is to "compose mail" and create an entirely new message. Furthermore, most of
the AOL documentation confuses followups and replies. It's almost as though
AOL were encouraging its customers to post rather than emailing, perhaps to
give AOL greater visibility. But remind me of Occam's Razor again. And surely
the AOL management would realize what a bad reputation AOL would get from
customers posting messages that should be emailed, wouldn't they? Wouldn't
they?

In information provided for AOL customers, the AOL support people refer to
"posting". But there is also frequent reference to "messages" to mean
articles. Users are likely to pick up the Usenet terminology of "articles"
and assume that "messages" are different, which they aren't. AOL never
explains the difference between posting and emailing, and they never explain
that their own software presents a conflicting terminology to the user. I'd
say it's no wonder that there are so many postings from AOL users which
should be in email. The software invites it.

A recent required-reading message of the day tries to emphasize the point that
email should be used. Unfortunately, the message says "send mail to the
author -instead of- following-up to the newsgroup". This only further
confuses the issue, since it fails to point out that the "send response"
button does the wrong thing.

Many AOL customers have noticed this problem and have complained.

Major issue: No quoting capability
----------------------------------

When you click "send response" (meaning follow up; see above) the software
pops up a new window with the obvious fields. In the body text field, it
inserts the text (for example)

In article <Cn180...@news.waydn.ac.nz>, smb...@waydn.ac.nz (Some
Bloke) writes:

OK, so far so good. But then nothing. No quoted text. And, no explanation of
why those first two lines are there. It's obvious that many AOL users assume
that this text is thrown in because it's required, and they go on to type
their response. Which is confusing, because we all expect to see original
text after the "so-and-so writes:" blurb. But who can blame the AOL users?
They are only doing exactly what the software has indicated to them that they
should do. They are trying to follow the conventions as shown to them.

Well, after a while some of the AOL users figured out what was going on. (Some
already had Usenet experience and realized immediately.) So to imitate a
quote, they cut and paste what they want from the original article into the
response window. But there's no way to add a prefix when they do so. As a
result, we see unprefixed quoted text in AOL followups, which confuses us
since we can't tell when the quote ends and the response begins. And a few
AOL users have actually put in prefix characters. Give them a big hand --
because they did that formatting *manually*, as far as I can tell.

David O'Donnell (AOL System Administrator, aka PDMAtropos) has explained that
they are working on providing a quote capability but want to do it without
encouraging overquoting. I applaud this goal. But they were negligent in
releasing the software in its current state: if it's not going to provide a
quote, it shouldn't put in the text that says it is. And if this state is
really essential as a partial implementation (which I find hard to believe),
it should at least explain loudly and clearly to the user why it is doing
what it's doing. This is not happening.

And it is not as though there isn't a good paradigm available to follow. I'm
using uAccess, which I hear has been renamed UUCP/Connect, to write this
article. In uAccess, if you select text in the original article (by dragging
the mouse) before selecting the followup function, that text is quoted.
Simple, and it doesn't encourage overquoting.

Some AOL customers have noticed this problem and have complained.

Minor issue: expiring news slowly and not respecting Supersedes
---------------------------------------------------------------

AOL apparently has an expiration time of about 65 days. misc.health.diabetes
has over two months of articles in it. misc.kids has over 10,000 articles.
This plethora of old articles is likely to be confusing to new users. It also
takes a long time to download the article list at 2400 bps, which I had to do
the first time I tried because the local 9600 bps phone number wasn't
working. This will be quite discouraging to users who aren't prepared to
upgrade their modems immediately. You don't have to wait for the entire list
to arrive ... but the oldest items are listed first. The ones that are two
months old.

In addition, AOL is not respecting the Supersedes header. As a result,
multiple copies of most FAQs are being stored and presented to users as
separate articles.

Some AOL customers have noticed. The most common response seems to be to
request that articles be listed in reverse order. Other improvements in
selection flexibility are often requested.

Minor issue: threading is weak -- poor subject matching, no references
----------------------------------------------------------------------

The AOL software apparently truncates subject lines at about 50 characters.
This is fine for display. But it also uses the subjects for threading
(ignoring the References header entirely), and does this threading with the
truncated subjects. As a result, if the original subject was 47 characters or
more, it doesn't match the subject of a followup which is additionally
truncated due to prepending Re:, and the thread is split in two. It also
splits garbage like 2Re: and Re(2):, where a good threader would recognize
them as part of the thread.

Ignoring References also results failure to treat multi-part FAQs as a single
thread.

Minor issue: no search capability
---------------------------------

There's no way to search for and select articles by any criterion, even a
simple string search. Article management tools are nonexistent. While the
complexity of something like TIN would be questionable in the AOL
environment, uAccess provides tools which are much simpler than TIN's yet
much more powerful than AOL's. Of course, the latter isn't saying much.

Minor issue: default subscriptions to extremely active newsgroups
-----------------------------------------------------------------

By default, AOL subscribes you to comp.sys.mac.misc, misc.kids, some Windows
group that I forgot, rec.pets, rec.travel, and soc.women, along with the
aforementioned news.announce.newusers, news.newusers.questions, news.answers,
and aol.* groups. Now I certainly agree that this is a rather representative
sample, and also that it's a good idea to show the new user a few newsgroups
to arouse some interest. But these are some of the busiest and noisiest
newsgroups on the Usenet. Do the participants in these groups appreciate that
fact that AOL is subscribing every user who looks at newsgroups to those
particular newsgroups? Do they even know? Have they noticed a drastic
increase in noisy new-user traffic since AOL began offering the interface?

As I say, I think it's a good idea to try to show the new user a few
newsgroups of possible interest. But this needs to be accomplished in such a
way that a few newsgroups don't get the brunt of all the new users. I can
propose several possibilities, and I'm sure the people at AOL can too if they
stop and think about it.

Minor issue: cannot read articles longer than 25K
-------------------------------------------------

The Windows software crashes when an article longer than 32K is opened, and
the Mac software truncates the beginning of articles longer than about 25K.
Of course, this means that most FAQs cannot be read, so this has a rather
significant impact on the rest of Usenet.

AOL cannot claim that this snuck up on them. They've had the same problem with
email for a long time. They "solved" the email problem by splitting long
incoming email into multiple messages! Yet they allowed the same problem to
creep into the Usenet interface as a flat-out bug.

AOL customers are complaining vociferously, especially the Windows users.

Minor issue: automatic sigs
---------------------------

AOL doesn't have automatic sigs, at least not for news. They say they plan to
add this feature. I'm not sure whether the issue is no sigs or that they plan
sigs. Frankly, I'm not impressed with how sigs are used in general -- lots of
ASCII pictures taking up space on my disk, lots of jokes that are funny the
first time and stale the third through two hundredth times, lots of
philosophies of life summarized in single lines. Will an AOL feature just
make this worse?

Minor issue: "newsgroups feature" or Usenet?
--------------------------------------------

AOL frequently refers to Usenet as "the Newsgroups feature". Now, in some
places AOL makes it very clear that Newsgroups come from outside AOL. But
this reminder isn't maintained after the user passes the gateway and starts
reading and posting. As a result, it would be very easy for an AOL user --
even one who reads some of the news.newuser posts but doesn't fully
comprehend the context -- to think that Newsgroups is something started by
AOL that others are hooking into. It seems possible that some attitude
problems may result from this skew.

Minor issue: cannot handle long article lists
---------------------------------------------

The local software cannot handle very long article lists. (Definitely true
for the Mac interface, and I'd bet dollars to doughnuts it's true for the
Windows interface too.) In particular, news.answers cannot be read because
the article list is too long! We *want* new users to read news.answers!

Minor issue: description used in place of name
----------------------------------------------

The description from the list of active newsgroups is sometimes shown instead
of the actual newsgroup name. While it's good to make this description
available, using it in place of the name can be misleading. The descriptions
were obviously not written to stand alone without the names themselves, and
in the past no one has cared if the one-line descriptions were completely
accurate. But when an AOL user opens a newsgroup, the window listing the
thread subjects is titled with the description instead of the name, so the
AOL user constantly sees the description. (The real name is used in the
listing of newsgroups.) A particularly egregious example of a case where this
is inappropriate is

comp.sys.amiga.datacomm Methods of getting bytes in and out.

where the description does not even mention the platform dependence. A more
subtle case is

misc.health.diabetes Discussion of diabetes management in day to day life.

where "day to day life" is too restrictive. That could alter the tenor of
expected discussions, for example excluding current research, a common topic
in that newsgroup.

Finally, a sign of culture clash
--------------------------------

On some of the internal newsgroups, I noticed a lot of followup postings
saying "me too" (yes, literally) and "I vote for that". I haven't noticed
such behavior on external newsgroups, so perhaps AOL users know the
difference and adjust their behavior. Still, the idea that "me too" posts are
accepted in AOL discussions concerns me in light of the continual efforts
that are required in many newsgroups to keep the signal/noise ratio
acceptable.

--
Edward Reid e...@titipu.resun.com (normal)
PO Box 378 Edwar...@acm.org (forwarding)
Greensboro FL re...@freenet.fsu.edu (seldom checked)
--
Ron Newman MIT Media Laboratory
rne...@media.mit.edu

0 new messages