The next time you see a railroad engineer at the controls of a freight train, a technician adjusting an MRI machine, or an aircraft mechanic examining a jet engine, consider: something in this process used class="span12".
You may be familiar with GE as the logo you study on your microwave oven as it reheats a cup of coffee. The company founded as General Electric (GE) has spent a long time manufacturing appliances that transformed everyday life.
That trendy Edison bulb in your local hipster bar? GE started making this mood lighting well over a century ago. What you probably haven't noticed, though, are the myriad GE products working to connect sensors, gauges, transmitters and nodes to the 'Industrial Internet'; the typically unseen community of machines that share data to create unsurpassed power and efficiency. Rather than eliminating human operators, these devices demand more from them to provide yet more data, more capacity for analysis and more opportunity for communication. These operators have an urgent need for reliable, effective, and coherent user interfaces.
Design challenge
Thousands of software developers, hundreds of use cases, an uncountable number of combinations of interface elements: these were the challenges we faced at GE Global Research as we built design systems for our products. We wanted to offer presentation layers that any GE developer could use in an application, and extend for other developers.
Where would you start with this kind of challenge? How about with Twitter Bootstrap?
Twitter Bootstrap offered a reliable base of HTML, CSS, JavaScript, and, crucially, documentation for frontend development work. Many of our design system users would have some familiarity with this framework, and we relished cutting out many hours of writing and testing our own frontend components. However, we did indeed end up developing ge-bootstrap, a layer of modifications we made to support GE applications. Here's what we discovered.
The power of LESS
One of our project goals was to create interchangeable modules of frontend assets that could be incorporated into any GE application. One strict requirement was theming; our application developers needed an easy way to change colours and fonts. We took a hint from Bootstrap's reliance on the LESS CSS preprocessor, and developed our own counterpart to Bootstrap's variables.less file.
Rules that established colour values or font sizes in our design systems originated in this file. As much as possible, the LESS/CSS rules defined in each design system component referred only to variables and never to font sizes, line heights, or colour values directly.
When a component needed to override a variable, its own variables.less file would establish the new value.
For instance, Twitter Bootstrap defines @black as #000000 in its variables.less file:
@black: #000;
The Brandkit component redefines @black to a slightly less stark value in its own variables.less value:
@black: #13161a
A design system component with need for a yet more muted @black to complement a brighter colour palette could its own variables.less file for this effect:
@black: #262626;
Every interface element that is 'black' in Twitter Bootstrap is a rather dark grey in a design system that uses this last component. All we had to do was change the value of one variable.
The power of Bower and Grunt
We had seemingly contradictory requirements: ge-bootstrap needed to be both a drop-in framework, taking care of most visual design needs, and also a collection of separable parts from which developers could choose.
To that end we relied on the Bower package manager and the Grunt task runner to assemble components into a design system. Each component includes a bower.json file that lists dependencies and a Gruntfile.js that installs them, among other tasks.
Below is the bower.json file for one of our components. main defines this component's endpoints. The ignore block instructs Bower and Grunt which files to skip over for installation. dependencies can be pulled from any repository Bower can reach with Git; we used some packages from GitHub, and others stored on an internal Stash environment.
{
"name": "datagrids",
"description": "Implementation of DataTables for GE Design Systems.",
"version": "0.2.5",
"main": [
"js/datagrids.js",
"less/datagrids.less"
],
"ignore": [
"components",
"css",
"node_modules",
"test",
".*",
"Gruntfile.js"
],
"dependencies": {
"ge-bootstrap": "...",
"jquery": "..."
}
}
Our long-term plan was to require developers to install only Node.js, Bower, and Grunt - each a single-line command at the console - to get working with our files, which we wanted to distribute via Git from GE's Stash repository. At launch we offered a compiled .zip download, anticipating that many users would be content to use the design systems without modification.
The Grunt JavaScript task runner proved invaluable. We used Grunt tasks to install dependencies, compile LESS into CSS, and even to build distributions. None of our users would have to edit a configuration file. One Gruntfile.js, run at the console with the memorable command grunt, handled this. Of the Grunt plug-ins available, the following proved the most essential:
How to make it extensible
While developing ge-bootstrap, we had to remember that our users, GE's software developers, would want to add their own components: specialised charts, animations, blog formats, interesting HTML5 experiments. We also wanted to make these components shareable across GE; every developer should be able to add a single line to his local instance of bower.json to pull this code into his project. We devised a set of templates for components to deliver as just another repo in Stash. When a GE developer builds a component to share with the rest of us, our plan is that all they have to do is verify it conforms to our component format, and push the code to Stash. Bower and Grunt handle the rest.
How to make it customisable
At present, we offer the design systems as all-or-nothing: we don't have the equivalent of Twitter Bootstrap's Customize form. Savvy users can, of course, examine the files to delete paths to the assets they don't want, but most developers will prefer to focus on their other project demands. Developing a user-friendly way to offer slimmer builds of the design systems is among our next issues to handle. We'll take much inspiration from how Twitter Bootstrap handles this matter.
At this time we're anticipating the launch of Bootstrap 3 with both excitement and dread. While Bootstrap 3's 'mobile first' direction will support many of our project requirements, it will also demand drastic revision of our markup and LESS. It'll be a great test of how modular we've made our design systems.
Even so, it doesn't look like the absence of .span* rules or IE7 support threatens catastrophe. GE products developed with our design systems will still function. Trains will still run, MRI machines will still scan, planes will still fly, and you'll still be able to reheat your coffee.
Light bulb image by achichi, licensed under Creative Commons
Melanie Archer is a web developer specialising in CSS, HTML5, jQuery and Rails.
