How We Finally Eliminated Flash

Up until our 5.2 release, we were using Flash (specifically, we were using Flex) in our UI. In 5.2 we’ve finally done away with Flash! This was a big change for us, so I’d like to cover how we did it and how we used the opportunity to make other changes in the user experience.

When the MVP of Delphix was built in 2009, it seemed like a clear choice to allow the team to focus on our unique offering (database virtualization). Since then? Apple killed Flash and we’ve been happily living in an HTML5 / JavaScript world. Well, except for the Delphix UI, that is! When we first built the product it did one thing - made space-efficient copies of Oracle Databases. As we’ve grown from a handful to many hundreds of customers and introduced support for a wide range of data structures our user interface has sprawled as well.

This provided an interesting architectural and product question - should we try and do away with an old technology all at once or go in incremental fashion? We had three major issues with Flash:

  • As a dying technology, the developer tools weren’t improving / maturing nor were there a ton of developers dying to work on Flash

  • Using Flash required our customers to have the Flash plugin - something that was increasingly disallowed in enterprises

  • The speed with which we could bring new features and new designs to market was stunted.

We initially were planning to slowly rip out Flash page by page and redesign as we were going. The problem? It didn’t actually solve any of our paint points above. We pivoted and decided to do it all at once - so we could bring new high quality design / UI work to market faster.

Release 5.1: Just say “No” to Flash!

So, how do you actually go about removing a UI framework that’s been in use for the better part of a decade?

With smart, dedicated people… and a lot of them. When we made the decision in 2016 to finally rid ourselves of Flash, we staffed 20 people on the project for a year - and we needed every one of them and every month that we had. Luckily, we did have some things in our favor - in particular, our platform has always been API-first, and the previous UI worked with this API as well. This meant that we could focus on rewriting the UI without have to change many of the underlying functions. Of course we always discovered new API endpoints we wanted to implement, but we kept this list short!

At a similar time in 2016, Delphix invested in an Experience Design team - a highly senior team focused on improving every single touch point our users have with Delphix. We realized that we had an opportunity to redesign key parts of the product from scratch since we were already investing to replace the entire user experience. We prioritized a few key areas (seen below) which allowed us to maintain a reasonable engineering schedule. Over time as we’ve matured our product and our product-market fit, we’ve grown to support new data sources and focused on improving enterprises’ application development. This gave our team the ability to focus on a few things:

  • How can we simplify every aspect of our product?

  • How can we ensure that users of our product have the information they need at their fingertips?

  • How can we build a platform on which to develop the next generation interface?

I want to share a couple of examples:

Release 5.2 Dashboard: We’ve redesigned our dashboard to focus on the key things that our data operators need to know: Are there any issues delivering data that developers need? Is any developer’s database taking an outsized share of throughput / storage? Do they need to deploy more infrastructure?
new 2
5.2 Timeflow & Dataset Details: One of our goals for the project was to use customer input to guide the new design. With Timeflow, customers told us that it was difficult to trace the lineage of their datasets. So we added the Dataset Details panel to show parent and child relationships—as well as the size of the dataset in focus in context of total engine capacity.
data set
5.2 Performance Monitoring: We’ve introduced a new screen to track network throughput by dataset - helping to identify if there are any outsized users of resources or any “noisy neighbors.”
5.2: Perhaps the most common question we receive is “which datasets are taking up the most storage and how do I clear them and their dependencies?” Now we have a whole screen dedicated to understanding and taking action on storage usage.

While we’re really excited about overhauling our user interface, this is really just the beginning. We had a tremendous amount of the ever-lurking “technical debt” to resolve with our elimination of Flash and we’re looking forward to driving our user experience in and out of product ever forward.

Next up - how our customers have come to embrace Oracle 12c and how our product is adjusting to support it.