How we did the Cobblestone Prayer Plugin

Central to the mission of Cobblestone Community Network is the desire to help small groups gather around activities that are close to their hearts.  This desire will hopefully enrich the lives of group members and raise the quality of time spent together which in turn should produce growth.  It is with this in mind that we developed the Prayer Plugin for Cobblestone:  To help small groups gathered around the belief that God hears our prayers and answers them according to His good pleasure that in so doing, our faith will grow strong.

Since the Cobblestone Framework already exists, all we needed to do was gather around a whiteboard and pour our hearts into a flow chart of what the Prayer Plugin should do.

Step 1: High Level Flow Chart

A quick side note: It would benefit any developer partaking in a flow charting session to allow the dreamers to dream.  All too often we get bogged down by the how’s and this tends to stifle collaboration and the great ideas that might actually surface from the rubble of incoherent suggestions that get flung out onto the whiteboard.  In order to maintain some control, I would highly recommend you grab the marker and arm the position at the whiteboard.  This role is pivotal in converting dreamy digital noise into a sequential stream of logical symphony.

The first challenge was to define what the Prayer Plugin could offer outside a simple post with commenting enabled.  What we came up with is summarized in the following screen shots.

The first challenge is being faced with a blank whiteboard. Often I have found the best way to start being to simply ask “what” it is you are describing. It is remarkable how much information is gleaned from simply listing the attributes.

After this it helps to ask what action will take place on the object described, in this case prayer. Again it is important to simply let the ideas flow. One can worry about how to implement later.

Once the obvious has made it onto the whiteboard, the really interesting ideas start flowing.

To summarize, a prayer in Cobblestone:

• is part of a group (which could be public or private)
• has a title
• has a description
• has an urgency level
• is of type praise or request
• contains people to be prayed for
• contains keywords or tags

Further more, activities on a prayer includes:

• commenting
• praying - a great way to notify the originator that you are praying but also that you’d like to receive updates on this prayer request
• status change
• scripture commenting whereby encouragement can be given in the form of scripture which will be displayed inline
• automatic follow up for archiving, reminders or notifications

Step 2: Specification Document

Once the ideas on the whiteboard have been agreed upon, the often tedious task of making sense of it all follows. It is usually better to have a more analytical perspective when working through the flow charts as this will bring up several questions that have not been raised during the excitement of high five’ing each other at the whiteboard.

A critical component of this document is the User Interface (also known as Wire Framing). This is especially useful when implementing within MVC frameworks in that styling views can be ignored until a later stage without compromising the implementation of the models and controllers.

Here is a screen shot of the Specification document we wrote for the Prayer Plugin:

As a result of writing this specification, a ton of questions came up regarding notification settings, group types and group module management. These have been diverted to other documents but has allowed for us to keep these aspects in mind as we develop the Prayer plugin.

Step 3: Entity Relationship Diagrams

If whiteboards offer lively discussions between the developers and the dreamers, the ERD provides plenty of that amongst developers. And so it should. I have found that just like most guitar players think they’re bass players, which they’re not, most developers think they’re database designers, which they’re not. It takes hard work and multiple refining iterations to produce the most optimized SQL design. Defining primary keys, compound keys and knowing your one to many’s and many’s to ones are essential.

Here is an example of an early round ERD for the Prayer Plugin:

Step 4: Code

Code, code, code!

Step 5: Style

With the coding and debugging completed it is up to the CSS guru to come in and style the views.  In some cases this will raise issues either because it’s been a while since the whiteboarding exercise of step 1, or new ideas rear their ugly heads.  I have found that going back to the whiteboard often provides a level of comfort to everyone in the team as it provides a platform for dreaming up the next version of a particular feature without arguing that it was supposed to be in the current version.

Here is a screenshot of what the Prayer Plugin’s ‘View all Prayers’ page looks like:

1. Adam says:

   June 30, 2009 at 8:49 am

   Etienne, Looks cool!
2. Drew Goodmanson says:

   June 30, 2009 at 9:22 am

   Great work, some additional screenshots are here: