As a self-taught software developer, I have found the best way to learn a new technology stack is to jump right in and build a project using that technology. By immersing myself in a project, I am able to gain a solid understanding of the technology and establish knowledge for future projects.
A great way to seek out these opportunities for knowledge growth is to volunteer personal time to build software using an unfamiliar technology. In 2016, I volunteered to build the website for the inaugural year of Revolution Conference, a two-day software development event.
I chose to use a headless WordPress install with a custom API as a back end and Angular as a front end for RevolutionConf.com.
I was very comfortable in WordPress and PHP, but wanted to stretch my understanding of Angular. The finished conference website looked professional and functioned well for visitors, but it was content-rich and needed frequent updates (e.g. if a speaker needed to add a bio).
The task of updating content fell to the overtaxed event organizers, which meant updates only happened when one of them had a free moment. This experience highlighted a well-known issue within many content management systems – the content entry choke point.
For most applications and websites, content entry is limited to a few key people. For a website like Revolution Conference, which has a lot of time-sensitive information coming from multiple sources, a few editors managing all of that content quickly becomes a choke point.
I decided to volunteer again this year to build the Revolution Conference website, but this time I understood my primary goal – I needed to develop a site that allowed multiple contributors to easily update and add new content.
I wanted to expand my expertise in Node.js, so it was an easy decision to use that for the back end and the statically built front end. I wanted to avoid WordPress and any other traditional CMS altogether.
Based on the previous year’s experience, I knew I didn’t want a few key editors of the site’s content. I wanted anyone to be able to contribute content.
SOURCE CONTROL FOR CMS
After some contemplation, the idea of using a web-based source control solution as a repository of content dawned on me. Given the Revolution Conference is geared toward professional software developers, I knew most of the speakers and attendees worked with GitHub (or at least Git).
I began to pull out any hard-coded content I had already added to the website and structured it and all new data into a series of files and directories.
After that, organization of the content naturally fell into place. Content that didn’t have rich text or images got a single file. More complicated content got a directory for each type, as well as a subdirectory for each item that contained images.
I created a tool that pulled the content down from the content repository and parsed it into easily consumable data (JSON files for each data type, which linked to images on the Github CDN).
COMMUNITY DROVE CONTENT
For those who chose to contribute, the process of updating and adding content followed the same path as contributing to any open source project on GitHub. This new method made the website a success, as the choke point of only a few content editors was resolved.
In 2016, only two or three editors could update content, but in this year, 35 people, including conference organizers, volunteers and speakers updated and/or added content. This new design allowed the community to drive the content management on the site.
Based on this success, I plan on expanding this concept and making a tool that allows anyone to easily update content, even people without any coding experience.
The code written for converting the content repo to data has been packaged and released at npmjs.com/package/cdcm
You can explore the application repo of the Revolution Conference app at github.com/RevolutionVA/website2017
This project is an excellent example of how a personal development goal turned into a practical method for community-driven content systems.