Flexible UI Framework for Greater Performance

There is a kind of “received wisdom” in the industry that highly configurable applications are necessarily slower, because they have to retrieve the configuration information from some database, and then they need a bunch of switching logic to render the view that the user has configured, so that’s slower.

This “received wisdom” is dead wrong, as we will demonstrate.

Perhaps even more important: never underestimate your end users. They know their job far more intimately than you do; as a software engineer or product manager, you are exposed only to the most pressing concerns of the moment.

You think you understand the design of a particular screen very well, because you designed it or coded it? No. Your end users know “your” screen far better than you do, because they have figured out the fastest way to use it to do their job, and usually, that isn’t the way you thought it would be used.

When it comes to web application optimization, the fastest, most scalable applications are the ones that have configurability baked in, where end users can configure the application to match their exact usage pattern, even as that usage pattern changes over time.

UI configurability has to be considered a baseline requirement in web application optimization. Configurability enhances both performance and productivity. 

Let’s look at some specific examples.

1. Saved Search

This is a subtle one. Saved Search is just a productivity feature, not an optimization, right?

We rolled out a saved search feature at one of our customers and within days, the end users were saying wow, what did you do, everything is a lot faster?  But in this particular release, we hadn’t intended to roll out web application optimizations. This release was mostly just new features, including saved search.

It was the DBA who finally figured it out: when you arrive at most screens in an application, there is a default search. For example, in personal banking, the default search might show recent transactions. In an issue tracker, the default search might be all open issues for your team.

Because of the pervasive Saved Search feature we had added, users were now configuring their default search, and replacing that default search with something more relevant to them. In general, those user-specific searches were much lower data volume, made better use of indexes, and hence lowered the database load by enough that even users of other applications noticed.

Further, before the introduction of the Saved Search feature, most users had a habit of arriving at the default view and then changing it to match what they needed. So consider a user doing this:

1. See default view (1st unnecessary request)
2. Change sort (2nd unnecessary request)
3. Add one criterion (3rd unnecessary request)
4. Add second criterion (the view is now what the user needs)

Saved Search – seemingly a convenience feature rather than an optimization – gives you a 4x performance boost in this common situation.

If that seems like a surprisingly large optimization to assign to Saved Search, realize that it’s possibly even larger: sophisticated users need to switch between different views of data, and every time they do that, if there is no “Saved Search” feature, they do so by incrementally changing the search until it matches what they want. So Saved Search not only reduces unnecessary requests when users arrive at a screen but also reduces requests as end users switch between different views of the data they need.

Once we fully understood the value of saving search queries as an optimization, we designed a Saved Search feature that could be turned on by default in every single grid, so that in every app ever built with our technology, this particular web application optimization would always be there.

And we did succeed with that – the feature is on by default in all grids, and works by saving searches to the user’s browser (window.localStorage). However, the storage is pluggable, so that you can instead save searches to the server and also have admins that can create or revise pre-defined searches on-the-fly.

You can see that working here.

2. Other Patterns of End User Configuration

The previous point about Saved Search can be generalized: when you allow your end users to configure the UI of your application, they go right to the data they need, they become more productive, and they reduce server load because they are no longer loading data they don’t actually need to look at.

Here are some other examples of configurability that are also optimizations:

Default screen to navigate to after an action

Wherever possible, let users pick the next screen to go to after completing something: at login, when done with a particular process, etc. It’s easy to add something like a dropdown that says, “After saving, go to: [list of screens].”

Sophisticated end users will absolutely make use of such a shortcut. You don’t even really need to come up with a way to save their preference across sessions, because with the very long session lengths of true web applications, holding onto that preference for just the session would already be a big boost (but it is better if you can persist it – more on that below).

Saved sets of form values

Imagine “Saved Search,” but for forms. With any form in the application, you can save a specific set of values and name them, then re-apply them whenever you are ready to use the form again. This is easy to build in a general-purpose way, so it can be simply “turned on” for any form in the application.

It’s clearly a productivity feature, but how is it a web application optimization? Well, filling out the form may typically involve navigating two combo boxes and a pop-up dialog, all of which require searching through data.

Make your own dashboard

Sophisticated end users can use a “report builder” or similar interface to create a “dashboard” containing the specific data they need to see – this is especially true of end users who are financial analysts, scientists, or the like. If the user isn’t able to create a dashboard directly, they are likely to create one indirectly, often in a very inefficient way.

A dashboard builder is, of course, a non-trivial thing to implement. However, some advanced frameworks have this as a built-in capability, easy to turn on for a given screen.

These are examples of configurability that can be applied to almost any application, but the fact is, in general, configurability is very application-specific. The key takeaway here is to understand that a flexible and configurable UI increases both productivity and performance.

As far as the perceived drawback of configurability – that you have to save the UI configuration, load it, apply it, etc. – remember that as a developer, you have the option to save configuration in cookies, window.localStorage, and via other mechanisms.

Yes, configuration stored via localStorage will be lost if the user switches devices, and that means it’s not necessarily a good choice for something like a user-created dashboard, which the user may well have put some time into. However, for something like a default screen to navigate to after login or after a specific workflow, it may be fine – a minor inconvenience that most users never experience, in exchange for flexible UI that you get “for free” – zero server load.

Rich search, sort, grouping, pivot – never skimp

Many times, I’ve had a customer say something like: “your search capabilities are really powerful, but the UI design calls for a simplified search interface, so we turned the entire default search UI off.”

This is a terrible idea. It has led to some of the worst performance problems I’ve ever seen.

Why? Because the designer’s idea of the user’s needs is necessarily incomplete, and the user’s needs change over time.

Having seen so very many projects, I can confidently tell you: the search capabilities you actually need are always, always more than you think at first.

Why limited search is a performance issue

But how is this a performance issue?

Because, when the available search isn’t enough, users still need to get their work done. So they are going to do the search they need to do, somehow, and often the approach they figure out is a performance catastrophe (not to mention the impact on productivity!).

This is one of the key areas in which B2B vs B2C UX design differs, in a way most designers do not fully appreciate: it makes sense to remove advanced search features from a B2C site. It’s rare that a normal consumer would use them, and the removal of unnecessary search features can reduce server load. 

But B2B is completely different: your users need to get the search done. If you don’t provide a way to do the search they need, they will come up with a way to do it, because, they have to. It’s their job.

I have seen lots of clever end user workarounds for underpowered search UIs. For example: one user needed to view certain data side-by-side, and the app didn’t allow it, and also restricted her to one session per browser, so she resorted to installing extra browsers and even VMs to get more sessions, in order to work around an app that just didn’t have the side-by-side view she needed. Her usage was killing the server, but ultimately, the UX team could not come up with a better way of achieving what she wanted to do within the existing UI – her workaround was the best option available, at least until the UI could be re-designed.

Limited search leads to expensive Excel exports

By far the most common performance catastrophe from limited search, which I have seen no less than 5 times, is having users export to Excel and search there instead.

With no better option, users export enormous data sets to Excel; millions of rows in some cases. In each case that I’ve seen this, the analysis that the user needed to do in Excel was not actually complicated; SmartClient’s built-in search features would have let them do it entirely in the browser, or at the least, would have allowed them to refine the search so the export would have been small and not a performance problem.

But instead, with the apps in question, where the UX design had specified a simplified or “streamlined” search interface, the users simply couldn’t do what they needed to do. So of course they went to Excel, and in one case, a particular user’s morning “export” had about a ~30% chance of killing the server (out of memory error), which would interrupt everyone else’s work.

Simplified vs. Sophisticated search: you can have both, with no tradeoffs

To be clear: simplified search interfaces are great. From a UX perspective, you should definitely analyze user behaviors, determine the most common search use cases, and build a UI that allows users to execute those common searches with the minimum number of steps. 

At the same time, you should give your users a more flexible & general-purpose search interface. Simplified search and advanced search is not mutually exclusive – we have a SmartClient-based example here showing a straightforward UX that allows both simplified search and advanced search with no compromises. This approach can also be achieved with other UI technologies.

The false optimization of simplified search, and how to correct it

If you provide only a limited search UI, you may well find that your highly optimized default search interface is indeed performing as expected, is very fast and very easy on the server, and then the whole team pats themselves on the back.

Unfortunately, real end users are using something else (whether gigantic exports, dozens of concurrent sessions, or whatever it is) to actually get their work done, and that is killing performance, as well as killing productivity.

Worse, many organizations just don’t communicate effectively across teams. The result is: the design team did a great job! The development team did a great job! The app is slow in production? Must be the DBA’s fault.

You can do better. High-end frameworks usually have excellent built-in search capabilities. When you receive a design that has very limited search capabilities, you can point out that the proposed search interface only handles the known use cases, and advocate for preserving the built-in search capabilities that come with your UI framework. If you are told that’s impossible, you can show them the SmartClient example, which allows both simple & advanced search with no tradeoffs.

Also, if slowness is being blamed on the hapless DBA, you can be the voice of clarity, pointing out that end users are working around a bad design.

Tip of the Iceberg

For developers who have been indoctrinated in the school of optimization that is centered on “minimize bytes for initial load”, the set of concepts in this article may come as a bit of a shock.

But this is still just the tip of the iceberg.

If I had the bandwidth and the space to do so, some of the things I would cover would include:

• Client-side grouping, pivoting, and aggregations: Giving users various views of the same data set without further server contact.
• Ultra-flexible grid layout: Why not give the user the ability to preview any long text field under the selected row? Why not let them view related records on the fly? These flexible views can come with intelligent caching & data reuse, improving productivity and performance at the same time.
• Client-side SQL-like engines: Turn an extensive data analysis session into zero server data requests. This can support far more data volume than you might think.
• Multi-modal presentation: Is it a classic list of rows, a tree, a set of tiles, or a node-and-spokes graph? It’s all of the above, and you can switch on the fly, and the server need not be involved.
• Multi-containers: Is it tabs, an accordion, portlets, a linear layout, a dashboard, or floating dockable windows? Again, all of the above, why not allow switching on the fly? When users can take any part of your app and re-mix it, they invent their own best UI, and if they can share it, both productivity and performance skyrocket!

If you have any feedback on this article, I would love to hear from you! There is plenty of room to improve on what’s here. The best way to get in touch is to Contact Us.

About the Author

Charles Kendrick has been the head of Isomorphic Software for over 20 years. He is the Chief Architect of SmartClient and Reify. Both products are heavily used and very popular amongst the Fortune 500. He has successfully worked with and coached dozens of teams delivering high-performance systems and is a pioneer in the field of web application optimization.