This document outlines necessary functionality and behavior of the new ACS 4.0 Bulletin Board system (herein referred to as bboard).
Our intent (as of 8/2000) is to start with a simple implementation that can accomodate future advanced functionality. As a result, these requirements may not prescribe functionality present in the ACS 3.4 bboard system. We are using the uslaw-bboard module as inspiration for a lightweight implementation.
Futhermore, this document is conservative in attempting to describe the ultimate framework for modular web based messaging. We hope such an architecture may well be born out of iterative process when designing this system. However, the scope is being primarily limited to functional requirements.
The future requirements (section VII) should inform the design process if not initially implemented.
An electronic bulletin board system is one of the simplest and most effective forms of collaboration between people separated in space and time. Bboards provide a centralized and shared venue for discussion that save communication costs over ad-hoc mechanisms (like arbitrary email lists). Since messages are organized by topic as well as temporally, bboard can provide lightweight interfaces for rapidly navigating to interesting messages. This low barrier to participation encourages spontaneous collaboration between disperse parties in the community.
The bboard system also serves as a useful archive and ad-hoc knowledge management tool by virtue of its persistence, light weight organizational structure, and flexible browse and search facilities. This sort of knowledge base can be easily leveraged to provide long term pedagogical value as well as aid in future problem solving.
When integrated with an email system, bboards radically improve email based collaboration. Email notifications can encourage continuous awareness of community issues. Email based reply functionality further lowers the barrier to participation, encouraging more Interaction around the TransactionTM.
The bboard system allows users to browse, read, and post messages organized into forums. Messages consist of short text messages with optional attachments such as image files or html documents. Messages are organized into threads when users reply to each other, maintaining the temporal flow of a particular discussion.
Forums are contexts for discussion relating to a particular domain of interest. Examples include the photo.net Q&A forum, the ArsDigita Web/DB forum, and the away.com discussion forum. Messages within a particular forum can optionally be tagged as being in certain categories to assist searching and navigation. Forums are always created in the context of a subsite.
Administrator: Phillis Goodsport is a world famous lithographer who wants to share her knowledge about lithography and encourage interaction between a community of lithographers on her new site litho.net. Although she likes the idea of a broad forum for general lithography discussion, she wants browsing to be tractable when traffic increases. If quality goes down, she'd like to dedicate one of her minions to moderating traffic to maintain her high standards.
Casual browser and poster: Joe Schmoe goes to photo.net for the first time and wants to ask what zoom lens to buy. He needs to find the appropriate category/topic to post his message.
Compulsive reader and expert poster: Jane Developer is a web development guru and wants to keep up with as much of the traffic on the web/db forum as possible. She wants to become aware of posts that might become relevant to her in the future as well as help out folks who have problems she knows how to solve. Since Jane is on lots of developer mailing lists, her preferred form of interaction is via email.
Moderator: Dave Balderdash is a chatter.net moderator and wants to delete redundant or useless posts. He's short on time, so he wants a quick interface for rejecting and approving posts.
Targeted researcher: Ted Stetson is an ACS developer who remembers someone mentioning something about his Oracle problem on a bboard. He wants to find records of similar problems and any related solutions.
10.10.10 The bboard system must provide mechanism for users to effectively choose which messages to read within a forum. Bboard must provide an overview interface to enable users to find messages of interest or relevant to them. This overview should provide the user with cursory information to facilitate quick scanning and meaningful evaluation of message contents.
10.10.15 The full text of bboard messages should be searchable by user queries.
10.10.20 [unimplemented] Bboard should consistently provide a mechanism to limit or sort displayed posts by categories, posters, and date range as well as to perform a text search.
10.10.30 [unimplemented] Most users primarily want to browse and read new posts or replies since their last visit. The bboard interface must allow users to ignore messages they've already read.
10.10.40 [unimplemented] Users should be able to search within and limit scope to messages they have already read as well as messages they have not read at all.
10.10.50 Users must be able to easily post new messages to a bboard, or reply to existing messages they have come across. When replying, users must be presenting with enough context to assist their composition.
10.20.10 Users can register for email notification of new messages in a particular forums.
10.20.13 Users can register for email notifications on a particular thread.
10.20.16 Users can register for email notifications on a particular category.
10.20.20 [unimplemented] Notifications can be sent as each message arrives or in an organized digest form over a configurable time period.
10.20.30 Individual messages will have appropriate RFC 822 headers to enable threading in the mail client.
10.20.40 [unimplemented] Email from the alert system should be tagged in the header with the site and forum name to enable easy filtering in mail clients. Well, as easy as the mail clients make it anyway.
10.20.50 [unimplemented] If the user requests it, email generated should use MIME encoding to deliver attachements and appropriately encode HTML. Otherwise plain text emails should be augmented with URLs and styling cues in place of rich content.
10.30.10 The bboard system must support a flexible presentation layer that allows custom layout of bboard content.
10.30.15 Publishers should have the option of displaying discussions in a flat linear fashion or in an indented threaded view.
10.30.20 Parties with administrative privileges on a particular subsite can create, delete, and edit forums scoped to that subsite.
10.30.30 Forums can be designated moderated in which case parties with sufficient privileges must approve messages before they are displayed generally.
10.40.10 Reading forums
10.40.20 Reading messages
10.40.30 Posting new messages
10.40.50 Approving and rejecting posted messages (for moderated groups)
10.40.60 Managing the forum (editing title and description, determining moderation and restriction policies, granting approval privileges to others, banning users)
10.40.70 Managing categories (editing, deleting, combining categories)
10.80.10 Messages are the basic units of the bboard module. The bboard system will provide a repository to store text messages.
10.80.20 Messages will be tagged as having HTML, plain text, or preformatted text in their body.
10.80.30 Messages will have a brief plain text subject line.
10.80.40 Messages will be related to their creating user.
10.80.50 Messages may optionally have binary attachments.
10.80.60 The bboard system must store relations between messages and their replies to enable threaded views.
10.90.10 Forums are the main administrative units of the bboard system. Forums are containers to which messages uniquely belong.
10.90.20 Forums must have a brief text descriptions and optionally a longer description called a charter.
10.100.10 There must be a mechanism for intra-forum categorization to facilitate filter, searching, and tractability.
Since bboard is primarily an end user application any exposed APIs will come out of the design rather than nailed down requirements from the start. Stay tuned.
10.255.10 bboard should provide a framework for extending the generic messaging repository with meta-data and in tandem extending the user interface to take advantage of this meta-data. This would let developers properly layer functionality such as geo-spatial messaging and slashdot style scoring. This is actually provided via ACS messaging and the ACS Object system.
10.255.20 bboard should support replying to and initiating threads from email. Administrative email list functionality should be developed or integrated.
10.255.30 Bboard should let users register interests (categories, certain users, keywords) for the purpose of filtering and sorting message displays.
10.255.40 Users should have the option of enabling spell checking on their posts. A framework for filtering (removing bad words, promoting text URLs to html links, auto detecting HTML vs. plain text, etc.,) should exist.
10.255.50 Allow users to configure how big the textareas editing widgets they get are.
10.255.60 Moderators should be given the option of making notes on a given discussion that appear prominently in the discussion display.
10.255.70 Moderators should be able to set posts to expire at a configurable time in the future.
10.255.80 Mega bonus points: an nntp gateway to bboards for access from standard news clients.
10.255.90 The bboard system should be able to take advantage of a caching system that stores the results of database queries for optimal scalability.
10.255.100 Publishers should have the option of allowing users to edit various parts of messages after they are posted (e.g. the text body, the subject, the text presentaiton style etc.,)
10.255.110 A user interface should allow administrators to easily categorize or recategorize existing messages.
10.255.120 Publishers should be able to classify users based on their forum contributions and appropriately target them for email, promotions, etc.,
10.255.130 Explicit permissions for posting new messages vs. posting replies.
10.255.140 Explicit permissions for posting attachments.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 08/23/2000 | Anukul Kapoor |
| 0.2 | Revision: More standard style, more detailed requirements. | 08/24/2000 | Anukul Kapoor |