An Update on the DirigoEdge CMS Platform10/10/2016
Our last DirigoEdge blog post is ancient history, but, don’t let the silence say anything about our commitment to the platform. We’ve come a long way and continue to invest thousands of hours per year into our software products. The DirigoEdge Web Content Management (WCM) platform has matured and is being well received by its target vertical. It’s always been a ‘niche play’. We’re not building WordPress because the world already has a WordPress. We’re making something very differentiated, and quite honestly, that has more utility than a generic WCM because of the specialization.
DirigoEdge is alive and well. We’re so busy onboarding new clients that we don’t have time to toot our own horn. Version 2.7.0 of DirigoEdge was the end of the road for V2. Its replacement, Version 3 had its first installation over the Summer of 2016 with www.schweitzer.com. Schweitzer Mountain was Dirigo's first large resort on V1 of the platform and they liked it so much that they came back for a redo 3 years later to get all the great new features.
The largest distinction between the two versions is a rework to Schemas and Modules. In V2 Schemas were stored in JSON format and in V3 they’re stored in SQL database tables. Schemas and modules were extended with more functionality and now support super large record sets. A new approach to building custom CMS input screens was the genesis for the new version. How do we provide clients with templates — really input masks — that are dead-simple to create and use? How do we drive down the development cost for these custom admin areas? How do we make using DirigoEdge simpler? These were the questions addressed with the new release.
On top of the Schema and Module changes we added load balancing and support for full integration of the WAVE tool (so that we can identify and log ADA compliance concerns) to Version 3. This is a short list of other changes:
- Fix responsive background images
- Allow inclusion of blank metadata
- Address CKEditor replacement issue
- Restructure Web Config file
- Add centralized logging functionality
- Adjustments to list item cloning
- Add slideshow preset
- Add event field types to list events
- Add schema to a new page if it is provided
- Allow rearranging of field selectors
- Added the ability to define field presets
- Fixed the problem with ampersands as part of folder names
- Handle cursor position better and clean up permalink events
- Added the ability to extend schema field types
- Tied the field types to the storage types for client-specific additions
- Relax validating schemas when saving a draft
The first version of DirigoEdge began to take shape in mid-2012. With Version 1.0 we were still thrashing around getting our development model straightened out and learning from our customers. The most difficult piece to building software, in my opinion, is maintaining compatibility and the ability to roll changes out to different clients easily. Testing is also quite difficult and time consuming. Building enterprise software is different than building websites.
By March 2013 we had achieved critical mass and the platform was meeting most of our needs. Getting to this point was messy. Then in March 2014 we released our first mega update with a move from Foundation to Bootstrap (though, V2 was a much deeper restructure). At Version 2.3 in April 2015 we ported the project from Team Foundation Server to GitHub. Moving to Git and the exit of J.P. Berry who had been the mastermind of the first version was a transformational event. By the summer of 2015 we had morphed from individual contributors to a software development team following best practices.
We’ve earned our ‘sea legs’ and our software development process is the ‘real deal’. We’ve transformed from an Agency that creates websites into an agency that sells an enterprise platform — a business that can develop enterprise software. We’re a product company now. Albeit, website development is a big part of what we do.
Fast forward another year and we’re about to release two software projects that will further transform Dirigo. All of this did not happen through natural selection or happenstance. It was a conscious strategic decision by the three partners to channel resources into building a portfolio of products that would become a platform. We’re honored that our products have been well received.
The transition has been slow and arduous. I reckon that we are 6-12 months behind where I thought we might be around this time. And we’ve spent more than twice what I thought we might spend in terms of effort and development hours.
Thirty-three months ago I wrote this:
Even a simple CMS system takes a very long time to build. We knew that building our own CMS would not be a trivial task. Each passing month we make greater and greater investments. That's just it, we're investing in our future. We’re glad that we built DirigoEdge—it’s precisely what we needed.
Much has changed since those words, but, they’re still as true today as almost three years ago.