Displayr

Problem: Displayr's existing SQL data source (see How to Import Data by Connecting to an SQL Database) pulls one query's result into the document as a static, in-memory dataset, refreshed only on schedule or on open, not re-queried per interaction. Documents still have to load within Displayr's 2-minute limit and fit in the R engine's memory, so customers with very large sources still need to pre-filter or pre-aggregate every query outside Displayr rather than working with the dataset live. This will mean we can support a live data source mode where individual tables/charts/filters push their query down to the source at render time, returning only the aggregated result needed, instead of requiring one static pull of the whole result set upfront. Why it matters: Power BI's DirectQuery connects directly to the source and runs a live query per visual instead of importing data, which is exactly how it bypasses Power BI's 1GB import limit for Pro (and works with data far too large to import at all). Tableau's Live Connection works similarly, though both trade off performance for scale; report speed becomes dependent on the source. We have customers with source files that exceed Displayr's manual-upload limit (8GB) today; without this, we're at a real disadvantage against both tools for large-data use cases. Trade-offs to weigh (based on how Power BI's DirectQuery and Tableau's Live Connection behave in practice): Performance becomes dependent on the source database and network; slow sources mean slow reports, and both competitors are explicit about this trade-off Not every transformation/calculation can be pushed down; some computations that can't translate into the source's native query language would need workarounds Built-in row limits are typically needed per query/visual to prevent overload (Power BI caps cloud sources around 1M rows per visual) Power BI offers a hybrid "Dual" mode combining Import and DirectQuery (e.g., import historical data, live-query only recent data), worth considering as a lower-risk first step rather than full live mode everywhere Optional enhancement — AI-assisted querying: Most Displayr customers (market researchers) won't hand-write SQL for every table. AI could translate a Displayr table/crosstab/banner definition (or a plain-language request) directly into the optimized query run against the source, automating the push-down step so non-technical users benefit without needing SQL skills. AI could also generate a representative sample or pre-computed summary when full live querying isn't practical (e.g., slow source, exploratory analysis), preserving the statistical properties needed without manual file trimming. This wouldn't replace the core live-query architecture, but would make it usable for Displayr's actual audience. Open questions for eng: Which sources to support first (SQL Server / Postgres / MySQL / Redshift / Snowflake already have providers), how this interacts with the R-based compute engine, latency of per-interaction queries, caching strategy, row-limit/safety guards, and fallback if the source is unreachable.

User wants the ability to change the column and row fonts, as well as the background of the header cells, based on Name Colors.

Q allows users to create a Moving Averages variables using Date/Time. Add a similar option to Displayr.

I don't want to show all data labels on a chart, particularly ones that are 0%. However, these 0%s are often flag up as statistically significant, meaning that I am just left with an arrow on the chart which looks a bit odd. At the moment I can only show all sig differences or none at all, I would like to be able to hide significant difference arrows in the same way I can hide data labels.

Create an option to disable the automatic relabeling of variables when combining variables into a variable set so that client can rename them manually. The client claims when they combine variable and they are automatically renamed they can easily lose track of where the combined variable is under Data Sources.

Ability to create Nets in Explore Mode on a table like you can in Edit Mode.

A user would like to update the alignment for statistics below: !image-20230905-164415.png|width=555,height=159! Cell formatting is only available in the “standard” cells of a table, and not the statistics below or to the right of a table. It would be nice to allow users to modify the cell styles for these marginal statistics as well.

Right now all CSS styling has to be entered into the Account settings. This can be cumbersome if you have to create different CSS styling for a bunch of document. The ask is to have the ability to apply CSS styling in each document and have overall corporate CSS styling in the Account Settings. That is if there is no CSS styling in the Document then the Account Settings CSS styling would be used. However if there is CSS styling in the document then that would override the CSS styling created in the Account Settings.

If you hide an empty period in a table using a rule, it will still compare to the previous column. If you right-click > Hide, it will now ignore the missing data period. However, if the period is sometimes missing based on filtering only, it's not possible to ignore this period only when it's missing data while using this setting.

The user would like to move the data labels in a Pie chart to appear within the Pir - rather than on the side.