![[Ad box removed; this image serves to flag pages that need to be updated in my log file.]](/i/boxremoved.png)
Here are just a few of the more obvious reasons that Web BBSes, often called "forums," suck. Of course, not all these points apply to all Web BBSes, but each one applies to enough Web BBSes to be a problem. The general pattern is Murphy's law: anywhere there is more than one way something could be done, Web BBSes do it the wrong way.
An entire generation now believes that the word "forum" means "Web BBS," leaving us with no convenient way to denote its actual meaning.
The same generation thinks that "forums" is the correct plural of "forum."
Web BBSes can only be read while connected to the Net - a problem that real BBSes solved in the early 1990s and Usenet solved much earlier.
Web BBSes can only be read with one interface, the one provided by the BBS software, unlike news, mail, and some real BBSes, which can be read with a client of the user's choice.
Oh, the previous point isn't true, because "forums" are "skinnable." Ha, ha.
Forget it if you have any kind of disability that causes you to require UI accessibility features.
Every organization, Web comic, or similar, has its own separate Web BBS for which you'll have to create and maintain a separate account, and separately visit another Web site on a regular basis.
Because the previous point results in so much inconvenience, organization members who should read an organization's Web BBS, won't bother to do so. That becomes a vicious circle where members don't bother reading the BBS because there are never any new postings, and there are never any new postings because members don't visit the BBS.
The Web BBS associated with a Web site or organization that also requires accounts and memberships for other reasons, will normally have a completely separate account system from the one used by the main Web site or organization, because the BBS software is an independent third-party package, not part of whatever other software is in use. Have fun keeping the two in sync.
Because the Web is World-Wide, a large proportion of participants on a Web BBS with a geographically specific purpose, will not actually be in the relevant locale. Unless, of course, the sysops lock it down heavily to keep out such people, in which case there just won't BE any participants.
Many Web BBSes that shouldn't be, are configured to require a membership to post or even to read. The converse is seldom true; sysops generally err on the side of too much restriction rather than too little.
The software provides a "private message" facility which duplicates the functionality of email, badly.
You can set up your account so that you'll get an email to let you know when someone has sent you a private message... but not to actually send you the private message. Ha ha, you're supposed to be logging into the Web site regularly, you silly n00b!
You can set up your account so that you'll get an email to let you know when someone has replied to a posting you made... but not to actually send you the reply. Ha ha, you're supposed to be logging into the Web site regularly, you silly n00b!
You can set up your account so that the only way to contact you is through the "private message" system. As a result, some people do. Thus, everyone ends up being forced to use the "private message" system whether they want to or not. The software could, but doesn't, provide email forwarding for everyone and/or email addresses that forward into the private message system, to allow email communication while addressing the supposed need for anonymity of email addresses.
You cannot set up your account to require people to contact you via email.
The software requires you to enter an email address - often rejecting valid email addresses that contain the plus character - for "verification," even though in all other respects it is designed to discourage the use of email. You're supposed to log onto the Web site regularly, you silly n00b.
The need for anonymity of email addresses is seldom genuine, and is better addressed by other technology.
Web BBSes where a need for anonymity can be well justified (for instance, the paedophile BBSes, of which there are disturbingly many) nonetheless maintain unencrypted subpoena-vulnerable user databases full of personal information, and take no measures against Web bugs or many other serious threats to anonymity.
The previous point isn't true, because the edgier Web BBSes protect privacy with a membership requirement and terms of service saying that the police are forbidden from logging on. Ha, ha. In fairness, real BBSes used to do much the same thing, with an equal measure of success.
No easy way to locally archive, filter, or search your messages, as would be trivial with news or email.
On the other hand, Google will index most Web BBS discussions, so as to pollute (sometimes beyond usability) the search results returned to anybody who has the misfortune to be searching for a topic that has ever in history been discussed on a Web BBS anywhere in the world. A Web BBS discussion may occasionally contain relevant information, but that's the exception rather than the rule. In fairness, mailing lists have the same problem, if to a smaller degree.
There are many kinds of Web BBS software, probably including some that address some of my software-related complaints. But everyone uses phpBB. Guess what happens when there's a security flaw found in phpBB.
Rules that can be enforced by the software bear little resemblance to the rules sysops would actually like to enforce. As a result, many user activities that ought to be impossible are instead "possible, but forbidden," and there's a lot of unnecessary work created for sysops in manually enforcing rules, along with opportunities for discriminatory selective enforcement.
No facility for providing static or nearly-static informational text for new users or for reference by established users. As a result, local rules, how-to guides, FAQs, and similar all end up being "stickies," and (true to their name) collecting a lot of cruft of useless replies. Revisions to "stickies" will occasionally be posted as replies in those threads, so you really do have to read them all the way to the end and continue reading new replies in the future, even though they're more than 90% useless cruft. The software may provide features so that only sysops can post in the "sticky" threads, to keep them on topic, but if so, those features will certainly never be used.
Actually, it's easy (because this all happens on a Web server) to post static or nearly-static informational text - such things could be posted as Web pages - but in actual practice, sysops think that "stickies" are the right way to do it.
There is a file called the FAQ, but it's actually the generic instructions for how to use phpBB, which your local sysop was supposed to, but did not, customize for this particular Web BBS by deleting irrelevant sections and adding local information. It will certainly consist primarily of material that is not applicable to this particular Web BBS, with no indication as to which sections actually do or don't apply. The real FAQ is in one or more "stickies," which you're supposed to read, you silly n00b.
User login process defaults to enforcing a toothless attempt at compliance with the USA's asinine "child protection" laws, never mind that your installation is not located in the USA and the CYA language in the user agreement probably wouldn't actually protect anybody should there be a legal dispute even if US law did apply.
On some Web BBSes, it is forbidden to "necropost" to topics that haven't received any replies in a while; if you want to comment on a topic that was discussed before, you're supposed to start a new thread. On other Web BBSes, it is *required* to post to an existing thread if one was ever created that even vaguely resembled what you want to talk about, and you'll be punished if you start a new thread. There is no good reason for either rule, no software enforcement of either rule, and no way to predict which rule a given Web BBS will follow. Ha ha, you're supposed to read the "stickies," you silly n00b.
Once a thread is no longer in the top twenty or so most-recently-posted-to threads, it will no longer appear on the front page. When that happens, the thread might as well never have existed. This point is especially problematic on systems that prohibit creation of new threads for previously-discussed topics.
Corollary: if you want to kill a thread, just make sure that twenty new threads are created. The old thread will never get another reply.
No, you can't view threads in any order other than "reverse chronological of last posting in thread," you silly n00b.
No, you can't view postings except grouped by thread, you silly n00b.
Well, okay, you can try to view individual postings with the search feature, sort of, but it still won't actually work.
Editing an already-posted message may or may not be allowed depending on local settings. On any given site, it will be allowed or not more or less at random.
Thread locking. What is up with that? I can think of very few situations where it would actually be the Right Thing. "Stickies" might be one, but it's seldom if ever applied to those. (I'm not sure the software even allows a thread to be both "locked" and "sticky.") Instead, thread locking is the enforcement action of first resort when a sysop doesn't like the topic of a thread, with the great benefits that the undesirable thread remains visible, it's marked as special in the UI so as to draw even more attention, and the participants are free to go discuss whatever they were discussing in a new thread or some other existing thread. Given its limitations, it's surprising that thread locking is actually somewhat effective - maybe because pretty much the only other enforcement action routinely used is to ban users entirely, so users take a thread-lock as a stern warning.
Sysop interventions, like moving, deleting, or locking threads, are generally applied to threads when they would more sensibly be applied to individual messages. I'm not sure whether that's a limitation of the software or the way sysops typically use it.
The UI displays who started each thread in a way that makes that look like important information, even though it is seldom relevant to anything.
The UI displays how many users are "currently logged in," and sometimes their names, in a way that makes it look like important information, even though it has essentially no meaning in the sessionless Web environment, is of no consequence, and has to be faked via timeouts.
It also prominently displays the all-time record number of users "currently logged in," and the time when that occurred, as if it meant something.
"User levels," attached to every message and determined by number of messages posted, give users a strong incentive to post as many messages as possible, whether that's actually desirable or not.
The system allows, and even encourages, graphical content in postings, which real BBSes, and email and news users, figured out was a bad idea many years ago.
Because of allowing graphical content in postings, there is a structural incentive for the antisocial practice of embedding third-party images without credit or permission, also known as "hotlinking" or "bandwidth theft."
Antisocial embedding is especially common because sysops and software packages could, but don't because of a penny-wise, pound-foolish view of storage space and bandwidth, provide any facility for hosting images - so users who don't own Web space of their own are pretty much *required* to embed from third parties.
The software could, but does not, include features and enable them by default to prevent antisocial image embedding.
Some sysops make rules against antisocial image embedding, but they have to enforce them manually. Others should and don't.
Image embedding makes it easy for people to post Web bugs and shock-site images, and the software does nothing to prevent either form of abuse.
With third-party embedding, a user can even post a shock-site image unintentionally, when the owner of the image server considers the embedding hostile and retaliates by changing the image.
Some software packages even permit posting embedded Flash; sysops can make rules against it, but the software doesn't help enforce them.
Sysops make rules about the maximum size of images that may be posted; the software could, but does not, include features to enforce those rules, so they all have to be enforced manually.
In order to facilitate graphical content in messages, the software defines its own proprietary, incompatible, and inferior substitute for perfectly good HTML, called "BBcode."
The small number of non-phpBB systems each have their own unique proprietary, incompatible, and inferior substitutes for marginally acceptable BBcode.
Heaven help you if you want to use the mysterious technique of advanced English composition known as "punctuation," because parts of your message will be randomly replaced by cute animated "smilies." Ha ha, you should have used "preview," you silly n00b. Ha ha, this is one of the systems where you're not allowed to edit messages once posted, you silly n00b.
The "smiley" codes are different on every Web BBS, even for systems using the same software, because they are locally customizable. They are the only part of the installation that your local sysop has actually customized.
You local sysop also made a rule requiring correct punctuation and spelling, but it isn't enforced. Ha ha, you shouldn't have believed the "stickies," you silly n00b!
BBcode provides a quoting facility that looks very nice when used correctly. However, because it requires a separate [quote]...[/quote] pair for each quotation (requiring extra work to split the quotes into multiple blocks), and the UI "quote" button pastes in a quote of the entire previous message (which is easy NOT to edit), excessive quoting is the rule on systems where users are smart enough to quote at all. It's especially annoying when the quote contains a large image repeated in several levels of nested replies.
The previous complaint, and many others, can be blamed on user error - but that's no excuse, because the software is designed in such a way that using it incorrectly is the easiest thing to do. It could and should be designed so that using it properly is easier than using it wrong.
For such heavily thread-oriented systems, you'd think Web BBSes would do real tree threading like a newsreader or Web log comment system, showing which messages are replies to which; but no, within a thread, the only available view is flat forward chronological without regard to the reply tree. Ha ha, you're supposed to read it all, you silly n00b!
HTML design that makes horizontal scrolling necessary.
Spam robots.
Poorly-thought-out attempts to block spam robots.
As of January 2007, this page is one of the highest-traffic on my site, and examination of the logs shows that almost all the traffic consists of HTTP POST requests to the comment form. 99% of those requests do not actually result in comments being posted... and it turns out that's because they are due to spam robots filling in every field of the form with HTML advertising. My code correctly recognizes that as spam and throws it out, but the traffic just from the failed attempts is enough to be a problem. My best guess as to why they're targeting this one page much more than others, is that maybe it's because the letters "bbs" are included in the URL. That seems like another reason Web BBSes suck; they've created an environment where I end up under DoS attack just because I created a file of that name.
I don't want to change the name of this page because that's letting the spammers win, and it would make trouble for the links that others have posted to this page from other sites. However, I'm moving the comment form to a more congenial place to see if that will reduce my failed-spam load. Go there if you want to comment on this page.
![[RSS syndication file]](/i/rss.png){kind=small}