In the blog post "Yes We Kanban" by Katie Wilkes, she talked about using a Kanban method to handle the day-to-day ticket management process. In order to facilitate this approach, we needed to create a custom online application that supported the requirements or “rules” we set for this process.
It was Katie’s job to dream up the idea. It was my job to bring the idea to life. Below I will unpack the build steps taken to create The C2 Group Kanban tool.
The landscape of front-end development has shifted over the years. Even though standards have limited browser rendering discrepancies, developing has never been more complex. This is mostly due to websites being consumed by all kinds of new devices with new capabilities. In an effort to make our code less complex and more maintainable, we've attempted to shift some of the responsibility to the computer. In front-end development, we've added a build step to our process.
The Kanban UI uses a build process powered by NPM and Ruby to keep the code clean and organized. These build steps add complexity to the project but simplicity to the code. Let's take a look at some of the tools that are used.
<p> CODE: https://gist.github.com/thec2group-blog/f298577a5192aecd35f76abb6990b084.js</p>
Adding specific vendor prefixes in CSS is time consuming and difficult to maintain. Autoprefixer adds only the vendor prefixes that are necessary by using data from caniuse.com.
<p> CODE: https://gist.github.com/thec2group-blog/94db424815e2c3e22258782982737c9a.js</p>
The same CSS converted with Autoprefixer to support various browsers:
<p> CODE: https://gist.github.com/thec2group-blog/0bfed3490941e0eb6c36203719412a08.js</p>
REM units allow that value to be manipulated by the browsers root font size. By changing the font size preference in the browser settings, any REM unit will be calculated off that font size choice. However, REM units are less readable in the code because the value usually requires a decimal. For simplicity, it is easier to write the code using PX units, then converting the code to REM with Pxtorem.
This is an example of CSS that has been converted by Pxtorem. The original PX declaration are left in as a fallback for browsers that do not support REM:
<p> CODE: https://gist.github.com/thec2group-blog/59ec2ee50f6edde38c018fe01b23b216.js</p>
This CSS build step has allowed our source files to not get bloated by code that only browsers need to see (not humans).
A CSS pre-processor that offers imports, mixins, nesting and variables. Sass is a must have for any of our projects.
Sass runs on Ruby which can be a bummer. First, Ruby is an additional thing to install. Secondly, we keep this separate from our Gulp file which only runs our NodeJS code. In the future, we may involve LibSass in an attempt to consolidate our build steps.
<p> CODE: https://gist.github.com/thec2group-blog/f302800b5f57abd34faabcf17c2066f2.js</p>
This file has one dependency, jQuery, which is "required" at the top. The variable "cache" is not added to the global namespace but is contained to the scope of this file and is persistent no matter how many times this file is "required". When this file is "required" in another file, the value that is saved asmodule.exports will be imported into that file through the required statement. In this case, a function.
The feature that we enjoy the most about Browserify is sanity (that's not really a feature, I'm being facetious). The style of importing and exporting encourages you to write many small reusable modules that can be shared throughout the project. Smaller also means more readable and maintainable, which provides sanity.
As you can see, a lot of thought and time has went into creating this Kanban tool. It vastly improved The C2 Group workflow in a matter of months. If you'd like to learn more about the Kanban tool and how it can be adapted to your process, contact us below.