Quick Base Announcements

Dynamic filters vs column filters in the Quick Base grocery store

By Harrison Hersch posted 08-23-2019 13:37


I heard a great analogy recently Quick Base is like a grocery store. While a grocery store might have 40,000 unique items, how many do you walk in looking for, let alone purchasing? The grocery store is responsible for serving a very wide customer base and balancing the needs of the many. Of course, you can also go to a specialty store which only has a few hundred items but is much more likely to serve a niche much deeper.

As we promised in our Product Keynote at Empower2019, we are going to carefully be rolling out improvements to modernize our user interface. During this process, we plan on gathering feedback that spans 200,000 users, 6,000 accounts and over 100,000 applications. Spread amongst those is an infinite number of use cases that all require different features and have different priorities, just like all the customers in the grocery store. We want to be transparent about our journey, the process of gathering feedback, reconciling and assessing it, and ultimately share how we produce the product or feature that you experience.

To that end, I thought it would be interesting to walk through our rationale and bring it into the context of some new features for a real-life example. We start with a fact-based model that we use to first decide what we work on as a product organization. Among other things, this includes factors like competitive research, customer feedback, strategic goals, etc. This model drove us to decide to focus on the new table report we presented at Empower, before working on a new form. We believe this benefits the widest footprint of customers while also preparing us for more future compatibility. At the same time, we know there are some customers who would have preferred a new form first.

As we dive into a specific feature like new table reports, we must prioritize the features we plan to tackle. We use the same framework to do that, but at a more microlevel. Within a given feature, there is also a consideration of backwards-compatibility competing with innovation and moving the platform forward. After all, one of the reasons customers chose to use a SaaS solution like Quick Base is that they don't need to continually have teams of developers doing optimizations, enhancements, and bug fixes; they'd rather have us handle all of that. This requires a delicate balance for us. One of the most difficult tradeoffs in software is how simplicity competes with flexibility. For every feature we add, we need to think through defaults and decide if something is optional or not and how it impacts new apps vs existing apps. Unfortunately, we know we simply cannot build every feature to the exact specifications every customer requires. Our goal is to get as close as possible to benefit the most people.

Table reports are used over 100 million times per month. When we look at our builder or user journey, we know that most people are moving into Quick Base and already have experience with some sort of spreadsheet format of data (rows and columns). If they are new to software, their familiarity is probably with something like Microsoft Excel. On the other end is a database administrator, who is probably used to something like SQL Management Studio. So, this common format of rows and columns is crucially important for us to get right. We thought we would share two more specific examples of upcoming features and how we consider adoption and change management for those.

Note: Mockup subject to change

The first one is resizable columns. A highly-requested feature and seemingly as simple as it gets. We will be letting you resize columns on our new reports, but should those settings remain across browsers? Should those settings apply to all users? What happens if you shrink a column but come back to a report and there is a bigger piece of data in a record? What about different monitors? These are very difficult questions that we set out to answer. This required us to do research, talk to customers, and discuss it at Empower 2019. The way we plan to handle this is by having settings such as column width be sticky to your session. That means that if you view a report at your office with a 23" monitor, you can customize your column widths on a report while also having the ability to customize them differently on your 14" laptop. One option we evaluated was having column widths be manually set by the builder of a report and apply to all users who view it. On top of the extra effort associated that would take us away from building other things, the thought process was that this would be confusing for users because a builder cannot always anticipate their user's browser, monitor, and zoom level. That being said, we will continue to learn throughout early access and evolve our thinking as needed.

Even more interesting is the conversion from dynamic filters to something more relatable, column filters. Another highly-requested feature, column filters are more common and have significant advantages. We know that having both features was a non-starter for a never-ending list of reasons. Deprecating a feature, however, is a decision that takes careful time and consideration. We started with an internal power user group as a 'scream test'. Unanimously, the feedback was that the benefits far outweighed the risks of moving away from dynamic filters and onto column filters. Early on, we identified really the only two benefits dynamic filters have over column filters:
  1. The ability to point & click for a filter. Column filters requires one more click to get to the drop-down menu when applicable.
  2. The ability to have a filter that isn't a column on the report.
Mitigating both concerns was important, but we knew the second one was more difficult from an adoption standpoint. There are a few reasons we are confident in our decisions here:

  1. We plan to have amazing collapsible grouping. Some of the scenarios that users may have needed dynamic filters for are reduced.
  2. Without the panel on the left, density controls, and a better visual layout, we know that users will have a better use of screen real estate and adding additional columns may not be as big of an issue.
  3. With resizable columns, users can customize their view.
Lastly, we plan to make these filters so helpful that most users will be happy with the tradeoff! To validate our findings, we conducted a survey during a session dedicated to this feature at Empower 2019. It was one of the highest attended sessions at the whole conference. We were ecstatic that so many of you came to share your opinions and feedback with us to help shape such an awesome feature. During the session, we held a live survey and discussed the results real-time. We also brought the results back to discuss with our developers and user interaction designers. One awesome confirmation of our hard work on column filters was that 92% of participants said they were okay with us transitioning away from dynamic filters, and onto column filters. An expectation of 100% is obviously unreasonable, but we were thrilled with the support we received.

For each of these examples, there are ten more things that we must carefully consider weighing the tradeoffs, costs, risks, and benefits. Additionally, the priority of how we choose these is important and each customer will have a different priority that is most near and dear to them. So, what are our promises to you as we modernize the user interface and, even wider, as we approach product changes in general?

  1. We promise to use objective information and facts in how we make decisions.
  2. We promise to spend ample time and take seriously quality control and regression testing.
  3. We also promise to communicate via our release notes changes that are coming.
  4. Most importantly, we promise to listen and consider your feedback.
You can expect to hear more about our new table component in coming months and we look forward to your feedback.



23 days ago

Hi Hector! Since this post, we've made great strides in this area in our new table report.

You can read more details on those improvements here:

Rollout Plan

January 3rd Update

March 12th Update

April 17th Update

And if you're interested in taking a closer look, sign up to join the Early Access program here and select Using Apps under Early Access Categories. We'd be happy to have you!

24 days ago

Update: Thanks @Alice Hinshaw!

What is the latest on this?   I can't find any updates on planned release.​

11-21-2019 14:08

Count me in as well

10-15-2019 18:00

Hey Jim. What you are describing is a known bug on the existing reports. The new table component certainly addresses this in a more delightful experience. All effort is currently on that new experience.

10-15-2019 16:52

Edit: 11/21 Thanks for fixing the column alignment!! 

I created a Support case and was given this link as the resolution. We are hoping this can be resolved soon as our Users are beginning to notice.

There appears to be an issue with the column alignment in some reports. Initially, the column data appears to be right justified under the column heading in the report. When you scroll down, the report appears to resize and the column data no longer appears to be associated with the correct heading. If the alignment in these reports could be adjusted so that the data is more clearly associated with the correct heading, that would be very helpful.


09-17-2019 17:50

Hi folks. You will be seeing an early access within the next couple months!

09-09-2019 11:16

Thanks for the post Harrison, this seems like exciting stuff! Are there any plans for a demo app open to the public so we can provide feedback after using it?

09-09-2019 10:40

Any info about a timeline for this yet?

08-08-2019 19:22

a way to run some type of in-line formula while you are viewing the report

That sounds amazing

07-31-2019 20:09

Thank you Harrison for sharing such an indepth insight to the process and the path forward.

07-26-2019 12:41

Hey Adam. Glad to hear you are thinking the same way we are about having a relatable experience to Excel.

Quick Base formulas are a proprietary language that run server side. With a goal of democratizing software development, we don't want folks to have to write code to achieve their goals. There are also heavy considerations of performance, and when the the formula evaluates. For example, if you were using a report that had a million records and this was paginated, a _formula_ in JavaScript can only evaluate what is in the browser - which isn't the whole million records. Then there are further considerations with how the work that is done in filters is translated to Quick Base query language. So we definitely need to keep a pretty tight wrap on the core experience. _That being said_, we have plenty that we are working on to make sure the pro developer like yourself feels right at home:

  1. A long-term goal for the new reports is to have a way to run some type of in-line formula while you are viewing the report. Sort of macro-ish. This is all still TBD.
  2. Our new APIs will be even more rich and easy to use and we specifically plan on making it easier to gather data from a report. This should make it much easier to pull in data to something like Excel, or create a custom UI on top of Quick Base.
  3. _(fine print - very early)_: We are looking at safe ways to provide further extensibility points to the platform in line for things like what you are talking about.
Hope this helps!

07-26-2019 12:16

Thanks for sharing. I look forward to these and other enhancements in the future.

I use macros in Excel to manipulate multiple column filters with a click of an active x control button. It would be good if the Quick Base code that performs the filtering actions were made available to users so they can create formula fields and quickly add multiple filter options at the click of one button.

Also, Excel makes it easy to show/hide columns. It would be helpful if this were available in Quick Base too. It is extra effort to go to the report customization page to add/remove fields.