Thursday, June 5, 2014

Rice Scrum

Hi Everyone! It has been quite awhile since we have posted an entry so I wanted to give an update. Things have been very busy, and there is a lot I could talk about. But I have decided to focus on two topics for the next few entries. Both can be summarized as 'Great Change'! The first deals with change within the team and our process. The second is change with the product itself (KRAD Architecture). As always I look forward to any feedback you have.

On the outside, things look like business as usual. We are working on a patch release of 2.4 (2.4.2), and our next minor version 2.5 which will contain loads of nice improvements. Internally though, there are exciting discussions and planning occurring to improve our value to the community (in other words, to deliver more often and with better quality). You have probably guessed by now this has something to do with Agile methodology, and you would be correct! More specifically, we are working towards implementing Scrum.

Within Kuali, we have always stated we follow agile methodology. Furthermore, on the Rice team we have implemented some Scrum practices already (daily stand-ups, sprints, and sprint planning). While these things have provided value, by not following the full practice we are not giving ourselves a chance to realize its real value: creating high performance teams. In addition to this, Scrum requires not just a process change, but a culture change. Before many of us (including myself) did not really understand the underlying goals of these practices. Fortunately, the Rice team was able to attend Scrum Master training ( at the recent Kuali Spring Workshop. This had a huge impact on the team. We now understand the goals behind the Scrum practices and the various Scrum roles. In other words, we understand the why!

We have a lot of work left to define what this all means for Rice, and how we get there. However, there are a few changes I would like to go ahead and mention. These are ones the team feels strongly about and that I think will have the largest impact on the community.

Product Owner(s)

Who sets the priorities for Rice? Who drives a vision? These are very complicated questions to answer currently. It is some (messy) combination of the ARC (Application Roadmap Committee), several smaller committees, project managers, team members, and likely others. In a Scrum team, these responsibilities fall to a single product owner (note this is per team, a project could have multiple teams). The product owner works with all stakeholders to collect and prioritize work. They protect the Scrum team from this 'noise', allowing them to focus on delivering. For more on the product owner role, see Scrum Product Owner.

On the Rice team, we have an incredible amount of 'noise'. Not only do we have a huge code stack to support (and multiple versions), we have multiple stakeholders with many different needs, and we provide support for the wider community. For any given release, I would estimate the amount of work we end up putting into that release is at least 3 times more than the 'planned items'. Many of these efforts go unnoticed, causing the community to only see a missed release date. The product owner will help greatly to make these items visible, and the team can stay focused on the highest priority items.

Definition of Done

Quality vs. Quantity. When a project is in survival mode (always putting out fires, behind schedule, attempting to implement all stakeholder high priorities at once, etc.), quality is often sacrificed for quantity. This might get the team short term praise for appearing to get a great amount of work done in a short period, but will come back to haunt in a big way. In fact, after years of quantity over quality, the project can get to an almost standstill point, and be a candidate for garbage collection. Before it gets to that point, there is vicious cycle. While trying to deliver new functionality, the team is also putting just as much effort 'patching' older versions. This could involve making the functionality work like it was intended to in the first place, or resolving regression issues. This puts the new functionality behind schedule, and pressure to deliver causes the same shortcuts to be taken.

This is where the promise of 'Definition of Done' comes in. It's about setting a line in the sand: We will not trade future quality for quantity. Our team feels quality includes these things (ex. user stories, unit/integration tests, AFTs, documentation, etc.) and new functionality will not be accepted (or considered done) unless it meets this criteria. Sticking to this takes a big commitment from the entire team, but it is the only way to break the cycle. It also takes honesty from the team to consider where things are at, and not continue to over promise or be overly optimistic. The product owner then has the information to correctly set expectations with stakeholders.

Deliver more Often

Wait, deliver more often? Didn't I just talk about the need to put quality over quantity? It turns out, by focusing on quality (and done) you end up getting both: better quality and more quantity.

First, if the items you are delivering are 'done', you will be spending less time 'patching'. So the time that was allocated for new work, can truly be spent on new work. Next, by requiring an item to be done, and limiting the amount of work in process (small batches), you can release more often. Instead of waiting 6 months to a year for any new functionality, customers can get quality releases monthly, or even sooner (in fact, many great teams are now achieving continuous delivery).

Focus on the Customer

All of this change steams from an increased focus on the customer. Besides the items outlined above, there are many other pieces of Scrum that will help in this area. For example, Sprint demos will allow us to verify new functionality with stakeholders sooner, eliminating potential waste. The product owner will help bring transparency, allowing the stakeholders to make better business decisions. Most importantly, our team will gain trust from the community by delivering quality product.

The motivation to make these changes is a great step in my opinion. Of course, the hard part (implementing) is yet to come. Furthermore, Scrum is not a magic bullet. Becoming a high performance team involves many aspects. Personally, I have been on a journey exploring other methodologies and practices to help our team. This includes XP, Lean Methodology, and other leadership practices. In the next entry ("Notes to a Software Team Leader") I will discuss these more.

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

Sunday, March 2, 2014

KRAD Training - April 14th - 18th

Training ​including ​the ​newest ​KRAD ​features, ​attend ​onsite ​or ​online, ​and ​super ​discounted ​rates! 

Training ​on ​the ​most ​current ​version ​of ​the ​Kuali ​Rice ​development ​framework ​KRAD! ​Training ​will ​cover ​all ​you ​need ​to ​know ​to ​start ​building ​great ​applications ​today, ​and ​support/implement ​migration ​processes ​in ​your ​current ​Rice ​applications. 

Kuali ​Rapid ​Application ​Development ​(KRAD) ​is ​a ​software ​development ​framework ​for ​building ​enterprise ​web ​applications. ​KRAD ​provides ​many ​useful ​features ​and ​helps ​greatly ​with ​building ​rich ​modern ​user ​interfaces. ​KRAD ​provides ​solutions ​to ​common ​technical ​problems ​such ​as ​a ​quickly ​building ​UIs, ​accessibility, ​security, ​CRUD ​operations ​(searching and ​maintaining), ​integration ​with ​identity ​management, ​and ​workflow! 

Register Now:

Who ​should ​attend? 

  • ​Developers ​who ​have ​worked ​with ​the ​Rice ​KNS ​module ​and ​wish ​to ​learn ​about ​the ​new ​KRAD ​framework ​for ​converting ​previous ​apps ​or ​writing ​new ​apps 
  • ​Developers ​who ​are ​looking ​into ​using ​Rice ​and ​are ​interested ​in ​what ​features ​the ​KRAD ​module ​provides 
  • Developers ​who ​have ​been ​working ​with ​KRAD ​but ​wish ​to ​deepen ​their ​knowledge 

What ​will ​the ​training ​cover? 

  • Overview ​of ​KRAD 
  • Overview ​of ​the ​UIF 
  • Types ​of ​Components 
  • Building ​Pages 
  • Adding ​Rich ​Behavior 
  • Spring ​EL 
  • Lookups ​and ​Inquiries 
  • Maintenance ​and ​Transactional ​Documents 
  • Using ​jQuery ​and ​Styling 

What ​skills ​are ​needed? 

Attendees ​should ​have ​experience ​with: 
  • General ​web ​application ​development ​(including 
  • HTML/CSS/JavaScript) 
  • J2EE ​Programming, ​including ​Servlets, ​JSP ​and 
  • JSTL, ​MVC ​Patterns 
  • An ​IDE ​such ​as ​Eclipse ​or ​Intellij 
  • XML 
  • Working ​with ​a ​MySQL ​database 
In ​addition, ​the ​following ​are ​recommended ​to ​get ​the ​most ​out ​of ​the ​training: ​Experience ​with ​the ​Rice ​KNS ​module, ​JSTL, ​Spring ​Beans, ​Spring ​MVC, ​and ​jQuery. 

Who ​will ​be ​giving ​the ​training? 

Jerry ​Neal ​is ​a ​Senior ​Developer ​for ​Indiana ​University ​working ​in ​Enterprise ​Software ​development. ​Over ​the ​past ​8 ​years ​he ​has ​worked ​with ​the ​Kuali ​project ​as ​a ​developer ​and ​development ​manager. ​Currently ​he ​is ​the ​lead ​architect ​for ​the ​Rice ​KRAD ​module. 

How ​can ​I ​attend ​the ​training? 

The ​recommended ​way ​of ​attending ​the ​training ​is ​onsite. ​Training ​will ​be ​held ​in ​Bloomington, ​IN ​at ​the ​new ​Cyberinfrastructure ​building ​( ​You ​may ​also ​attend ​the ​training ​online. ​Video ​from ​the ​training ​will ​be ​streamed ​and ​online ​attendees ​may ​interact ​with ​the ​instructor ​through ​online ​video. ​ 

Register Now:

Monday, December 9, 2013

Unified Kuali Processes

Thought I would take a moment to expand on a Kuali technical item that very recently arrived at a pretty cool milestone.

As of last week there are five Kuali projects (KS, Rice, Mobility, KPME and OLE) that all inherit from the exact same version of the latest top level Kuali pom (version 3.3.36)

Tops among the various benefits this provides is consistency, transparency, and simplicity for a number of critical software development processes.


Building any one of these five projects is done the same way as all of the others, and is one simple command:
$ mvn clean install
Any Kuali developer familiar with checking out and building any one of those projects, will be inherently familiar with how to do so for all of them. Any java developer (including the vast numbers of developers external to Kuali) familiar with Maven will also be able to easily complete a checkout and build. This can typically happen without them needing to speak to someone at Kuali or otherwise requiring extra assistance.

Given the community source model under which Kuali software is produced this is an invaluable asset in terms of enabling the extended global community to engage with Kuali projects and provide feedback. Since every ounce of friction removed from the build process is multiplied across all developers (both internal and external) this has a very positive cumulative affect over time.


Public copies of the project's software are automatically published and conform to a well known and documented standard.

Every project declares a globally unique identifier for every binary it produces.  In Maven parlance this is GroupId + ArtifactId + Version, aka "GAV". The identifying information gets automatically baked into the filename of every binary without exception.

Those binaries are then posted to Kuali's public internal repository and (at the project's discretion) to a globally accessible public repository that hosts them for free. This makes them automatically accessible to anyone, anywhere, at no cost to Kuali.

This is only possible because all five projects adhere to a few simple non-negotiable rules critical to keeping the worldwide public exchange of open source software organized and cohesive.


Technical information is automatically generated including javadocs that always exactly match the corresponding code.

The latest Kuali branded versions of these are at:  StudentRiceKPMEMobility, OLE
All content is versioned and permanently published to Amazon's content delivery network (CloudFront).

This enables:
  • High speed browsing (everything is cached to 31 different edge locations around the world)
  • Guarantees the content is always available
  • Is extremely low cost
Kuali's CloudFront costs for the month of November '13 totalled $4.07.  This represented 600,000 requests and 30 gigabytes of network traffic.  Interest in the content originated from around the globe and was serviced by Amazon data centers in Virgina, Ireland, Tokyo, Singapore, Australia, and Brazil.

There are any number of other benefits to having all five project teams use a shared top level Maven pom.  Economies of scale is one, (fixing or upgrading something in one spot benefits all five project teams simultaneously).

I've chosen to highlight these three since they:
  • Directly impact day-to-day development in a positive way
  • Demonstrate the pro-active steps Kuali is taking to be a good steward of the open source technologies it produces in a cost conscious way
  • Represent fundamental software engineering processes that have been abstracted out in a unified way for all five projects teams

Jeff Caddel
Director of Development Operations
The Kuali Foundation Inc

Friday, November 15, 2013

Kuali Days 2013

It's that time of year! Kuali Days 2013, our yearly extravaganza, will shortly be upon us. The Kuali Days conference is jam packed with informational sessions that range from project overviews for rookies, to new feature demos for veterans. This year Kuali Days will be held in San Deigo, CA, and has expanded to three days. For more information on conference logistics, see Kuali Days 2013.

As always, the Rice team and community has prepared many great sessions about the Rice project. In this post I will highlight some of these, and let you know of some other sessions I am looking forward to.

For Rookies

For those who will be attending Kuali Days for the first time, or are new to the Rice project, here are the introductory sessions.

Monday (Pre-Conference Workshop) 8:30 AM - 12:00 PM

Kuali Rice Installfest: Computer Setup for Rice Application Development 
Monday (Pre-Conference Workshop) 1:00 PM - 4:30 PM

Tuesday 8:45 AM - 9:30 AM

Tuesday 11:45 AM - 12:30 PM
This is one of two sessions I will be co-presenting on with Brian Smith. A good general overview of KRAD for those who are looking at the framework for the first time.
Tuesday 3:15 PM - 4:00 PM

Wednesday 11:00 AM - 11:45 AM

Thursday 9:45 AM - 10:30 AM

This session will overview the new KRAD data framework. Those who have been following the posts know this is a module we are very excited about. Learn about all the features this framework will provide, and the potential it has for bringing new data technologies into Kuali.

For Everyone

For those new and old to Rice, here are sessions that may be of interest.

Tuesday 2:00 PM - 2:45 PM

Tuesday 2:00 PM - 2:45 PM

Tuesday 3:15 PM - 4:00 PM

Tuesday 4:15 PM - 5:00 PM

Tuesday 4:15 PM - 5:00 PM

Wednesday 8:45 AM - 9:30 AM

Wednesday 1:15 PM - 2:00 PM

Wednesday 2:15 PM - 3:00 PM

This is the second session I will be co-presenting on. We will update you on all the new functionality that has been implemented in KRAD over the past year. Will include demos, and a look ahead to 2014 development efforts.

Thursday 8:45 AM - 9:30 AM

Thursday 8:45 AM - 9:30 AM

Thursday 11:00 AM - 11:45 AM

See the new data framework in action! In this session, you will see how the metadata abilities of the data framework can help you build KRAD views quickly.

Others of Interest (To Me)

Finally, for what it's worth, here are some other sessions I am most interested in. It goes without saying that there are many great sessions to attend, many of which I have seen in the past and greatly enjoyed. You might notice a theme in my selection for this year. I of course am interested in other efforts that relate to KRAD, and in general those concerning the future direction of Rice and Kuali.

 Wednesday 8:45 AM - 9:30 AM

Rice will be making the move to Git early next year. I am interested in learning what University of Arizona has learned from their migration.

Tuesday 9:45 AM - 11:15 AM

Tuesday 11:45 AM - 12:30 PM

Tuesday 2:00 PM - 2:45 PM

Wednesday 1:15 PM - 2:00 PM

Our direction for KRAD includes moving away from targeting portal deployments. Some of the work done so far includes building a standard application header for Kuali products, that includes application navigation and common workflow items. However, there is still a need for a 'launching pad'. IU is doing some great work in this area, which could serve as a basis for our KRAD implementation. Come to this session to learn more about what IU has done for their portal replacement.

Wednesday 1:15 PM - 2:00 PM

The bulk of my Kuali Days preparations has been for this session. You will see some of the early UXI design work, and its implementation in KRAD. There will be a demo of the KC proposal using the new look and feel, and using many new Bootstrap components.

For a full listing of sessions visit Also, make sure to grab one of the Rice brochures that will be available at the registration booth and many of the Rice sessions.

Hope everyone has a great time, and gain information that will useful for your own Kuali effort!

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

Friday, August 30, 2013

2.3 Baked, 2.4 In The Oven!

As of August 9th, 2013, Rice version 2.3 is now available to the public! This release includes several new features and improvements to KRAD. In this post, I will highlight some of these, and look ahead to the 2.4 release scheduled for early 2014.

Unified Header

Unified header gives you the ability to pack lots of useful information into your view header. You can combine the page text, add two more titles (area and support title), and provide view metadata.

Bookmarkable URLs and JS Back Button Support

Web requests/responses have changed greatly with the use of AJAX. We can now make frequent updates and requests on behalf of the user, even without their knowledge. This is a great thing, but one drawback is these requests occur without the browser's history tracking. In other words, the browser does not know how to rebuild the current state or allow the user to go back to a previous client state.

Thankfully, with HTML 5 History support we can give the browser the necessary information about our requests, so that the user may bookmark a certain point, or use the back button to go back to a previous point. Examples where this is used are page changes and dialogs (lightboxes).

Session Support

Kuali applications commonly maintain a lot of temporary state as the user interacts with the system. For example a user could be completing a document that contains several pages, or even use one screen for their entire workday. In order to free up shared resources, the user's state (or session) will be cleared after a configured period of inactivity. A user loosing thirty minutes (or more) of work is a very bad thing! Therefore features have been implemented in KRAD to help prevent the user from loosing data, and to gracefully handle a timeout when it does occur. These features include a session timeout warning dialog that allows the user to extend their session (shown below), configurable session timeout redirects, and a configurable timeout view.

Bootstrap, Less, and the Theme Builder

Version 2.3 comes with a new look and feel built with the Bootstrap library. This replaces the previous KRAD and legacy (KNS based) themes (look and feels). Along with this, a theme builder is provided that supports Less files, minification with versioning, and theme inheritance. For more information see Theme Blog Post.

Breadcrumbs and History

Like Breadcrumbs? If so, you'll very much like the new Breadcrumbs component. It is a complete rewrite of the previous component, and provides a huge amount of new functionality. Among this functionality is the ability to create 'sibling' breadcrumbs. These are items that appear under a breadcrumb item, and can be represented in a dropdown list or a suggest box (see screenshot below).

Breadcrumbs come in two flavors: location based and path based. Location based breadcrumbs serve as a site index. They tell you where you are at in terms of the application structure (e.g. 'Home -> Course Administration -> Edit Course 103'). The other flavor, path based breadcrumbs, show you where you came from. They give you the ability to navigate back to a view within a sequence of requests (e.g. 'Lookup A -> Lookup B -> Lookup C'). Applications can choose which type of Breadcrumbs works best for a particular view or context.

To support path based breadcrumbs, KRAD has also introduced the concept of 'flow'. Currently this is implemented using request parameters and controller methods (side note: down the road this could morph into declarative flow management, or possibly use of Spring Web Flow). Besides supporting path based breadcrumbs, the history manager also supports controller navigation actions (such as going back to the previous view).


Other notable 2.3 improvements include:

  • Dirty Fields - The third party dirty fields plugin has been dropped and replaced with a custom plugin. The previous plugin had several issues which are now resolved.
  • Row CSS - Adding custom CSS classes for table rows is now easier with use of map configuration. Classes can be specified by index, the 'even', 'odd' keywords, or even based on an EL expression that can check values for the current line.
  • Performance - As development approaches completion of KNS Equivalency and KRAD Phase 3 (functional requirements for Kuali applications), performance tuning is becoming a high priority. 2.3 improves the general runtime performance and also provides optimizations that can be taken advantage of in certain situations. Profiling shows reductions of up to 80% off the response time.


The release of 2.3 is significant not only due to the previously listed features, but also that it roughly marks the half way point to the 2.4 release. A good case can be made for 2.4 being the most important release of Rice so far. Without question, it will be the most important release for KRAD. Let's look ahead to the improvements and new features 2.4 will bring.

KNS Equivalency 

  If you have been following KRAD closely, you have likely heard the term 'KNS Equivalency'. This refers to the point at which KRAD will contain all the features provided by the KNS. This effort might be surprising given the number of features KRAD currently has. However, even though KRAD offers many more features and flexibility, there are certain places where the KNS provided an option or small feature not available in KRAD yet (or in many cases not provided at the same level of convenience). This effort will fill those gaps.
  In addition to feature completion, this effort includes developing a conversion guide and a set of conversion scripts. Our goal is to make the conversion effort as painless as possible for existing KNS applications.

KRAD Phase 3

  2.4 will continue Phase 3 development of KRAD. The main deliverables include:

  • Events - Simply put, this will bring the ability to generate client side events and client side updates declaratively in KRAD. Tools such as Angular JS are being looked at to provide the backbone for this functionality. We are really excited about this work! In fact, I will likely dedicate a post for describing this enhancement in the near future. It will be a killer feature!
  • Nested Views - Nested views will be our take on iframes, without all the problems inherent to iframe use. Currently in KRAD, only a single view can be rendered at one time. With this enhancement, multiple views can be rendered asynchronously (by nesting).
  Let's take an example. Suppose your application requires a shopping cart to be presented on each page. The shopping cart can be developed independently of other views (with its own view, form, controller, etc.). For views that should display the shopping cart, a simple group can be created that references the shopping cart view. On render of the parent view, an asynchronous call will be made to fetch the contents of the shopping cart, which will then be inserted into the appropriate DOM position. Very cool!
  • Accessibility - Phase 3 is also slated to include a second round of accessibility work using ARIA. Creating accessible table and tab structures, along with general cleanup for achieving WCAG 2.0 certification will be the priorities.
  • Keyboard Support - Keyboard support (beyond standard browser keyboard support) will be added in 2.4. Out of the box KRAD components (such as navigation) will be enriched with keyboard shortcuts. Applications will also be able to define enter key actions based on the user's location within a view. Finally, applications will be able to create custom shortcuts where desired.

JPA Support

The long awaited JPA support will arrive in 2.4. This includes not only JPA support, but also an overhauled data access layer that will setup KRAD applications for the future. Since Eric will be addressing this item in his posts, I will leave the details for him.


Could there be more? Actually, there is!

  • Performance - Performance work will continue in 2.4 (more accurately, there are plans for a 2.3 patch which will likely contain the remaining performance improvements). This will also include cleanup/optimization of the HTML output.
  • Security - KNS equivalency mandates a certain level of security be implemented. In addition, Kuali is taking a close look at security (developer training, tools, etc.) and discovered issues are being addressed in the software.
  • Tooling - KRAD tooling has not been top priority so far, but a lot of good work has occurred 'on the side'. Some of this will come to fruition for 2.4. This includes a custom schema for the UIF, along with support for Emmet. The new UXI project is also spinning up and will be contributing work to Rice. This is likely to include things such as the ability to build UIs outside of the normal Java development environment (for example, just with a standard text editor, this is another likely post in the near future!) and much more work with the KRAD Bootstrap theme, UI best practices, and accessibility.

  You can see why Rice 2.4 is a critical release for the Kuali projects and the community. This will end a three year cultivation of KRAD, and marks the start of the KNS conversion process. Forward Charge!

Saturday, June 29, 2013

Common Questions (aka Criticisms) About KRAD (P1)

As promised, in the next few posts I will answer some questions regarding the KRAD architecture. I have picked three questions we get the most, and that will also allow me to relay important principles of Kuali and the Rice project. These are:

  1. How is KRAD different from Java Server Faces (JSF)?
  2. Is KRAD tightly coupled with the data access layer?
  3. Why do I have to write all this XML? 

Before I answer these questions, you guessed it, a short history lesson! I pointed out in my introductory post that KRAD is a replacement for the Rice KNS (Kuali Nervous System) framework. However, KRAD retains many of the same goals as its predecessor. What were these goals? Well, there were many, but the major idea behind the KNS was to make it easier and quicker to build the Kuali Financial System, and then a bit later Kuali Coeus. In other words, it was geared for building large enterprise administrative applications. These are applications with many screens and which contain a lot of repetitive user interface content. While retaining this objective, KRAD expands to support student facing applications as well.

Another important factor in our decision making process is one of Kuali's core values: we are functionally, not technically, driven. What does that mean? Well, there has never been an official definition that I have heard, but to me it means this. First, requirements and priorities are set by functional committees. Second, those on the technical side should make decisions that meet those requirements, while minimizing delivery time and future maintenance costs.

Our situation on Rice though is very complicated. Recall, our first mission is to support the Kuali projects. However, we are a technical project. Furthermore, our second mission is to be a general development framework for use at higher ed institutions. This means we do attempt to stay as modern as possible with technology, pay back technical debt, and so forth (as evident by our current work on JPA support). However, even these work items go through functional approval and prioritization.

That should set the stage, so here we go!

How is KRAD different from Java Server Faces?

This is a great question and I am not surprised it gets asked often, for one simple reason: much of KRAD was designed based on Java Server Faces! So why do we not just use JSF? To answer this I need to describe the concept of components in KRAD. In functional terms a component is a reusable piece of UI content. There are basic components like text controls, buttons, and images. There are also more complex course grained components like tables, dialogs, and pages. Now, with JSF you can create much of the same UI content (text control, button, table, etc). So is KRAD meant to compete with JSF? No! KRAD is meant to build on top of tools like JSF.

Here is how it works technically. Producing HTML (and JavaScript) is the final goal, let us call this HTML markup level 1. JSF builds on HTML. Developers create JSF markup, and it in turn generates the HTML. So it is an abstraction, therefore let us call the JSF markup level 2. There are many other libraries like JSF that operate at level 2. For example, JSP, Velocity, FreeMarker, GWT, and various JavaScript libraries (I realize these tools are not really all the same, some do much more, but in general they all provide this HTML abstraction). Now KRAD builds another abstraction layer on these tools at level 2, creating a level 3. In other words, KRAD generates Freemarker/jQuery, which generates HTML. This abstraction layer in KRAD is provided by components.

This raises the question, why create the additional layer? There are many advantages to this architecture, and it has been interesting to see benefits come about we never planned for. Even though there are many advantages, I can summarize the main reasoning with two points.

The Spring Framework 

Rice is built using much of the Spring portfolio. To us, Spring is the best thing since sliced bread! We like it so much that we have expanded use of the Spring bean framework (also known as the Spring configuration system) to other areas besides dependency management. For example, the KRAD Data Dictionary uses the bean framework to configure metadata about application entities. Furthermore, the KNS used Spring beans for configuring some common screens (Lookup, Inquiry, and Maintenance). For KRAD, we wanted to use Spring beans for building all our user interfaces.

Why is this bean thing so great? It turns out the Spring bean framework is not just convenient and flexible for configuring service dependencies, but really any type of configuration. It has all the benefits of XML, with the power of Java inheritance. This provides a powerful environment for assembling pre-built components (see the next part) into a working user interface.

I realize this sounds a bit abstract (side note: I am noting this as a great topic for a future post). Let me give you one concrete way this approach benefits us.

Many readers have likely heard Kuali is "built by higher ed, for higher ed". Some people take this to mean the Kuali products have everything any higher ed institution will need, right out of the box. They simply install and go. This is not the case. Instead the out of the box products contain common functionality, as agreed upon by the higher ed partners. The rest is a customization effort by the institution (or commercial affiliate) implementing the product.

Now those who have attended a Kuali Days conference before have likely also heard the numerous vendor horror stories. The three complaints heard most often are:

  1. Vendor products are not built with the needs of higher ed in mind
  2. High licensing, support, and maintenance costs 
  3. Painful implementations and upgrades, where attempts are made to adjust the vendor product, so that it better fits the institution's needs

Kuali provides relief in all three of these areas. The first two are taken care of by the Kuali foundation and the criteria it sets for new Kuali projects (higher ed partners, community source). The third pain point is remedied by the design of the Kuali products. A great amount of effort is put into making sure institutions can make the customizations they need to, with minimal effort, and in a way that does not have a significant impact on upgrades. Much of this product flexibility is provided through the Rice framework itself, and the Spring framework makes this possible. This ability to easily make institutional modifications includes the user interfaces.

For example, if an institution calls an 'account' a 'fund', or their account number is 15 digits long instead of 7, no problem! They modify a few lines of XML and that change is reflected across the entire application. Need to add some fields to the travel section of the KFS disbursement voucher? No problem. A few lines of XML is all it takes. Furthermore, these changes are done entirely outside the core product, which means there is no need to reapply them each time an upgrade is made. Contrast this to what it would take for most products. First to even make a simple change like modifying label text, you would need to search through thousands of lines of markup, and likely make the change several times. Each time an upgrade is performed you would then need to reapply each of these changes again. This is a process that becomes unmanageable for more than a very small number of customizations.


Let us recall our history lesson and one of the primary goals of KRAD. Essentially this is to build enterprise web applications faster. How does a framework help us build software faster? One of the ways it can help is by pre-building functionality. Most applications have repetitive content, and certainly across multiple applications there exists a lot of repetitive content. We look for functionality like this and build it once, so that it does not have to be built multiple times by other Kuali developers.

In terms of building user interfaces, tools like JSF (level 2) certainly provide many useful features, but they are still fairly low level. That is, they require development to make a complete functional piece. In these tools you will not find a control that searches KIM (Kuali Identify Management) users. Nor will you find a header containing document information, or a fully functional notes and attachments tab. These are the sort of things that KRAD is meant to provide, again building off the lower level tools. Note you will also find lower level components in KRAD, which in some cases map almost one to one with the lower level tool. In fact, when new developers learn KRAD this is generally what they see first, which leads to questions like the one I am answering now.

Even in cases where KRAD provides a basic function (like a simple text control or button), there is still great value to the abstraction. This is because KRAD can encapsulate features such as UX best practices, accessibility, authorization, security, user preferences, theming, and mobile device support. These are not trivial matters in terms of development, and a great challenge to consistently implement without the use of a framework.

That explains why we are building this 'level 3', but now the question becomes why didn't we build on JSF? Well, the short answer is there were features of JSF we liked, but also features of the other 'level 2' tools we liked. As much as we would all enjoy being able to pick and choose features from different libraries, we had to pick one.

The initial functional requirements for KRAD (remember functionally driven) consisted of a list of roughly 20 'rich' UI features that were needed (as you might expect that list has grown greatly since then). Our mandate was not really to upgrade the Kuali tool set. However, we were using an old version of Struts (version 1), and really did not have any JavaScript library in place. Therefore adopting new tools was necessary to achieve the functionality in a way that would allow future growth (side note: this is a good example of how we can get technical issues addressed that likely would never get prioritized high enough by the functional groups). We performed extensive research on tools at that time (roughly 3 years ago, way before JavaScript MVC frameworks). Many of these met the requirements, had vibrant communities, and a promising future. The criteria then shifted to costs. What is the work involved to add the support in the framework, and then what will be the work involved for the existing Kuali applications to convert. The Spring/jQuery/JSP solution (now Spring/jQuery/FreeMarker) by far provided the lowest barrier.

Since that point we have basically been in heads down development and have not looked back (although there is now momentum gaining for looking into client side MVC frameworks). I hope this explains why we do not use JSF directly and why we chose to use other tools to build on. Now, developers who are familiar with both JSF and KRAD might be unsatisfied by this argument. They could say I have taken a narrow view here (looking at only the templating aspect), and there is much more to KRAD components and JSF, which contain duplication. For example, both have a lifecycle concept and similar component Ajax options. This is true. Unfortunately, with Spring/JSP we did not get any functionality like this and therefore built it ourselves (side note: I would really like Spring to add an abstract UI framework, like KRAD, to their portfolio someday). However, even though the concepts are similar, there are great differences in the implementations and the role they play within each framework.

In the interest of keeping this post from getting too long (and loosing your attention), I'll save questions two and three for the next post. Don't forgot to pass our blog along to others. It's the Kul thing to do!

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

Tuesday, May 14, 2013

Bootstrapped, Lessful Themes!

“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 ( 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 ( Less is part of a class of tools (another is SaaS - 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'):

  <viewTheme name="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:

  1. Overlay assets from a parent theme (optional)
  2. Compile .less files to .css
  3. 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 ''. 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 contains 'parent=kcTheme'. This indicates which theme to inherit from. In this case we want to inherit from 'kcTheme'. The file from this directory will override the 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'.