start > 2007-11-05 > 1

Software Developing: Implementing a ShoutBox on SnipsSnip

Created by pabrantes. Last edited by pabrantes, 342 days ago. Viewed 848 times. #3

[diff] [history] [edit] [rdf]

labels

attachments

Software Developing: Implementing a ShoutBox on SnipsSnip

Since a few months ago I noticed that the number of visits were raising although most of the readers won't comment. In my opinion, this behaviour is due to the fact that SnipSnap only allows logged-in users to comment and even though the registration process is quite simple and fast some readers probably prefer to skip the process and not comment at all.
The idea of allowing guests to comment is in the list of features to implement, although since a comment is a snip and a snip needs to have an owner it has implications, such as, who is the owner of such snip - some default user? should be an editor and the snip be locked? - I still haven't find out a good solution so that implementation keeps getting postponed.

Meanwhile, I thought that a good idea would be the existence of a shoutbox. For the ones who don't know, a shoutbox is a chat-like feature that allows people to quickly leave messages on the website, generally without any form of user registration.
It's not my intention to replace the comments with the shoutbox, but it could be a feature that allows interaction with new users, which then might lead to the registration of those users.

On Friday I developed a simple implementation of a memory-only shoutbox. I'm saying memory-only because the messages aren't persistent, there's a buffer that keeps messages in memory only (size is configurable) and after it's full it has a policy of first in, first out (FIFO). Also since it's only in memory if the server is restarted the current shoutbox is lost.

The implementation is very simple and it only needed to create three new objects, the ShoutBox, the ShoutBoxServlet and finally the ShoutBoxMacro.

ShoutBox
The ShoutBox is the object that is part of the model. Basically ShoutBox is a wrapper around an application aware map that contains for each one of the application instances that SnipSnap is running a list of shouts. A shout is nothing more than a formatted string with the date, user and actual input.

ShoutBoxServlet
The ShoutBoxServlet is the controller. It receives data from the interface and after input formatting and escaping (in order to avoid XSS) it passes the information to the ShoutBox object.

ShoutBoxMacro
The ShoutBoxMacro is the tool given to the user. It is a component that renders the shouts' list for the current application and also renders an input box to enter new shouts.

A schematic can be found below.

shoutbox-render

This is the first version and I'm aware that improvements can be done, such as:

Allow editors to moderate the ShoutBox. Currently shouts are only deleted when they are thrown out of the shout buffer.
Using javascript to submit and update the shout panel auto-magically.

Any other suggestions, comments and critics are welcomed.

m4ktub, 342 days ago.

Hi,

I've been using Last.fm and although I don't shout the shoutbox in everypage is a very used feature. Notice that in Last.fm you need to be logged in to shout anyway. Spam bots are terrible so beware.

I have one idea between the login and the free shout box. Instead of forcing a login to post, you (read SnipIt) can show the post box with two additional fiels: name and email (url, OpenID, whatever) and create or reuse a new user. One that is between active and nonexistant. So this user does not have a login but has snips associated to him and when the user decides to register you can ask something like "Did you write this things: ...?".

(ofcourse a "no" would give the same headaches ...) smiley

PS: http://en.wikipedia.org/wiki/SnipSnap the first step to become famous smiley

PPS: Lots of spelling errors and others. Feel free to improve.

pabrantes, 342 days ago.

I have one idea between the login and the free shout box. Instead of forcing a login to post, you (read SnipIt) can show the post box with two additional fiels: name and email (url, OpenID, whatever) and create or reuse a new user. One that is between active and nonexistant. So this user does not have a login but has snips associated to him and when the user decides to register you can ask something like "Did you write this things: ...?".
m4ktub

That's an interesting idea. Although what would happen if the user would say "no, those are not my posts" we had to have a way to tell that those posts no longer belong to that user… Something like username(not registered) versus username.

But that's a strange concept in a bliki isn't it? The comments are nothing more than pages on a wiki and if someone wants to participate in the wiki it should register first.

But I like the concept you suggested! smiley

And thank you for the wikipedia entry! When I'll be a gazillionaire for being refered in wikipedia I'll give you your share laugh

skimmer, 342 days ago.

Nice idea. I could see it being implemented as a standard feature next to "comment" and attached to a snip in the same way. The difference would be the user would be "guest/shouter", no editing after submitted, and the persistence based on a Admin(Setup) setting of 1-? days. After the time period the Shout would automatically be removed by a background thread.

pabrantes, 341 days ago.

I could see it being implemented as a standard feature next to "comment" and attached to a snip in the same way.
skimmer

Well, I never thought on a shoutbox per snip, but actually a shoutbox per application, but that's something that is simple to modify.

(...) and the persistence based on a Admin(Setup) setting of 1-? days. After the time period the Shout would automatically be removed by a background thread.
skimmer

I don't see the need for having a thread (even if low priority), they could be just ruled out on insertion of other shouts (like is currently being done) or when retrieving the shouts. Any special reason I'm missing and that made you suggest a thread?

Please login to www.pabrantes.net.