Skip to main content

· 2 min read

Interactive dashboards often come with slicers that provide the ability to visualize the same dashboard by slicing the data. However, many dashboards and BI tools don't have a way to keep the slicers fixed (or floating) at the top so that as the user scrolls down the dashboard (or a large data table) the slicers are always visible. This results in a poor UX forcing the user to go up and down as they want to slice and visualize the charts and reports that are well below the page fold.

SQL Frames provides a no-code UI that puts the end user in control of having the slicers fixed at the top or bottom of the page. This allows the user to scroll to any chart or data grid on the page and then start using the slicers that are readily accessible. Here is an example of such a UX.

· 11 min read

Large enterprise application software companies like Oracle and SAP used to have powerful desktop applications. During the Internet boom of the late 90s, these companies tried to provide a class of software called "self-service" where all employees, and not just those working on back-office data could interact with the applications to perform simple tasks. The web UI of that era was very basic and so it wasn't possible to create desktop grade enterprise applications for the power users.

As time passed, concepts such as PPR (partial page rendering) and AJAX have helped to push the sophistication of the UI in these web applications to the extent that these days even the power user applications are completely delivered via the web. However this used to be a dark art until the advent of the frameworks like Angular and React. These days anyone can build extremely complex UI very declaratively.

This complexity on the fontend perhaps pushed the balance of the backend-vs-frontend. While historically backend development used to be hard and meant for advanced developers these days the complexity of the frontend also requires highly trained developers and in some ways simplifies the complexity on the backend. No wonder, a good React developer charges $250/hr or more these days.

In spite of all these advances, I think there is one area where things haven't really caught up enough. That is the ability to deal with semantically displaying large amounts of data. It could be too many rows or too many columns or both. Basically, the lack of an awesome semantic data grid. But SQL Frames wants is making progress to change that.

· 4 min read

Bar chart racing has been a popular visualization technique that we all have seen in the last couple of years. In this post I will discuss about how bar chart racing works, it's benefits and drawbacks, a more generalized concept of bar chart racing provided by SQL Frames along with how to overcome some of the mentioned drawbacks.

· 3 min read

There are a wide class of questions that can only be answered declaratively by using advance sql concepts like sub-queries. Sub-queries are also expensive compared to normal queries and hence one of the reasons that not all low-code platforms provide them.

"What are all the opportunities with no activity in the last two weeks" is an example of a query that requires sub-query and SQL Frames just introduced support for a wide variety of sub-queries in both SELECT and WHERE clauses.

· 4 min read

Everyone who studies data structures and algorithms would come across tree data structure and related algorithms at some point or the other. The tree traversal algorithms provide the ability to do bottom-up aggregation, top-down propagation, breadth first, depth first processing and so on. While SQL provides a standard to process recursive data using the WITH RECURSIVE CTE clause, doing any complex analysis on recursive data using SQL is like using assembly language to build a web page.

As much as SQL Frames is a fan of SQL, this is one of the use cases where it has to breakaway from the limitations of it.