How Ajax Saved Us Money During Scope Creep

When we look at ROI, one thing we need to take into account is how much it costs us to implement our ideas. This week we are going to talk about a non-obvious benefit of a pervasive group of technologies commonly known as Ajax. While the benefits of using Ajax typically come in the form of enhanced user experience, there is more under the covers of this paradigm that leads to cost savings during implementation.

We are currently building the complete back-end system for a very large event venue. The project includes everything from initial contract negotiations, event planning, automated invoices, and CRM. The system even goes so far as to give the food coordinators an interface that lets them make changes to seasonal menus and see how much food they need to buy in bulk for all the events this month. It’s a very complicated system, and has a lot of interlocked parts that rely on each other to function.

Added to that complexity, the client has a penchant for changing their minds. While we did an extensive wireframing phase, some details (or new details) are coming to light in the implementation phase that are requiring (sometimes) substantial changes in where information is presented in the workflow.

As an example, the event facility has a notion of “global discounts,” such as “book this event during the summer [which is off-season for them] and get 10% off.” In all the documentation we received, discounts were created as line items on an invoice. It wasn’t until half-way into development that they decided discounts should be a global idea, tied to a contract, and show up on any and all invoices for the client.

Obviously, this presented problems on both the back-end and front-end. In the back-end, the data had to live somewhere else (not where the invoices live). The front-end could have also been a disaster.

We had built a fairly complex (but intuitive on the front-end) method for the client to dynamically add discounts to an invoice and adjust the discount’s parameters on the page. Had we done this with traditional form-based HTML, it would have been a small nightmare to rip out all the code in order to move it to the contract modules. This is because traditional forms not only have the HTML to create the form, but also the PHP code required to act on a form submission.

Because the entire site is utilizing Ajax to store and edit data, we didn’t have these problems in the front-end. All of the user experience elements (text area, checkboxes, etc.) are completely modular and self-contained. In other words, a checkbox knows how to update the correct database entry and doesn’t require any external code to do so. Likewise, a text field updates the database field it points to as the user types. There is no secondary code sitting somewhere waiting for a form submission for that text box.

This self-contained modularity made it extremely simple to take the fields from one HTML file and put them on another one. Then the functionality simply works because it is independent of anything else that is on the page.

When a client is prone to changing their minds a lot, or when functionality is changed during the development cycle, it is imperative to minimize the risks and costs, especially for a client that might push back on scope creep charges. By developing functionality in a highly modular way, we have been able to mitigate the change of course by making it extremely easy to move parts of pages elsewhere without disrupting any other functionality on the page.

Until next time…

Image on home page via Shutterstock.

Related reading