Folks at ActiveScaffold have just released v1.0 of their same-named Rails plug-in, and it rocks. ActiveScaffold is a replacement for standard Rails scaffold. It creates fully-featured and professional-looking user interface from your model objects. In its simplest form, it only takes one line in the controller class, for example:

active_scaffold :user

From this declaration ActiveScaffold creates a supercharged data grid that allows the user to browse, page, sort, search, create, update or delete records. Under the hood it uses Prototype, Scriptaculous and custom-build JavaScript to render the DOM grid and handle the user input.

By default, ActiveScaffold exposes all attributes of your model objects and their associations to be viewed and edited by the users (anybody still remembers Naked Objects?). But it also provides a well-designed set of configuration options and customization hooks that you can use to define what the users can or cannot see and do. As it happens in Rails, you have to write Ruby code to set the options, so it’s not as declarative as it could (and , in my opinion, should) have been.

Extreme In-line Editing

ActiveScaffold takes the concept of in-line editing to its extreme. Let’s say you are browsing a list of user roles. Each list row has an Edit link. If you click on it, the record details are shown in the in-line edit form that replaces the current list row (and pushes other rows) down:

ActiveScaffold object listActiveScaffold object list - with inline form
The edit form has Save and Cancel buttons that remove it from the list flow. In the same manner, the Create New button uses in-line form that sits on top of the list to allow the user to enter the new record. Furthermore, you can open multiple in-line forms at the same time, which is where things start looking really confusing.

In-line forms are very cool. I do not think they will make sense for the majority of mainstream business users, because the users generally like things to stay where they are, and don’t like it when things move. It just confuses people when a list row suddenly expands into an edit form, and then collapses back. There are other UI patterns that accomplish the same goal, such as pop-up modal dialogs and multi-panel layouts, and they have been well accepted because they Don’t Make People Think.

Of course every development team targets specific user audience, and Rails users being who they are – early adopters of a not-yet-mainstream technology – might like in-line forms just fine.

It’s Bigger Than It looks

The project web site modestly states that ActiveScaffold is intended as a quick-and-dirty UI for administrative tasks (OK, “dirty” is not the right word – the interface looks beautiful). But I hope that the developers are not going to stop there.

Real-world applications require sophisticated user interface patterns, such as dashboards (list of projects + selected project details + list of selected project tasks + selected project cost analysis chart) or tabbed wizards (create new project -> assign resources -> add tasks). There is a big push in JavaScript framework arena to support these patterns by creating layout managers (see as Jack Slocum’s ExtJS an example), but these frameworks are strictly client-side and do not “understand” model objects. Application developers still have to pull the model objects from the database, serialize them to JSON or XML, and write the client-side code that feeds the data into widgets. ActiveScaffold can potentially simplify all this by generating widgets that are bound to model objects, and by wiring these widgets into rich user interface patterns. Somebody is going to have to connect the dots.


There is a repeating phenomenon in software development: a new project is started with clever ideas and a good plan, staffed with skilled and well-intentioned developers, but in the heat of the initial design and development something goes wrong. Some of the functional and technical requirements begin to attract more attention and resources than the others, and after a while the system grows more and more crippled. Depending on the developers inclinations, the system might have a gorgeous user interface and a messy, unreliable implementation – or it might have well-designed implementation that can stand an earthquake with the magnitude 9 on the Richter scale, and be completely unusable.

A team that continues to develop or maintain such a system is frequently driven by two conflicting forces. On one hand, the management firmly insists on not fixing what ain’t broke, which in a bad case may translate into “let’s hack it anyhow to resolve the problem of the day” and in a good case may mean “we have a vision and a business plan and will choose to address outstanding problems that prevent us from hitting the business goals”. On the other hand, the developers have a natural desire to throw away the existing system design and start over. After all, after making all these mistakes know how to make it right the next time, right? The truth of the matter is that, as Joel Spolsky once wrote, rewriting large software from scratch is a single worst strategic mistake a company can make.

Complex software is a bit like plastics – it may appear solid and rigid and impossible to change, but if you apply enough pressure, you can morph it to address new requirements and to resolve even the most difficult structural problems. Morphing the software design is not an easy task, because you have to understand how all of the system parts work together, which of them need to be changed, how to change them without breaking everything else, and most importantly, how to change them in a way that will make future changes easier. You also need to approach any problem as an opportunity to improve the structure of the system.

This is a lot of work. But once you and your team get into this mindset, once you prove that morphing actually works, your team gets a capacity to meet any business requirement with the existing system. Suddenly nothing is impossible and nothing is too hard.

In business software, the system design is never “done”. New business requirements and technology changes will always render parts of your system outdated, so you need to keep adapting your design to these changes, without starting over each time.