About a month ago, I had worked for three days to come up with a proof of concept for a project collaboration platform aimed at a small company – typically less than 40 people). The webapp was not something that could be actually used by anyone. There were glaring holes and missing functionalities that would be useless for any actual company.
I still had no idea as to how much time would it take to polish it to a point that it would be a commercially viable product.
Here were my objectives:
- A project (segment) consists of individual discussions.
- A discussion (thread) consists of individual Markdown formatted posts.
- A post can contain some text or attachments. It can also have some searchable tags.
- A collection of to-do entry resides inside a project.
- It is possible to start a discussion thread against a to-do entry.
- It is possible to mark a discussion as a to-do entry.
- The author of a discussion thread / to-do can assign the to-do to anyone else.
- A to-do mark can only be closed either by the author or by the one who has been assigned.
- The author of a thread can lock the thread.
- The registration system is not open. Only an admin can invite an user.
- An admin can grant regular users admin privileges as well as lock their account.
- The author of a thread can also invite an external user who can only participate in that thread.
One of the biggest problem with my proof of concept was the MySQL interface implementation. It took me quite a few hours of work to write an abstraction layer that can work with people simultaneously accessing different databases. This was necessary as each company is assigned a unique database while everyone would be accessing these databases via the same code. The solution was not to have a persistent connection but create an on demand connection and cursor whenever a request is received.
One weekend, me and Mogit sat down and drew the interfaces on paper. This became the basis for the layout of the webapp. It’s fairly simple and looks best on a desktop. The CSS needs a lot of tweaking for mobile and low resolution screens. I can safely say that it is far simpler to transform hand-drawn layouts to their HTML+CSS counterparts than toil somewhat aimlessly on a computer.
Once the overall templates were ready, it was all about writing the implementation. Barring a handful of functions, most of the code has been re-written. Just like any other form of art, churning out simple and efficient application in a framework takes time. This also means that I have a fair idea of how to approach an webapp in Flask. Next time, it would be much faster.
We are using Ninjin to develop Ninjin itself. (That’s so meta!)
Two projects focussed on development and bug tracking respectively.
Here is a list of stuff that I will have to do before I can call it a “product”.
This is what the thread author option looks like.
I had kept a track of the number of hours I had spent behind this project. Not counting the initial three day hackathon, I have spent 36 hours in building this app. That’s not bad for a start!