In the Frame II: Intentions

The Application:
Having announced my ambitions, I had better announce my intentions: what application shall I write?

My trusty Rails reference is Dave Thomas and David Heinemeier Honsson :'Agile Web Programming with Rails', which describes a simple shopping cart application. A little copycattish to do that again, I think.

Instead, since I am going to be developing the application in triplicate, I shall choose something that caters for multi-user interaction: I shall create a conversation whiteboard.

What this will allow is for each version of the application to interact with each other (in theory!).

Important stuff first
What to call it?

Well, it's a chat application with multiple varieties, so a starting point of 'N-chat' leads naturally to calling it:

Enchant

Analysis
How do I imagine it operating?

Starting with a conversation board, a user can select which of several groups they might like to join.
(There might even be a snatch of overheard conversation to help them decide)
On selecting that conversation, the user then sees a number of views*:

• one for what is typed in
• one for the general buzz of conversation
• a few extracted streams, associated with user.
  

Oh yes, they will probably want to be able to leave as well!

There are any number of refinements that can be added to all this, but I think this will be more than enough for a training exercise (especially if muggins here is going to be doing it in triplicate!)

Design
OK, what we have already suggests a number of design issues:

• two main displays: the main listing, and the conversation area
• A database (which isn't strictly necessary for casual chit-chat forums, but which might prove useful for playback. This poses a small problem in that I don't actually have a database that is accessible online...so we may dispense with that. That would be a pity, since ORM is a major support feature of these frameworks)

Tackling the main listing first, it should handle the following use cases:

• view conversations (default)
• create conversation
• join existing conversation

The conversation space should handle the following, at least:

• add to conversation
• update conversation
• leave conversation

In the spirit of Agile programming, we will leave the list at that, and add to it as time and experience suggest.

*You will note a few mixed metaphors going on here, as I try and cram square pegs into round holes, and describe a visual application for what is, traditionally, an aural/oral activity. This isn't an idle observation: I think it's a major issue of chat sessions, which we will not be solving here)