About one year ago I was extremely excited that my colleagues and I at Jaspersoft were about to embark on a re-design of the UI for our flagship product, Jaspersoft Report Server.
Actually, it was more than a re-design, it was a complete renovation of the UI layer. All of our existing markup, styles and script would be replaced with a standards-based framework of our own creation.
I had conceived and sold this project to Engineering, Marketing and our senior executives because I truly believed this renovation was the required and foundational enabler for a host of initiatives. Primary would be the development of a great user experience, but I also expected it would enable greater community involvement in our development process, more efficient development cycles, faster prototyping, and better stakeholder communication.
I still believe all that.
But man oh man, at what a cost!
The official project estimate was 6 months. My belief was that it would actually take 8. In reality, all said and done, it will take us 12!
We began the project with a team of 4. We will end the project with a team of 12.
Words of wisdom from my former manager at Apple, Bob Baxley, ring in my ears daily. When I arrived at Apple (for my brief tenure there) the store website had just undergone a major re-design. Discussing that experience with me, Bob said “those of us who were here for the re-design feel more like it was something we survived rather than something we accomplished.”
With our UI renovation nearly behind me, I now fully appreciate the feeling that Bob was trying to explain. I also have a pretty clear idea of why this project was so much harder than we expected:
- We did not, and frankly could not, accurately understand the true amount of re-work that was going to be required
- In trying to create a state of the art result, we sometimes had to innovate, but had not accounted for the time of the resulting iteration cycles
- We could not always keep ourselves, or our internal partners, to the limited project scope we had set
- We overestimated the efficiency that standardization would bring to the design specification process.
However, the piece we did not truly consider in our planning was the cost of re-writing all the logic embedded in the markup itself. We are a Java shop, so we use JSP files to create the markup delivered to the browser. In this project we did not correctly estimate the time cost to re-think, replace, and modify the logic in these files. I think our mistake was to base our estimate on an extrapolation of our experience converting over a few pages. The problems with this procedure were, first, that in our test pages we did not actually change all the little things we needed to change in the production version so we ended up with an overly optimistic effort/page factor. Second, the ‘average’ page was a myth. Every page took at least as much time to re-write as our ‘average’ estimate and many took far, far longer.
Cutting Edge or Bleeding Edge?
Our goal in this project was to create a modern UI framework, comparable in concept, if not scope, with YUI or Dijit/Dojo or MochaUI. Why we rolled our own is another post, but the point here is that these things are still quite new and it isn’t always clear what is the best way to solve the various issues involved in creating them. While we could rely on standards documentation to help us conceptually, transferring those conceptual ideas to an actual implementation involved innovation and risk.
For example, we had ambitious goals with respect to improving the accessibility of our interface during the re-design. However, as we progressed we learned that without experience doing this work, ambiguity in the accessibility standards documentation meant that we spent a considerable amount of time debating the best implementation approach, testing ideas, re-doing work and even ultimately giving up on some goals as we ran out of schedule time.
The agreed scope of this project was to renovate completely the interface framework, while leaving the fundamental application navigation and workflows intact. In practice it turned out that we could not keep to this restriction for 3 reasons. The first was simply that sometimes it was not possible. Our new framework includes forward looking design concepts and interactions and in some cases we could not map our older, circa 2002 UI directly onto the new framework.
The second reason was sometimes it was just too painful to leave the old design in place. For example in situations where it was clear that we could replace a 3 step wizard (complete with 3 page loads) with a single, reasonably simple form, we went ahead and did just that. Each time we made this kind of usability improvement we cost ourselves the time involved in re-writing page logic.
Finally, our internal partners had trouble keeping to the original scope agreement. During this project nearly the entire marketing team at the company turned over and the new team chose to re-open some of the design decisions we made with the previous team. Discussing and implementing these changes cost us several man-weeks of effort.
Not Cookie Cutter
A major driver for this project was to improve the consistency of our interface. The old UI had been built up over several years by different developers working without any design management so different sections of our product had different design conventions, interactions and even look and feel.
Our assumption was that cleaning up this inconsistency would be straightforward once we had designed and built a systematic layout structure and a standardized set of components. In practice we found that the application of these standards to our existing pages and workflows was more time consuming than we expected. As we began to convert pages we found that we were missing both layouts and components. We also learned that even our augmented set of standards still only applied about 80% of the time–nearly every page had some particular feature that required some custom layout work or specialized markup.
There were also a few unfortunate cases in the oldest part of the application where what was expected to be a simple task turned into days and days of unplanned code re-factoring. This occurred where our state of the art approach to separating the logic, structure and presentation layers of the UI required us to untangle monolithic server code. For example, in the section of our application that displays paginated reports, the trivial sounding task of making the pagination controls into a general component, instead of a custom element embedded in each report, took literally 10 times the expected effort.
Anyone who has ever been part of renovating a house has experienced the budget-busting moment when opening up a wall reveals an entirely unexpected set of existing conditions. These painful moments serve as humbling (and expensive) reminders that it is simply not possible to anticipate all the risks involved in a truly complex project.
We discovered that a home renovation was an excellent analogy for our experience replacing the UI layer for JasperReports Server. The project took far longer than we expected, and was much much more painful that we anticipated. The outcome, however, like a lovely new kitchen, will be a pleasure to work with for years to come.