Xref: utzoo comp.misc:4312 alt.bbs:277 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!gatech!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.misc,alt.bbs Subject: Re: New Ideas in BBSes (No BS!) Summary: Some more on this issue; client-server models and user interfaces. Keywords: BBS Client Server Network Message-ID: <2383@ddsw1.MCS.COM> Date: 7 Dec 88 21:04:03 GMT References: <1217@cps3xx.UUCP> <430@telly.UUCP> Reply-To: karl@ddsw1.MCS.COM(Karl Denninger) Distribution: na Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 251 In article <430@telly.UUCP> evan@telly.UUCP (Evan Leibovitch) writes: >In article <1217@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > >> 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. :-) This I have to agree with 100%. We've tried several different things; people come back to what they know and like. The cutesy interfaces and whiz-bang graphics terminal setups have been tried already; they DIED from a lack of users. Why? Because they were artificially limiting their audience. (There are a few notable exceptions; Quantum Link is one example... but they ALL cater only to one type of machine and/or software) >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. EXACTLY. A few years ago I had an interlinked system running on Model III machines (Tandy). This before Fidonet had even "bow wow'd" it's first bark. It was a horrible kludge, but darn it, it moved mail and bbs files back and forth across the country for quite some time. One set of sites in Texas is STILL using the email part of it in a network of about a dozen systems -- on Tandy Model IVs. We've learned a whole heck of a lot since then; our current offering's security, easy of administration and flexibility massivly outclass the old ERACS systems -- but then again, we're not on a 64K Z80 based system anymore either! >> 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. Or the person who has a real terminal -- as in a mainframe user who can dial out, but does NOT have ANY... ANY.... ANY... WAY to get local intelligence. DUMB terminals (as in "glass tty") are all but gone; we can safely ignore these.... Or can we? Ignoring glass ttys, my friends, means ignoring more than half the Commodore owners -- or about 60% of the PC's out in the PERSONAL computer world today! What was it you said about PC's being only $400? With a modem, and DOS, and.... yeah, keep dreaming. A minimal PC needs help -- enough memory to work (ie: 256K), floppy and modem, display, monitor, keyboard.... getting the idea yet? You're looking at a $500-600 machine; more if you don't go with a "no-name clone"! Heck, a C64 + disk + modem can be had for $200-300! Which one can Mr. Auto Worker afford more easily, and which of the two do his KIDS want? Not the IBM with monochrome screen! >> 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. Yep; it's our position that anyone who can turn on the power, log in as root, and read a manual should be able to handle running the system. If you can't do all that you call us -- after 10 minutes you can indeed! (assuming you can read, of course :-) If that doesn't work, WE SCREWED UP (or any other BBS system author/publisher). >The best (and most successful) BBS systems I know of are are not run >by programmers. I'd debate that (and I'm very biased) ;-) >> 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. Agreed; why should you force anyone in either direction? The best solution is to provide a smoothly-integrated and carefully designed method for having it either way -- you can have downloads, or you can do without them; the administrator gets to choose. There are a lot of sites that don't want d/l capability that are using AKCS -- they simply don't enable the option. But for the sysadmin who DOES want to have the areas available, the capability is there, built in, and not a "hacked in" afterthought that will cause a lot of grief. >> 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. Boondoggle? Waste of resources? I'm sorry, but I have to disagree here. We have a very nice multiplayer space game; it's not terribly piggish with machine resources, it works, and it's a ton of fun -- better than simply taking on a computer ANY DAY; there's a human element involved. I'd never run software that prevented me from making a choice to offer such a game on the system -- that's way too restrictive! In fact, I need capability to interface (or at least "gate" to) ANYTHING. On a Unix machine, it's perfectly reasonable for a person to execute commands within a restricted environment. >> 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. Yes, or making the "minimum platform" an AT and run Microport or SCO... >Windows; The UNIX 'curses' library allows 'C' programmers to make software > using TERMINAL-INDEPENDENT pop-up windows. (Remember the lowest > common denominator?) This is the way to go if you must have windows. I'd hope you'll stay reasonable; believe me, there is nothing that slows down a perfectly good application faster than trying to run in a windowed environment; ask anyone who is _skilled_. The first-timers ooh and aaawww over it; when it comes down to brass tacks, the cutesy stuff LOSES. Why? Almost without exception: the time savings for new users are minimal, while the time LOST for the experienced user is not trivial or necessary. >Icons; Forget it. Icons without mice is a useless exersize, and there > are too many mouseless callers out there to make it standard. Agreed (once again, C=64, VT100 terminal, any mainframe user). >Games; The least you could do is to provide adequate hooks for the sysop > to implement this if desired. Absolutely a requirement. >Help; A great idea, but it's largely been done in the other good-quality > packages. Also absolutely a requirement, and it has to be definable by the sysadmin. >> 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. Painfully slow is being too nice :-) >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). You bet. We thought long and hard about this before deciding to go with Unix rather than DOS as a base for AKCS; DOS was just too restrictive in what it would support, and offered nothing but more work for us in implementing what we wanted to do. >> 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. You've also gotta figure on another problem. Disregarding those who just CANT run the client (and that is a LOT of people, folks!) leaves you with lots of systems to support -- at a minimum you need Amiga, Atari, C=64, and IBM (DOS & OS/2, 2 versions!). Oops -- you just excluded all the 3b1/7300's, all the Tandy gear (there's a LOT of it!), all the SCO Xenix machines, and all the....... Getting the idea yet? This is going to be one HELL of a lot of work, yet without the client software no one will use the thing! >> 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. Yep; and those files are HUGE!!!! Ever look at the size of an HP font file? Or a bit-mapped screen image (or any significant piece of it?) 5-10k comes to mind as a reasonable number for some icons... how long did you say you were willing to wait for that transfer of the 300 D&D monster icons for that neato game? The only scheme that I see as being practical at all is very, very simple server with a highly-complex client piece for each system. This also allows you to build a "text only" interface that can run locally (given Unix as a base system). This comes with it's own set of problems -- now you've got security headaches up the wazoo to deal with as well! -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"