Component Library
A custom component library decreases design and development time
UI components and their underlying architecture were unsustainable for developers and caused problems for customers
Developers
The existing HTML/CSS architecture supporting the UI components in Jaspersoft's business intelligence application had become problematic. The CSS relied on heavy use of cascading, resulting in a fragile UI with a vast number of components that were context-sensitive. Additionally, some developers weren't using the system properly. They would recreate components and styles instead of using those that already existed. The result was code duplication and an overabundance of one-off styles that undermined the utility of a systemized architecture and component set.
Customers
A significant portion of our customer base would embed our application directly into their own applications. Our CSS used common classnames like .button or .tab that were likely to clash with a customer application's CSS. We were getting complaints about broken UIs caused by conflicting classnames.
Developer resources were already spread thin
First, the engineering team was small, and all developers were already committed to important projects. Only one client team developer was designated to work on this project, and this was not his only project.
Second, when the components were complete we'd need to implement the them in our application incrementally. This meant they had to resemble the look and feel of our existing UI, with the long-term goal of updating the look and feel more easily in the future.
We would rebuild our components using an improved CSS architecture
We defined a three specific goals:
- Components must be stand-alone elements that can be used anywhere in our application
- CSS class names must have a logical structure
- Components embedded into other applications won't be affected by the parent application's CSS
Audit the Existing UI
The first step was to do a component audit of the application. It was important to identify all components used in the UI, their usage patterns, inconsistencies, and specific requirements for any given component.
Select technologies
The development and UX teams decided to make two significant changes that would positively impact our workflow.
Start using a CSS preprocessor
We evaluated both LESS and Sass, choosing Sass for compatibility purposes.
Create our own iconfont and graphics
We had recently been acquired, and getting approval from legal whenever we needed a new third-party graphic was a slow and inefficient process. We decided to create our own glyph icons and generate them into a webfont. Grunt, a JavaScript task runner, would be used for this.
For multi-colored graphics, we would create them ourselves and compile them into sprites images.
Define CSS naming rules
This was the most critical part of the project. Getting it right would directly address the issues our existing system was causing for developers and customers.
I researched various naming conventions, involving developers in the process. Between engineering and UX we decided on a naming convention that was a hybrid of two different methodologies: SMACSS (Scalable and Modular Architecture for CSS) and BEM (Block, Element, Modifier).
We also decided to add the prefix "jr-" to all classnames, as well as adding the stand-along classname "jr" to all components. For customers that embed our application into their own, the unique prefix and additional classname would prevent conflicts between our classnames and the host application classnames.
Create the foundational elements
It was finally time to start designing and building the CSS architecture. We started with the basics: colors, typography, and icons. The company that had recently acquired us had a style guide with a large selection of colors. We chose a limited number of colors from this large color palette.
Build Components
With the basics defined, we could build the actual static components. We started with the fundamental components such as buttons, dialog boxes, menus, messages, and tabs. The markup for each component was reviewed and iterated upon before being approved by development.
New components were used in the release of a redesigned feature
The product team was working on a redesign of the Domain Desgner, a data modeling tool in our application. Since we were starting with a clean slate design-wise, it was decided that we would use all new component in this project.
Other Team Members
- 1 Developer
My Contributions
- Designed all components
- Wrote HTML and CSS