by Iain Duncan (@Iain_Duncan)
Building any application can be a daunting task, but building one that can be used and re-purposed by the open source software community has a certain flavour all of it's own.
If you are building and designing something that will be broken apart and reused by other developers as well as used for it's intended use as product by the man in the street, you face some unique challenges.
This article is one that I started piecing together, as myself and lead developer Andi Neck at our company intesso, built our open source CMS called Glint. My main area of focus was UX, design and front-end development with Andi focusing on the back-end and database development. So there will might be a drop of back-end but this article will mainly cover the UX, site architecture, front-end and design of the project, however most of the principles can be carried over.
1. Know what it is you are NOT building
"Without vision the people will perish"
The old saying 'if you fail to plan, you plan to fail' is one of my favourites, and with good reason. All that being said it's pretty often that I find myself getting weighed down by over planning and trying to put in feature layered upon feature to make this application the best that has ever been.
Recently while building Glint we decided to have a very clear definition of what the product was up front before a line of code was written or a pixel of paint was Photoshopped. With a clear vision we ran through a dedicated process during the principle UX(User experience) phase of our project.
As we are a two man team on this project it would be easy to just have an idea, forgo any planning and execute. Although tempting we found that going this route ultimately ended up with both of us disappearing into silos, finishing parts of the CMS that clearly weren't as important or essential as we felt they were, showcasing them to the other party and then starting over again or having to do wholesale revisions.
In the spirit of agile we came up with a mini planning session formula during the UX phase of each module's development that really helped us to keep on track and most importantly stop incorporating things we didn't actually need.
- Discuss and plan which module we are going to build
- UX designer throws the idea out into the wild and does competitive analysis and some user research
- Throw the idea's and related UX research against the vision for our CMS
- Design wire frames for execution meeting
- Discuss execution and final module planning
- Chuck out any bloat and fluff that doesn't match against our defined product vision
- Build only what is absolutely necessary
- Keep secondary ideas that could be of use for iterative improvements once the application is live
It's all too easy to fall into a mentality of agreement between developers, especially when you are working in small teams like ourselves. We instead decided to have a process that would help us to refine what it is we are designing and build only what is essential to our core vision. This is easier said than done and we have had many hours our arguments and strong discussion and hard decisions to make when deciding what not to include.
Remember that many people enjoy the simplicity of applications like Twitter but most of us get trapped in feature creep and bloat just for the sake of thinking it makes what we build better. Most of the things we love we actually love for their simplicity and single mindedness of functionality. Strive towards taking more out of your software than you put in and you will be surprised that it in fact makes your product better, more focused on it's primary task and as a result easier for your customers to use.
2. Third party implementation
We had to decide early on which 3rd party frameworks/plug ins etc. to use and when we needed to write our own. When it came to the front-end development of our CMS we had to take a hard look at the current wave of front-end frameworks that are gaining massive popularity. We feel it is vitally important to leverage knowledge already gained by many developers out there and make it easier for them to engage and be able to alter our code without being stuck in an overly obtuse world of our own creation.
We wanted a few key things when it came to our front-end dev:
- Don't create something cryptic and overly complex if you don't need to
- Start with a framework to breed familiarity with other developers
- Make it easy for community input by using a well known framework
- Must be up dateable to future versions of the chosen framework without breaking the current build/layout
- Must be a separate layer from the core site CSS/HTML
We ended up using Twitter's Bootstrap along with a few tweaks of our own:
- Custom LESS stylesheet that allows alterations and overrides to the Bootstrap framework without touching the core styles
- Using Grunt and csstransform we allow for both our CMS and the core website it's built on top of to have 2 separate working versions of Bootstrap. This workaround allows a true separation of the core website's front-end from that of our CMS.
- Fully upgradeable and separate working version of Bootstrap for the CMS
This is just one example of how we are trying to implement widely used frameworks into our project. We have a strong belief that in the end by using such we will ultimately make the project more open and easier for others to edit and add to in the future.
3. Structure, structure, structure!
The last but not least point that we learned while building Glint is that overall structure is one of the most vital things.
When a product is going to be ripped apart and tinkered with by other developers it's important to have a well thought out structure in place. After having done hours and hours of competitive research this single point rose far above others when it came to ease of use for others to contribute to your project. Far too many open-source CMS projects have an overly long winded way of doing things and a steep learning curve when it comes to figuring out site architecture.
SInce we were building a CMS one of the principle problems we had to deal with was creating a spaghetti mess of files and folders with mixed relationships all bungled together. We had to make sure there was a clear separation between the site that was built by the CMS (core site) and the CMS architecture itself.
Here are some of the core principles we followed:
- Separate 'Website' and 'Glint CMS' parent folders
- Mirror sub folder structure under each tree e.g. both CMS and Website folders have App, Public, Vendor folders etc.
- Use the MVC model across both
- Build for extension, but still allow overrides
By keeping a mirrored structure as much as possible it makes it far easier to switch and find core files across both the framework and website. It also means that after building a website users who fancy tinkering with the CMS can easily get started as as many of the fundamental structures and principles as possible have been carried across to the CMS framework.
Wrap up
Although still a work in progress we have learned many valuable lessons so far and hopefully these fundamentals will help you when building your own open-source applications.
- Strive towards taking more out of your software than you put in
- Play well with others and make it easier for other developers to contribute by making good use of 3rd party frameworks where applicable
- Structure, structure, structure! Keep a clean house and you'll make it more inviting for others to contribute