Slate Development History
May 2022
The development of Slate dates back far before slate had been name. It's design, it's proverbial DNA is inherited from its predecessors.
Slate predecessors
Boss2
The beginning of Slate can be traced back to a company that Jansy acquired, called BurgoPak. BurgoPak used an access app to track job numbers called Boss. It was simple and got the job done, but that job was only issuing job numbers.
The need for a more comprehensive project management system was obvious. So in the mid to late 2000s Boss2 was developed. It was was a php app developed using a home grown MVC framework. At the time these concepts were fairly new in the web development community, and open source frameworks hadn't reached maturity yet. At the time, developing frameworks such as Zend were considered. Even a port to GWT was considred, but was rejected. Transitioning from the built in framework and routing to another platform wern't considered time efficient.
Project management in Boss2 was rudimentary. It could track basic tasks as well as CRM type features with company and client contacts. It handled standard file uploads, but didn't provide version history.
For a small, developing company it was a large step up from excel documents on a server.
Selecta
After Boss2 had matured, the need arose for a client accessible asset managment system. Although Boss2 handled file uploads, version control was now needed. Additionally, the current system wasn't designed for client interaction. The privacy of corporate data was also a concern.
Selecta began development in the early 2010s. Selecta was developed using Django as a framework.
The feature set for Selecta was focused on version controlled assets that were sharable with clients. It had an integrated approval cycle system complete with client comments and annotations.
Selecta had a large impact in how the designers worked with clients.
Slate
After the success of Selecta, along with the continued productivity of Boss2, planning and development of a combined system started.
Building on the success of using Django as a development platform, and using the feature set of Boss2 as a base, Slate was officially born in late 2014.
Slate v1 (Legacy Slate)
Slate started by pulling the existing file management modules from Selecta. First was the creation of a group based permission system capable fo global and object level permissions. The first user facing module implemented with as a project management system. The code used in these core modules, though somewhat improved, can still be seen in the production deployment of slate today.
Along with development of a new system, the version of Slate was the first to switch to the SPA/Backend split. The frontend was based on AngularJS, and used the default bootstrap for styling.
Slate v2 (Polish)
After continued development had Slate functional and stable, attention was turned to aesthetics. Jansy had just refreshed it's website, and the look and feel of Slate followed. Custom bootstrap overrides were developed. Background techtures were added, along with better choice of fonts.
With this version of slate, the first implmentation of purchase order and invoice tracking were added. Until now project managers had been interfacing with accounting through spreadsheets via email. With data slipping through the cracks, and the difficulty in determening just which spreadsheet was the latest version, we moved these functions into Slate to give us better data tracking. More importantly, it eased the daily workload of the project managers and finance.
Another major module added later in this version is logistics. The first iteration came from a spreadsheet passed around between our logistics team and project managers. This continued the theme of streamlining the teamwork between different roles within Jansy.
Slate v3 (Salesforce Integration)
In approximately 2017 Jansy's sales director moved the sales staff to using Salesforce. As implementation of Salesforce progressed, integration of Slate and Salesforce began.
At this time the attempted implementation of Infor as an ERP failed. Realistically what Jansy was maily seeking from the project was an accounting package. There were only a small number peices of an ERP that wouldn't be covered between Slate and an actual accounting package. When Jansy implemented AccountingSeed, that brought with it integration through the existing Salesforce integration Slate had.
Development began filling the missing peices, and implementing the AccountingSeed integration.
Along with integration, many other modules were developed. We developed a formal RFQ system, complete with vendor logins in order to enter responses directly into our system. This allowed for better cost tracking and pricing. Eventually the RFQ module was discarded in favor of a freeform estimates module.
Many other major features were added to slate after the Salesforce integration that significantly improved the overall functionality of slate. During this stage in Slates development the focus of each module was often improving data access and reporting capabilities. Moving staff from spreadsheets hidden on laptops and dark corners of file servers, into something visibile to management and those who needed ready access to that data.
Slate v4 (Porting to Vue)
When AngularJS, the framework used for Slate's frontend, split at version 2.0, Slate remained on version 1.x. The new version required a major port, and needed significant work to move to the new version. It was simply not cost efficinet for a small dev team to move while the existing framework continued to function without issue.
Since the split, the development tooling required to build an AngularJS fronted has started showing it's age. The in browser devtools relys on an api that is deprecated, and will cease to function in early 2023.
Slate's actual code has also accumulated technical debt along the way. The core modules were origonally developed with early version of Django. The older modules especailly need a review and code review. Many parts of the existing modules can be abstracted into common code, reducing the time cost of developing new modules.
With these considerations we've begun the planning and prototyping of a major overhaul of Slate.
The backed of Slate doesn't required wholesale redevelopment. With the python portions of slate, we're mostly looking at a proverbial spring cleaning. Moving to using newly available syntactic sugar, and facilities that have become available in the packages we're already using.
The frontend of Slate poses a problem. Newer version of AngularJS are radically different. There is however a framework which thematically is similar to the orginal AngularJS. Ease of porting was a major part of why Vue was chosen as a new framework. Taking advantage of this famework change, we're also moving the langauge target from es2015 to es2018. Moving from AngularJS services to bare JS classes actually results in less code. Often our api models will be a list of field definitions and can depend on inheritence. The improved component system also has shown a better development experience.