I have broken down this article to approximately 15 posts which I’ll publish once every week. You could also access them using the keyword rmdstudio cb anatomy on Technorati. Readers from both business or technology backgrounds could find this article useful.
View this image on Flickr
This article portrays a 10,000 feet view of a Community Builder (CB) web application similar to the ones you see around on the web (Flickr, Facebook, Digg.com, … ), although my take on this topic would be a bit more vanilla and abstract. Building a more sophisticated CB application is closely tied to the business requirements and also the cultural and sociological aspects of the online community we’re trying to grow. Knowing that, each specialized case should be treated differently and that really goes beyond the scope of this article.
In the mean time, as I am dissecting and going through , I will be emphasizing details that I think are important.
The 12 building blocks
I have managed to break down a generic CB application to 12 main components that are worthy of being discussed. Of course this number could vary in different projects, as a matter of fact, not every project requires all of them.
- There is a simple diagram here that you can download. It is released under the creative commons license meaning that you can use it and redistribute it.
I figured using today’s available frameworks such as Joomla 1.5, Drupal or Ruby on Rails, each component could be developed and refined in approximately 100 hours good enough to be used for a real life project. That includes all the time required for squishing bugs, fine tuning user interfaces and the overall software architecture.
The reason I have named those three frameworks is because they:
- have proved to be reliable frameworks in different projects
- are all open source
- have well designed APIs
- are well supported by great communities of users and developers
- use a 3 tiered architecture called Model View Controller (MVC).
If terms such as API or MVC sound too technical for you, just keep in mind that having a good API and MVC architecture makes your application more flexible and maintainable. It might cut down the development time but that is not always the case. What’s certain that, for sure it will keep the design cleaner, more flexible, and maintainable, and that will save you time and resources in the future.
But isn’t 100 hours per component an overestimate ?
You may think 100 hours development time per component is an overestimate. Yes, I do believe that there are fine developers out there who can put together each component in less time.
I guess I am being pragmatic by considering a standard developer, probably hired through a job recruitment agency, working in a corporate environment or a small development house. Top notch Architects are rare species and often self employed. If you’ve found one, then good for you!
That said, please consider that tailoring a generic CB application to a specialized business model does require extra time and resources. Instead of cutting corners, use a combination of following methods:
- Consider alternative options to find resources ( knowledge, time, brain power )
- Reduce your project requirements
- Develop in multiple stages over time, instead of building the whole thing at once.
Keeping the Architecture loosely coupled and flexible
Charles Darwin himself observed that it is not the strongest of the species that survive, nor the most intelligent, rather, it is those most responsive to change.
Same idea also applies to computer software.
A CB web application is an organic entity therefore subject to change and evolution. Staying with a more generic and loosely coupled architecture maintains the flexibility of the system. A web application built based on a stiff marketing and business plan might appear successful today, but it is often doomed to extinction in long term.
NOTE: if you believe in Intelligent Design, then consider this: A divine creator would have done it the same way I am telling you!
A model for cost and time estimation
I think the modular model described here could be used as a cheat sheet for making time and cost estimations.
One advice to the developers: to be on the safe side, you may want to build some of the generic components first before you go hunting for projects. That way you could spend more time on customization rather than building each infrastructure from ground up.
I would also be interested to know your input on this subject, so please don’t hesitate to post your comments. Next week I’ll be discussing the User Manger Component which I think is the back-bone of every CB application.
[tags]rmdstudio cb anatomy, rmdstudio, rastin mehr, community builder, web application architecture, joomla, drupal, ror, ruby on rails, mvc, model view controller, charles darwin, evolution, intelligent design, software architecture, api, modular design[/tags]
3 thoughts on “Anatomy of a Community Builder Web App – Part 1”
I like the way you’re approaching a generic CB application. I do think some of the components you highlighted like community policing and user management would overlap other components. I haven’t had any real experience with the frameworks you mentioned (I did play around with ruby awhile ago) but I can’t agree with the 100 hour per component. considering how much of the stuff covered in you components would be overlapping and how extensive some of these components (search for example) are already developed within the mentioned frameworks. I do think you’re overestimating.
Something else I wanted to mention. Consider that not every online community will be a facebook or flickr. Take an online community like fark.com. Here is a community that does not have majority of the components you mentioned and is constructed in a rather non-traditional way. How would this generic CB builder be able to provide support for communities with abstract features. How much low level access will the developer have on various components. how much freedom can be offered within such a builder and still take care of all the technical labor.
“I do think some of the components you highlighted like community policing and user management would overlap other components.”
Yes the overlap is there, Joomla! CMS has the plugins and modules that could resolve the overlapping issues, but in some cases we may have to even merge some of the components.
“I canâ€™t agree with the 100 hour per component.”
“I do think youâ€™re overestimating.”
Perhaps you and I could do each extension in less time, but I was considering an optimum case with an average developer and average corporate development house. I guess for that I am probably under estimating too.
“a community that does not have majority of the components you mentioned and is constructed in a rather non-traditional way.”
True! the idea is that a community could be built using all or some of those extensions and components. I do agree not all communities need all the extensions.
I would build the extensions and components as Vanila and Abstract as possible with higher degree of modularity, and leave the customization to the developers.
At the end, I am actually building those components in Joomla 1.5 and later, and you have pointed out many valid points. These will be released under the GPL License. I really really appreciate the fact that you took the time writing such a great comments. Thank you so much 🙂
Comments are closed.