Printout from http://www.systasis.com on Saturday, 18 January 2025
Copyright: 2003-2025 Symeon Charalabides. All rights reserved.

Information presentation: Systasis comments, part 1
by Symeon Charalabides (symeon@systasis.com) on Tuesday, 18 February 2003

Every web-publisher wants to create a community because every web user likes to participate in one. It's as simple as that, really. In Systasis, we welcome article submissions by anyone, but were more concerned with creating a clear and concise commenting system. These are also commonly known as forums.

Two kinds of forums tend to prevail on the internet.

First and foremost, the "table" forums, such as the one on SitePoint. They vary from plain text to entirely graphical. They tend to offer every single functionality a user could possibly wish for and do, eventually, "suck you in", when the topic is of particular interest. However, due to their complexity, they can be a nightmare to maintain and also tend to scare away new users who don't want to have to read pages of manuals just to be able to say "I agree. Hum.". Also, under the start of every topic, the replies are presented linearly, lacking an element that readily (see "visually") ties them to the specific posting they refer to.

On the other hand are forums offering "threaded discussions", like this one regarding abstract art. Although their usage dropped considerably as bandwidth became cheaper and browsers faster (well, some of them anyway...), they score over the previous kind on the issue of posting lineage: it is reasonably easy to trace any posting back to its originator while identifying all the interceding ones on the way. This advantage, however, is lost when actually reading a posting on its own page. These forums originate back to the discussion boards that used to run on clunky UNIX megaliths, charged people by the minutes of access and where cracking was born. They require minimal administration, and some offer no moderation at all.

We decided on the form of our own commenting system by putting together what had remained after everything we knew we didn't want had been discarded:

[a] We didn't want a packaged forum which we could slap a logo on and be ready to go. First of all, we don't have a logo. Second, these things waste too many resources: the last one we tried created twenty (20) tables on our database with generic names such as "users" and "config" and expected to see an empty writable file outside its directory before it would work. Third, half the fun of eating is cooking.

[b] We wouldn't require registration: people can't afford the time to do so, are reluctant to give personal details to strangers and, frankly, we don't want them either. We firmly believe in taking responsibility for what you say, though, so an e-mail address would be required: unique and a means of communication. Users can still enter a false e-mail, but that is actively misleading or forging, and thus a different ball game altogether.

[c] The lineage of every posting should be readily traceable, and by some kind of graphical indicator more sophisticated than a HTML unordered list. Moreover, the lineage of a posting should remain visible even when reading or replying to it.

[d] Since the script would dig into a database to come up with the postings, we wanted to keep page reloads to a minimum, i.e. one for the overview (each title a link to the respective posting), one for every read and one for every submission. We could display all titles and contents at the same page, of course, but it wouldn't be an overview if users had to scroll up and down in order to make out the dynamics of the threads. In addition, this could potentially produce a lot of HTML in one file.

[e] We wouldn't supply ready titles and quoted content for comment replies. There are scarcely more frustrating things than seeing "Re:Re:Re..." as the visible beginning of a title and no indication as to the content. Users can always copy & paste parts of the posting they are replying to, but empty prompts are likely to tempt them to come up with more interesting things.

[f] Dates would be nice.

Considering all this ("design specifications" would seem to be the proper term, but it's hard to utter when you're listening to Doot Doot), it was obvious that we wanted something much closer to a threaded discussion than a modern forum. If we were to read/reply to a posting without losing sight of its lineage and without reloading it, though, something drastic would have to be employed. Like a pop-up window.

Silence falls.

People shiver.

Some cringe.

Having worked on FVWM and fought the evil consoles its browser loves to spawn, I tend to spray Close buttons on my room walls late at nights. Microsoft themselves don't seem to have mastered the high art of getting the width of their pop-up windows right, so maybe it wouldn't be too hard after all. Ah, this also means that we'd be limiting our audience to version 4+ browsers, effectively losing a good 1.2%. We decided we could live with that (if we could manage the rest).

Putting all this together yielded the following plan: the "parent" page would display all article titles, along with submission dates and author e-mail addresses. The latter would simply be mailto: links. Clicking on the former would pop-up a window that would display the content of the comment as well as the reply box. For simplicity reasons, we used the same window for starting a comment thread - it just doesn't display another comment. Here is the pop-up window script:

var w = null; function popup(p, w, h, s) { l = (screen.width) ? (screen.width-w)/2 : 0; t = (screen.height) ? (screen.height-h)/2 : 0; t = 'height='+h+', width='+w+', top='+t+', left='+l+', scrollbars='+s+', resizable'; w = window.open(p, '', t); }

We like it because it is short and sweet and centers the window to the screen (if information about the resolution is made available by the browser). It beats writing a 3-line A tag, but we usually add a couple of events to make sure there is no long incomprehensble code displayed in the bottom bar. Here is the command we used:

<A HREF="javascript:popup('com-display.php?id=ARTICLE_ID&cid=COMMENT_ID','452','360','yes')" OnMouseOver="window.status='Click to read/reply';return true" OnMouseOut="window.status='';return true">

Although the second window.open variable is supposed to store the title of the window to be opened, this is only really useful when opening a non-HTML window. If it contains proper HTML, like all our extra windows do, the TITLE element is used for that purpose. Consequently, we have hardcoded an empty string in the script and done away with that hassle.

The read/reply window contains a Close button and the usual form-checking scripts. Following submission of a comment the window moves to a preview, which we felt had to exist: it's hard to picture how your comment will be displayed, especially when partial HTML is allowed. We couldn't have users editing their comments after they have been submitted, because that would require user registration which is the biggest can of smallest worms. Hence, a preview of the comment and a friendly message together with a Back button to facilitate such.

And so we reach the end of the read/reply/submission process. The most dreaded part of all:

When the Send button is finally clicked, PHP takes care of the submission process, but what happens to the pop-up window? Is it left hovering there? Do we forward it to a "Thank you" message and a polite request to close it coupled by a handy Close button? The latter seems to be the most common solution to the problem. We, however, are definitely not common and can't go along with something as graceless as that.

Supposing we do, though, there still remains the issue that the user has then, after closing the pop-up window, to refresh the original page in order for the newly-made comment to appear. That's another click, two consecutive in all, that the user shouldn't have to make since we know what is required after submission, and it's a weary and growingly impatient audience we should be catering for.

Hold on, we know that PHP, after taking care of the submission process can have the current (pop-up) window load another file, right? We've been using the header command as a matter of principle for years, after all. As it turns out, it's perfectly feasible to forward our current pop-up window to one that, on loading,
1. refreshes its parent (the main window) and
2. neatly closes itself.
Voila! No shot has been fired, the enemy's dead and the new comment stands proud in all its glory. We have placed below the horribly complex code that achieves this magic feat. At a total of 119 bytes, it probably packs the highest usefulness/size ratio we've ever come up with:

<HTML><BODY OnLoad="javascript:parent.opener.document.location='index.php?id=ARTICLE_ID';window.close()"> </BODY></HTML>

This concludes this first installment of the description of the Systasis commenting system, which described the mechanics of the visible processes. How all this information is represented for the server to interact with, the database structure and PHP code used will be described in the second article which, hopefully, won't be too long now...

[ Back to journal | Expand comments | Print this page ]