“We made the buttons on the screen look so good you’ll want to lick them.” Steve Jobs
Long gone are the days of building software that simply had to 'work'. Today's users want software that is easy to understand, efficient to use, and that looks great! Our foremost goal for KRAD is to be a platform for creating application interfaces that meet this criteria, and are pointed to by users as something they want to use. Fortunately there are many great libraries we can build upon for the "out of the box" KRAD look and feel. In this post I'll talk about the work currently going on in this area.
Before discussing the new work though, a bit about the previous look and feel efforts (this 'walk through history', or in some cases we might say 'trail of tears' is becoming a pattern for our posts!). Initially we created a look and feel that was based mostly on the Kuali Student application, and one that was based on the KNS (which we call 'legacy'). The reason for building the 'legacy' theme was so applications could begin converting screens to KRAD, and not have a drastic change in appearance from their old screens (and once everything was converted the application could then get a face lift). The majority of the CSS was custom, although the FSS (Fluid Skinning System) was included by default and used to apply some global styling. It should also be noted styling for many of the widgets comes from jQuery UI or the widget library itself, which presents a challenge for global theming.
There have been a few major iterations on the CSS over the past two years. The latest of these efforts implemented a global naming standard for classes (uif-*). Each component provided by KRAD is configured with a style class (regardless of whether any theme takes advantage of that class), then additional classes can be added when using the component. In addition, an approach was taken to 'stack' CSS classes based on the component hierarchy (an approach similar to what jQuery UI does). This class stacking reduces the amount of style duplication.
To summarize what is going on here, basically the structure of the page and the applied classes is defined within the UIF metadata (yes all that XML that everyone loves to hate). So where does the actual visual treatment come in? Well that is loosely coupled with the structure by an object we call the View Theme. The view theme is a simple object containing a list of CSS file paths, script file paths, and image paths. In order words it holds the configuration for our static web assets.
The theme concept allows applications to all be built with KRAD but not necessarily all look the same (as was the case with the KNS framework). This is evident by the applications that have been built with KRAD so far: Kuali Student, MyPlan, and KRMS all look vastly different. It will also allow for implementors to alter the look and feel as necessary without modifying any of the core application code.
While we have been busy doing this work, many other exciting tools have sprung up (sidenote: trying to build a framework that is 'modern' is like trying to have the latest gadget. Remember the commercial with the guy driving home excited by the new top of line M400 TV he just bought, and then sees a sign advertising the new M500 model?). One such tool is called Bootstrap (http://twitter.github.io/bootstrap/). There are many appealing features of the Bootstrap library, but what attracts us the most is the opportunity to offload the creation and maintenance of CSS, with a result that looks awesome.
Bootstrap makes use of another cutting-edge tool named Less (http://lesscss.org/). Less is part of a class of tools (another is SaaS - http://sass-lang.com/) that boost the standard CSS language with some new features, such as variables and mixins. Using these two tools, visual designers (or developers) will be able to construct great looking applications with much less effort.
To support these new tools we will be redesigning how our view themes work, which I will briefly overview now.
First, the ViewTheme object itself (this is the object that is configured in the UIF XML and associated with one or more views) will require just one property to be configured, the theme name. This can be any name you would like, but should correspond to a directory under the web root 'themes' folder (example '/themes/kcTheme'):
From here the remaining necessary configuration will be derived by convention.
There is one other thing we need to do though, and that is prepare our theme for consumption. This will involve two, possibly three steps:
- Overlay assets from a parent theme (optional)
- Compile .less files to .css
- Build minified .css and .js
This work will be performed through the maven build process. A custom plug-in will do the work of overlaying, compiling the Less files, and building the minified files. In short, the functionality will be similar to the Asset Pipeline offered in rails (later on we could add support for such things as CoffeeScript as well).
Let's take a couple of examples to make this concept more clear. First, we'll create a completely new theme (meaning we will not reuse any files from an existing theme). Assume our theme directory is '/themes/kcTheme' (corresponding to the view theme configuration above), and has the following contents:
A real KRAD theme is likely to have many more files, but this will do for our example. You might be wondering the purpose of 'theme.properties'. This will hold the compile values for all the Less variables. After the build runs, our theme directory will contain the following two files (note the previously listed files will still be in the directory as well):
The kcTheme.min.css and kcTheme.min.js resources will then be linked to the view in a test or production instance. Notice the version tag added to each minified file. This ensures when a new version of an application is released, users automatically download the updated resources. In development mode, the individual files (less, css, js) will be linked to the view for debugging.
Now here's the cool part! Instead of creating a theme from scratch, we can inherit from another theme (for example extending the out of the box KRAD theme). Suppose now our theme directory simply contains:
And the first line of theme.properties contains 'parent=kcTheme'. This indicates which theme to inherit from. In this case we want to inherit from 'kcTheme'. The theme.properties file from this directory will override the theme.properties file from the inherited theme. If the original theme makes good use of variables (as the out of the box theme will), the actual styles (colors, fonts, padding) can be altered in this way.
We can also add files to the inherited theme, or override any file from the original theme (including images) by including a file with the same name:
This would override the 'layouts.less' file and 'logo.png' image from the inherited theme, along with adding the asset 'additionalStyles.css'.
Finally, since really the theme is created from the final directory contents, we can take advantage of WAR overlays to customize an out of the box theme without creating a new theme. For example, to modify the content for the out of the box KRAD theme, we create the folder '/themes/krad' in our web project and then place any of the files we wish to override.
For those of you ready to beautify, lessify, and simplify your themes, the work should be completed for the Rice 2.3 release.
Next time I will discuss a variety of topics, as I take on 'Top Questions (aka Criticisms) Regarding KRAD'.