If the Quick Base product were a person, we would already have the ability to vote and buy lottery tickets. Nearing two decades as a trusted solution of business app builders, we’ve learned and improved a lot. But like a young adult heading off to college or the proverbial workforce, we realize there are some things — like that beloved, old blankey or teddy bear — that need to be left behind.

My team, the End User team, tries to put ourselves in the shoes of end users of Quick Base (as opposed to app builders or account admins) in order to solve their problems. An end user is someone who uses a Quick Base app that someone else in their company builds. Our goals are to empower end users to:

1. Be more efficient and productive while using Quick Base
2. Learn how to use and navigate Quick Base more easily
3. Enjoy using Quick Base

In service to these goals, we aim to simplify Quick Base and make it more intuitive to use.

What does this mean in practice? It means making sure that there is only one, easily discoverable way to do something.

We have a lot of functionality and UI that, in their day, may have been cutting edge, but are now woefully outdated. Our customers are endlessly creative in finding workarounds to add functionality that we previously didn’t offer. One of the reasons we keep a lot of those features around is because customers are still using them.  Even once we realize, “Hey, we can do that natively in the product for everyone,” there isn’t always a strong impetus for those with existing solutions to change. So we end up keeping old stuff around to make sure customer functionality remains intact.

Home pages are a perfect example of this. Home pages are the entry point to nearly all of our apps. An app builder can curate the content of these home pages for their end users by presenting customized reports and charts, providing links to other important places in the app, displaying a README with instructions on using the app, and much more. End users then have all the context they need to start being productive right away.

A few years ago, we created a modern, widget-based home page, with a drag-and-drop building process. Builders loved it because they could directly manipulate the elements of the home page while previewing what their users would see. At the time, we decided to keep the older homepage, built with checkboxes and drop-down select menus, so that customers with older home pages could still view and modify them. We’ve seen that our builders, especially builders new to Quick Base, love the new home pages and their drag-and-drop construction. Beyond that, there are costs of supporting old functionality as we try to innovate. We decided to deprecate our old home pages for three reasons:

1. As we started updating some of our report types (most recently Calendar Reports) and adding new ones (Kanban), the tax of ensuring these new reports play well with the rest of the UI on the old home pages was becoming too much.
2. Removing old home pages allows us to simplify the product by providing fewer and more intuitive ways to do the same thing.
3. Several features used in old home pages expose our users to code that may no longer be supported, which opens both our customers and Quick Base to potential security risks.

When we saw an opportunity to deprecate old home pages, while maintaining customer functionality, we took the opening.

Quick Base makes prolific use of feature switches (aka feature flags or feature toggles) — customer specific server-side and client-side checks that enable or disable a given feature. They allow us to release functionality in early access, receive feedback on usability, and make corrections before releasing to all customers. They also allow us to easily deprecate old functionality, by simply turning a given switch on for everyone before we clean up and remove the associated code.

Removing old home pages is more than a change to the presentation layer. It potentially is a change in user data. This precludes the use of a feature switch. We, therefore, created a process that allowed app builders to convert their old home pages into new ones and switch over when ready. Old home pages follow a common pattern in our legacy C++ server code; they are HTML templates generated and filled on the server side. The new widget-based home pages use Backbone and serialize to and from JSON to communicate with the server and persist the home page object/data. It was simple enough to write a JSON serialization function for the old home page objects and use it to populate a new home page.

The tricky part was how to replicate a certain piece of functionality of the old home pages. Previously, we allowed users to enter arbitrary HTML into a rich text element, and we would dutifully render it, executing scripts and all. This is incredibly important in allowing customers to customize their home pages, but also presents Cross Site Scripting security vulnerabilities, and therefore is not supported on new home pages.

To solve this problem, as part of the old home page conversion, we take every rich text section on the old home page, sanitize it to remove script tags, inline event handlers and the like, and place it in a rich text widget on the new home page. If there was only HTML, with no added functionality in the old section, the new one will work great. In case there was important business logic occurring on the old home page, we also create a raw HTML page with all of the contents of the section. The customer can then take this page, and link to it within an iframe widget of the new home page, or use it to start a Code Page, a blank slate where advanced builders can build their own HTML, CSS, and JS based homepages. The last step customers will have to take is to swap over the role-based settings of the old home pages. For example, if the default homepage for sales reps was the home page, now they just need to make it the new one.

Software companies are continually weighing the costs and benefits of various types of projects. Tech debt work, such as deprecation of old features, is often easy to deprioritize in lieu of new feature implementation. In our case, it was easy to justify the work required to make this change. We wanted to avoid future roadblocks and to make the product safer, simpler, and more intuitive while maintaining customer functionality. Working with a legacy platform certainly has its challenges, but like a teenager comin­­g of age, it’s our approach to these challenges that allows us to adapt, grow, and become successful. As we continue to learn, simplify and improve our product and process, we look forward to problems and to solving them in efficient, creative ways.  ­