![[Logo of the Galion Public Library]](/img/hdrxparent.png)
As you can see, I have already begun a preliminary implementation, although it
is not yet finished. The question remains, assuming that I can implement this,
and that the computational resources of this server are enough to handle it (which,
I suspect, is not a problem on both counts), will such a thing be useful,
or will it just sit around and collect metaphorical dust?
2006 Jul 18
Library Discussion Forum
So, the library staff would post articles, and then everyone else could respond with their thoughts?
Anyone with a library card from our library could respond, yes. In addition to the staff, board members could probably also post topics.
Requiring a library card number would hopefully prevent the forum from being overrun with automated junk posts, without requiring anyone to go through a lengthy sign-up and verification process, complete a complicated CAPTCHA, or similar measures like most online fora have started requiring. It also eliminates the need for the user to memorize yet another username and password just for our forum. Our patrons should all have a library card already, so using that for login is a way we can make life easier for everyone and yet still keep the spammers out.
I see, and you can tell which comments are posted by staff, too.
Yes. This is what a comment from a board member would look like.
This is what a comment from a member of the Friends of the Library might look like. (Although, tracking who is a current member of the Friends all of the time could be difficult to do perfectly.)
I've now implemented reply notification, so that if you give the forum your email address, it will drop you a line whenever anyone replies to one of your forum posts. This is only lightly tested, but I believe it now works.
So, if I post a reply here, you will get email?
That's the idea. Here, let me test that. After I send this, you should get email.
I have now tested in the following browsers:
* Firefox 1.5.0.4 (but all versions should work)
* Opera 9.01
* Konqueror 3.4.3
* MSIE 6.0.3790.1830 (with some limitations)
The chief limitation with MSIE is that styles do not come through on dynamically-fetched information. For this reason, the Read More link on MSIE links to a separate page; whereas, on other browsers it loads the content dynamically. (This is accomplished by sniffing for "msie", case-insensitive, in the user-agent string, so if your other browser is spoofing IE, you may get sent to a separate page unnecessarily. This seems to me like less of a mishap than missing the styles altogether if you really are using IE. At some point I will test with IE7 and see if it can handle this better than IE6.)
With regard to inserting dynamically-retrieved content, IE7 needs to be treated the same as IE6, i.e., styles are not re-applied when the class transfers.
As for other browsers, anything Gecko-based (Netscape, Flock, SeaMonkey, K-Meleon, Camino, Epiphany, ...) should all work the same as Firefox, and I wouldn't worry about testing them all individually.
Theoretically Safari should work the same as Konqueror, but Safari is worth testing separately, if someone has access to a Mac.
Minor or specialty browsers, such as Lynx, will probably not work, and there isn't much to be done about that without doing a lot of sniffing and serving out legacy versions of everything with no client-side scripting. If this were the library's main website that would probably be worth doing, but for a discussion forum perhaps not.
As it turns out, the "Read More" links will be plain vanilla links for MSIE as well as most robots (e.g., search-engine indexers). This at least allows the content to be accessed. Additionally, you can now force _all_ of the links to be plain old links via a setting in your preferences, so that the forum is useable (albeit somewhat less convenient and a little rough around the edges in places) without Javascript.
Update: MSIE became a first-class citizen sometime in late 2006 or early 2007.