By "forums" we mean an interactive discussion on the internet enabling a group of people to contribute to a debate. We also mean a discussion where, unlike a "chatroom", the contributions remain accessible until specifically removed; and, unlike an exchange of e-mails, the discussion appears on a commonly accessible site.
Already, it has been remarked of these pages that I am using terms which may not be obviously clear to the casual reader. I quote Hume: "To deliver a SYSTEM in conversation scarcely appears natural;"
One aim of these notes is to try to form a set of definitions which would be naturally translated into an object oriented implementation.
Some features of a forum system follow, call it a System from now on. (The names for components and participants in the System will be typed with capitals (when I remember), but this does not commit an implementation to use these exact terms; although, again, it is worth saying that these would, in the "real" world, be candidates for the objects defined by the software.)
The primary division of the System will be the Topic. Topics may be gathered into Topic Groups, typically but not necessarily, forming a hierarchy.
Within a Topic there will be (at least) three categories of material:
Topic Groups (and the whole System) will also have header material.
Posts will have, at least, the following elements:
The interface for entering Posts should enable the easy typing of text. Formatting should be possible, within limits, but the conventions for entry, where these are not the direct provision of HTML should be well-defined (and not subject to arbitrary change).
If limits are placed on the size of a Post or of text in a Header, then the entry interface must have a user friendly method of applying that limit.
Links will be possible in text, and the entry of links should be an easy process.
It should in general be possible to place images in a Post; however it should also be possible to preclude images in a Topic, or Topic Group, or to place a limit on the image size.
It should not be possible to place dynamic HTML or other program elements within text. If it is useful to provide features which would require programmability, then the features should be provided by some mechanism and specific formalism built into the System.
Within a topic, it should be possible to make a formal connection between a Post and that Post (or Posts) to which is replying. The actual presentation of the material should be able to recognise this implicit "threading"
There should be a general search operating on Topic titles, the text in Topics (headers, posts, and any auxiliary material), the identifications of Contributors. The search should have full Boolean complexity. It should enable restriction by date and by Topic or Topic group.
Every element of the System should have a readily determinable link.
It should be possible to set up a poll in a Topic header. The System should contain the mechanism to restrict votes to prevent multiple votes.
A general system might have an implicit polling system built in, so that for any Post counts of simple agreement or disagreement could be maintained.
There will be at least three categories of user:
(Originators and Contributors may be the same people, but for generality they should be distinguished).
It should also be possible to determine in a Post when its Contributor is the Originator of the Topic or is a Controller.
(again, this category of user is added for generality).
In a general System there is no reason to suppose that access to the whole System is available to all users; there may be secure or private Topic Groups.
There must be mechanisms for the initial registration of all Users of the System, for establishing and changing passwords, and for logging on to the System at the start of a session. The only exception to the requirement for password control would be, optionally, Readers - and then only if all or part of the System were to be made generally available.
The Contributors should, within the System, be clearly defined, with a unique name. The Contributors must be able to preserve complete anonymity outside the System. In particular no Contributor should be required to use an identification from which an e-mail address could be deduced.
There should be a facility to give each Contributor the ability to provide a readily available area to attach whatever information they are prepared to reveal. This could be limited to a single page, or could be, in effect, the provision of webspace.
There should be a facility to enable each Contributor to provide, on option, any standard text that they wish to attach to each Post.
Contributors should have, at least, the following capacities:
they should also be be able to specify, quickly, that material from any part of the System is to be regarded as having been read. This should include the ability to specify the scope of such material by date.
this should certainly include:
The System must be implemented so that it can readily changed.
Contributors must certainly be able to edit their Posts for some interval.
The Originator of a Topic should be able to modify header material at any time. This is necessary if no other reason that links on the internet are fugitive.
The System Controller should be able to change anything. Clearly this should only be done for good reason. The design of the System should enable the rearrangement of Posts and Topics without disturbing links.
Generally material should not be removed - the main exception being that Posts may be removed by their Contributor. However, practicability will demand that Topics that become obsolete or quiescent should be moved to a position where they do not clutter the System. Such an Archive must itself be reasonably accessible.
A further requirement for a form of archiving will arise when a Topic is very long-lived and very active. In this case a slightly different solution will be to provide one or more "quasi-topics" (a provisional and unsatisfactory name) with chunks of the debate removed from the continuing Topic and accessible by link from the header of the Topic.
The concept of Topic Group has been left vague. It should support, at least, a hierarchy, so that we may have sets of Topics, sets of sets, and so on within sensible limits - and it is assumed that these are determined by the System Controller.
However, the world of online discussion is not strictly nested.
Let us distinguish between simple or first level Topic Groups, which are just sets of Topics and higher level Groups which can have Topic Groups as members. We must preclude loops. But we can insist that beyond the first level the structure is strictly nested, and System wide.
But there seems no reason why simple Topic Groups should not be dynamic constructs, some provided at System level; some implicit (all Topics with the same Originator, for instance); some determined by, and only relevant to, a Contributor for whatever reason.
I think we require an object which is simply a (dynamic?) list of Topics, without the overhead that would be associated with a Topic Group.
But I also think we require a slightly more structured object, a Scope, which consists of a tree reflecting the inclusions and exclusions of Topic Groups and Topics in the System hierarchy.
I think we also need objects which are lists of other components of the System; certainly this is true of Posts.
There should be a hierarchy of ownership for every element of the System. This need be no more complex than that Contributors own their posts, and that there is an overriding ownership of the entire System by its Controller.
It is possible that the System will require some control on the origination of new Topics.
The possibility of delegation of the capacities, especially of Originators, should be considered, as should the possibility of the transfer of ownership.
It should be clearly stated what claims of the organisation providing the System makes about copyright and moral rights of contributions to the System.
by "moderation" we do not necessarily mean an active intervention examining contributions before they are accepted. Such a feature is not often desirable, and would always imply both effort (on the part of someone) and a loss of immediacy. However, a general system should include the capacity to set up moderated sections of the system.
In fact we should need to provide the Controller with the ability to create read-only Topics (or Topic Groups); and perhaps Originators should be able to create read-only Topics.
But, there will always be a requirement for elements of the System to be changed, and this should, for generality, be available to the owner or co-owner of any element of the System.
One option, related to moderation, is that areas of the System should be private. Some possibilities are:
Users should have the ability to control the way the System appears to themselves, without implications for the appearance of other web sites, or the way the System appears to other Users.
If an implementation grows without limit, then it may run into problems of scale which make it unwieldy and slow. To what extent does the System require builtin warnings and limits?
Who knows? Does any existing specialised software have the capacity to implement this?
How much of the generality presented here can be set aside in an actual System?
Is this design general enough?
The providers of the System should probably, even before a document of even this detached technical content, state their aims and intentions in setting up this means of discussion; and suggest the criteria they will use - if any - in controlling the content of the System.
They should also decide what commitment they are prepared to give to day to day supervision of the System.
Should the forum System be integrated with other modes of discussion, such as User web pages, "chatrooms", and direct messaging?
If the System replaces an existing system, then to what extent should the old material remain accessible, and in what form?
And this is the biggest open issue of all. What should the screen look like. But I suggest that it is a question best left until there is a clear design for the underlying structure.
John Bennett 8-12-2003