Setting up a workflow seems to be a fragile process. It typically starts off orderly, but then becomes more chaotic as the ideal meets the real — deadlines, choices about the wireframing and prototyping environment, limitations of deployment methodology, etc. all contributing to the urge/need to cut a corner and just get it done. I can’t claim this won’t happen again, but I hope by documenting it up front, it might increase my commitment to this particular workflow.
The LibGuides 2 platform provides Bootstrap-syntax classes for various elements on the page. This includes the overarching grid layout system that allows you to place content boxes in columns within the page container, as well as navigation, header and footer elements, various buttons, tabs, labels, badges, thumbnails, and more. But if you want your site to follow the style guidelines of your organization, you are going to have to modify the the generic styles that come with Bootstrap out-of-the-box.
That’s where the sourcecode version of Bootstrap comes in. Bootstrap’s stylesheet is actually compiled from a folder of about 40 stylesheet components written in Less, a CSS preprocessor language. The big win for CSS preprocessing languages is that they extend CSS by providing additional functionality like variables, mixins, and functions that make it possible to modularize and reuse your code, but compile a single stylesheet as the final product.
In an earlier post, I noted that the design comps for the LMC College website identified 7 colors of green and 2 colors of gold.
See the Pen LMC Color Palette by Tom Keays (@tomkeays) on CodePen
Rather than trying to remember that “#009161” is the primary color of green used for links and the background color of certain boxes, I instead assigned it to a Less variable of “@lmc-green-3”. Down the road, if I need to change that color, I just need to change the value assigned to the variable.
Here’s the color palette that the LMC website will be using.
@lmc-green-1: #00c483; // #00c483: lightest: background, links @lmc-green-2: darken(@lmc-green-1, 5%); // #00ab72: background, text @lmc-green-3: darken(@lmc-green-1, 10%); // #009161: background, primary green link @lmc-green-4: darken(@lmc-green-1, 15%); // #007850: background, gift box, dolphin @lmc-green-5: darken(@lmc-green-1, 19.9%); // #005f3f: background, bars, primary green link hover @lmc-green-6: darken(@lmc-green-1, 25%); // #00452e: background, super navbar @lmc-green-7: darken(@lmc-green-1, 27.5%); // #003825: darkest: background, search field @lmc-gold-primary: #cfb57e; // #cfb57e: primary gold, buttons, links @lmc-gold-secondary: #ddb253; // #ddb253: secondary gold, small arrows
There are other CSS preprocessor language choices besides Less. SASS is the most popular of these (and the language I actually prefer) and, while it is now possible to use SASS with Bootstrap, all of the documentation still references Less. Less is not terribly complicated and Bootstrap doesn’t use many of its trickier features, so I figured sticking with Less was the best path to follow. Hopefully, I won’t regret that decision down the road.
I mentioned that Bootstrap’s Less source code is broken apart into 40 or so smaller files. These have names like “buttons.less”, “dropdowns.less”, “forms.less”, “navbar.less”, and “tables.less” which define the appearance of various page elements. There are also files such as “mixins.less” and “variables.less” which define functions and variables that will be reused by the other modules. Changes you make in the appropriate Less modules are compiled by the Less framework and reflected in the final CSS stylesheet.
However, the recommended best practice is to avoid directly editing the Less files that come with Bootstrap.and, instead, create a separate Less file with your changes that will be applied on top of the default Bootstrap files. In this new file, you can reassign variables, create new mixins and functionality, and assign different style attributes to page elements and Bootstrap classes, without the risk of seeing your work wiped out the next time you download the newest version of Bootstrap.
For instance, I would not change the value of the primary brand color assigned in the “variables.less” Bootstrap file. By default, this variable is defined:
Instead, I would create a new folder next to the default bootstrap folder which contains a new “variables.less” file that redefines the variable the way I want it: E.G.,
Then, by importing my “variable.less” file after the original, my definition of the brand color will overwrite and replace the original. My compiled CSS will reference the color as I defined it.
CodeKit / Prepros
However, at work, I use a Windows machine where CodeKit is not an option. Fortunately, in the past year a viable alternative came along. Propros, originally for Windows but now running on Mac OS and Linux, is not quite as versatile as the industry standard CodeKit, but it handles Less preprocessing just fine.
When you start a project, Propros makes an inventory of all the files. If it sees a folder of Less files, it analyzes them to see if one of them is the master file for the project — i.e., if it sees that Less file imports another file or set of files, then it won’t compile the subordinate files to CSS, but will only compile the master file. It is also possible to manually determine which files Propros with compile and which it will ignore. Prepros watches for changes to the project files and automatically compiles changes as you go. Prepros can also provide a web server environment that will refresh the page to display the style changes you have made.
Coding is an iterative process. As you try things out to see what works and doesn’t work, it is nice to have a way to document the changes you have made and to rollback to an earlier version when things don’t quite pan out. Git is the latest in a long line of version (or revision) control programs. It gained acceptance with programmers and coders because of its distributed way of sharing the coding work among members of project teams and solidified its dominance because of the popularity of the social coding repository, GitHub, which gives every coder in the world a place to save, share, and showcase their work.
I’m saving the code for this redesign project at https://github.com/tomkeays/prototype. I have installed Git on my work computer so I can commit incremental changes back to the GitHub repository. While the public repository, strictly speaking, is not necessary (I could use Git entirely locally on my work machine), by committing changes to the GitHub repo, I am able to pull those changes down to my home computer and continue my work there (in effect, collaborating with myself).
The public repository also makes it possible to communicate my work to others, should anybody be interested. For example, over the weekend, I experimented with LibGuide 2’s templates. I liked the sidebar template that LibGuides provided better than the typical tabbed template that is a carryover from LibGuides 1. However, I did not like the clunky look of the “pill” buttons and I was disappointed that there was no way for there to be more than one content column. I realized that while I couldn’t override LIbGuides and enable the sidebar template to specify 2 columns to display content, there was a way to explicitly place the guide owner’s profile box in a second column. Because the profile box is not optimized for wide columns, I made its containing column narrower and improved the overall look of the page for both desktop and tablet screen resolutions. If anybody were to ask how I set up this template, it is a now simple matter to refer them back to this repo.
However, when I work from home, I don’t have direct access to files on my work website. To keep everything in sync, I pull files to my home computer from my GitHub repository, so I don’t want to simply FTP changes back to my work website. That would cause the repository on my work machine to differ from both the home machine repo and the GitHub repo. Instead, I take advantage of the fact that LibGuides has its own document store in its Assets library and upload “main.css” there. I then just have to point LibGuides to that file in the docstore. It doesn’t have immediate gratification aspect of the other solution, but it has more versatility.