Xref: utzoo alt.bbs:260 comp.misc:4281
Path: utzoo!attcan!telly!evan
From: evan@telly.UUCP (Evan Leibovitch)
Newsgroups: alt.bbs,comp.misc
Subject: Re: New Ideas in BBSes (No BS!)
Keywords: BBS Client Server Network
Message-ID: <430@telly.UUCP>
Date: 3 Dec 88 22:31:49 GMT
References: <1217@cps3xx.UUCP>
Distribution: na
Organization: System telly, Brampton, Ontario
Lines: 200

In article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes:

> The Next Step in Bulletin Board Systems
> ------------------------------------------------

> I really think that most if not all BBS soft that is popular these days
> suffers from a lack of change.

I beg to differ. The evolution of FidoNet, the creation of ever-more-efficient
transfer protocols (Kemit, Ymodem), the emergence of multi-node and multi-user
systems, and the development of ANSI-based graphic displays, all fly in the
face of assertions that BBSs have been resistant to change.

> If you sit back and look at it objectively, 
> most BBSes support the same UserInterface/Options/etc. that the "Conference
> Tree" BBS supported in the late 70's.

> If you look at the rest of our industry, you see incredible change and
> improvements.  But not in the area of BBS communications!  Why?

I have seen experiments in alternative user interfaces. They all died under
real-world use. The good stuff stayed around. Call it the Darwinist theory
of BBSs. :-)

Besides, I think you are missing something important - that user interfaces
are only one (and not even the largest, IMHO) of the facets of a BBS.
Administration tools, security, inter-system communications, and other
features are also important - and they have been improving steadily.

> Well, I believe that it has to do with the fact that most BBS sysops
> feel a necessity to support the "least common denominator" in terms of
> user, (i.e. the user who has only a DUMB terminal).

No, the least common denominator is someone who doesn't know what a dumb
terminal is, and has been shown how to put in a communications disk, turn
on a modem, and dial a number.

> Also a factor is
> the sysop's lack of programming ability.  I have found that most sysops
> are not programmers or designers.  They are mostly regular joes who are
> interested in the "communication" aspect of BBSes.

And not all car drivers are mechanics, but that doesn't explain why cars
don't last longer. I never fail to get irritated by programmers who think
end-users should be programmers. For BBSs or anything else.

Your 'regular joes' crack demonstrates a condescending attitude towards
the poor souls that have to USE the software that programmers create.

The skills necessary to administer a BBS, deal with abusive users, collect
subscription fees, expire old files, keep bulletins current, get rid of virus
programs, recover from power failures, check for libel, etc., are TOTALLY
different from the skills needed to design and code software.

It's arrogant to lay the blame on for 'BBS stagnation' on sysops who choose
to concentrate on spreading information and running a secure maildrop, doing
their best with the software that programmers make available.

The best (and most successful) BBS systems I know of are are not run
by programmers.

> If I were designing a NEW BBS,
> (which I am, actually), I would not include any UL/DL capability except
> as an afterthought.

Another example of programmers pushing their personal philosophies on end
users. I can debate with you on the merits of uploading and downloading,
but my main concern is that you would consciously make your software LESS
useful. You recognize that UL/DL is popular, then go on to say it won't be an
important part of your software because YOU don't think it's useful.

> There are always "online games".  Another boondoggle, I believe.  What
> can an online game on a BBS offer that can really compete with the games
> that are currently avaliable on personal computers?  Multiple players.
> And there again we have a serious "misuse of resources" problem.  WHat
> is stopping your users from using your machine solely for games and
> nothing else? Nothing.

Has it occurred to you that some BBS sysops may WANT it that way?

I agree with you that games are a waste of resources, but I would prefer
BBS software which could reflect the sysop's vision of communications, not 
inflict the programmer's vision.

> Let's play "what-if" for a moment.
> 
> What if:
> 	A BBS could offer windows, icons, menus, popups, multitasking,
> 	online games, interactive communications (chat),
> 	context-sensitive help, and all of this while supporting
> 	multiple users on a machine not much more powerful than a
> 	standard IBM PC?

Now THAT's a shopping list. Let's look at a few:

Multitasking? Multi users? on an 8088? I wish you luck.
You'd be best off not doing it from scratch, but using something like QNX.

Windows; The UNIX 'curses' library allows 'C' programmers to make software
         using TERMINAL-INDEPENDENT pop-up windows. (Remember the lowest
         common denominator?)

Icons;   Forget it. Icons without mice is a useless exersize, and there
         are too many mouseless callers out there to make it standard.

Games;  The least you could do is to provide adequate hooks for the sysop
        to implement this if desired.

Help;   A great idea, but it's largely been done in the other good-quality
        packages.

> 	This BBS could present a User Interface that was tailored to the
> 	individuals own machine.  That would take advantage of graphics,
> 	should the users machine support them.  That would offer
> 	different "paradigms" to different users, while using the best
> 	features of the users own machine?

This would probably be the most significant leap, allowing users to compose
messages with full-screen editors, use arrow keys to make selections, and
use colour when available. Just remember that most terminal emulator programs
of most computers, even the ones with high-quality graphics, cannot take
advantage of bit-mapped images. Those that do, like software that emulates
Tectronic 4014 terminals, draw images painfully slow at 2400bps.

The ability to ask a user what kind of terminal he/she is using, and
determine based on that what codes to use to clear the screen, etc. already
exists on Unix and other multiuser systems. I would argue that the most
serious constraint on BBS systems is DOS (ESPECIALLY if you want multiuser).

> Science Fiction?  No.  I think I have a model that would offer all this
> and more.  There are two "catches".
> 
> One:	It really means that some fancy programming needs to be done.  I
> am currently doing a little of it, and plan on doing more, but would
> like to get a group of people together to help design this.

Perhaps a new GNU project? :-)

> Two:	The user would run special "terminal software" on their own
> machine.

Big problem. It would have to be written totally differently for each system
planning to dial in, to take advantage of all the graphics features you want.
Writing this program, and the GETTING CALLERS TO USE IT, will be a far tougher
chore than writing the host BBS software itself.

It's a bit of a chicken-and-egg situation. If no callers will have it, sysops
won't run the Server software. If no hosts support it, callers won't bother
getting the Client program, regardless of cost.

If you can't get your Client software to support older systems like Fido,
BIX and Compu$erve as well as existing packages like Procomm and Qmodem,
the whole idea of non-standard Client software is dead in the water.

> How is it done?
> --------------------------
> The BBS computer, (known as the SERVER), communicates with the users
> machine, (the CLIENT), through a simple communications protocol that is
> very similiar to Xmodem or Kermit.  Something like the TCP/IP protocol,
> but much smaller.
> 
> The only real difference to the forementioned protocols is the addition
> of a one byte "Channel Number".  Channels are a method of creating
> multiple "virtual" communication channels over a single serial line.
> 

You've REALLY gotta concern yourself whather the benefits from this will
be worth the huge programming headaches you have in store (not to mention
the extra admin headaches ahead for sysops who use this). Computers may
be multitasking, but most users have problems with even a single task at
a time. I myself see no need for 'virtual' channels over a single line.
Especially if you intend to run this on an 8088.

> If the Client supports graphics, we can have multi-user GRAPHICAL games
> where the client saves an "Object Library" locally on his disk.

Are these downloaded, or is the Client expected to have them? If it's
downloaded, than the Server must have multiple copies of all graphics
and icons for each type of supported hardware.

> Well, I have rambled on quite a while now.  If any of this is
> interesting to you, perhaps we could start a mail group to discuss these
> ideas.

Better still, let's keep it here in alt.bbs. The traffic isn't so big as
to require moving this discussion elsewhere.

I am interested in many of these ideas. As you may have noticed, I've
disagreed with some premises and I think some of these 'features' aren't
worth the energy. But that doesn't mean the discussion should lapse. It's
obviously easier to be negative than positive, and I'll try to post some
suggestions of my own in the future. For now, I'm just responding.

> 			Regards, Rob


-- 
Evan Leibovitch, SA of System Telly                   "I am most concerned that
Located in beautiful Brampton, Ontario, Canada          nobody will remember me
evan@telly.on.ca -or- uunet!attcan!telly!evan            when I am dead" - Anon.