Front End Design at the College

Frontend development continues to expand as a percentage of project coding to the point that some of our products, such as the clinical applications, are 100% frontend code. Over the past year, I have been putting work together to support a massive shift in how we do frontend and, in the long run, how we develop, support, and release our college software solutions. 

The most significant issue I continually see in IT is decentralized coding efforts. Decentralization leads to repetitive solutions, inconsistent behaviors, extended regression testing, bloated packages, complicated deployments, and potential code errors as we try to make security patches or upgrades.  

Focusing on improving how we execute frontend for the college and not just for a project, I have tackled four pillars.  

  1. Unification of design but building for flexibility
  2. Shifting to the CFD (component first development )
  3. Creating documentation that is utilized and not just ignored
  4. Centralizing everything for everyone

The unification of design was the first place I started. "Arches" is the current solution that enforces a Design Opps procedure to streamline requests and deliver a college-wide design system. This design system has two tenants. First, it can replicate its styles influenced by the brand and frameworks from its product space. It now covers QII, ACC, Cardiosmart, and Mobile and can be further scaled. Second is its utility framework that ensures a highly flexible practice to allow countless UI permutations without CSS mutations. Utility styling is also known as "scopeless" styling because you can build out many UI patterns without ever altering the original styles.   

Shifting to CFD (component first development) embraces an architecture for our frontend products and alters how we develop. CFD, as a pattern, has been around since 2012 with bootstrap. In its infancy, CFD could only capture minor token UI. Still, with the introduction of javascript models like Web Components, React, Vue CFD can now capture business logic, complicated interface interactions, and data mutations. Vue has been my primary focus as it builds on the collective knowledge of the department. Vue has the capabilities to make obsolete Jquery UI, Pager, Knockout, Angular, JqueryMobile, and many other libraries that are currently in use. IT streamlining to a single dependency allows for universal software patching for frontend security issues. 

Currently, we are creating documentation that is utilized and not just ignored. As we shift to CFD, we can use Storybook which allows for documentation around a living singular component with artificial data. This type of documentation gives a single point of Design, Development, and QA. The effort on a single element can be attached to countless projects through version control. Centralized development and QA can give us a feasible path to automated unit testing and regression testing. As new projects come online, utilizing the global-version-controlled components would benefit from standards, consistency, and quality control. Preliminary work done with Storybook around a future product under the ACC.org "Home Page Redesign." Projects could include the transcript, CSTool, GL Search, Coveo Search, and FIT Management.

Vue 3 component for all new work
https://assets.acc.org/papercrane/Latest/docs/

Centralizing everything for everyone. I have conversations GM, Josh G, and Micheal M, and the great work of Ling C on creating a path forward with using assets.acc.org and also moving the newly used submodule features from GIT within current and future products. Submodules empower the component work to be checked in and out from both the centralized-version-control and from projects, these efforts can be kept in sync. The vision for this project is to be controlled by ACC but utilizable by vendors.