We’re working on a new feature which allows users to group/categorise queries. I’m opening this thread for discussion and providing feedback.
Problem: once you have more than 15-20 queries, it becomes very difficult to find the right query. Many of our users have hundreds or thousands of queries—so you can imagine how difficult can it be to find queries.
Solution: provide an option to group/categories queries. You can filter by these categories on the queries page and find your queries much quicker.
I’m considering 2 directions here:
Folders/subfolders: a more traditional way of categorisation where a query can be placed in a folder. Relationship is 1-to-1 between query and category.
Tagging: a more flexible categorisation, where you can add multiple tags for the same query. 1-to-many relationship.
I’d apprecate feedback about this planned feature. Please share your thoughts and ideas!
I think the topic should be larger and layout a bigger plan and later define smaller steps we can take as we work towards this improved state.
The topic should be: content discovery in Redash. How users can find relevant pieces of information?
I can think of several very common practice solutions:
Tagging – as tagging is a superset of folders, there is almost no question as to whether we should do this instead of folders. For the very organized crowd we can offer nested tags (similar to how Bear does it).
Favorites
Global search (that searches across all content, instead of specific search for each type) along with more granular controls on the search (ability to search for a tag or specific types).
On top of that we can improve the list pages to allow better filtering by using tags, keywords, who created this, or data source.
Of course, those are only suggestions. So indeed feedback will be welcomed.
Good to know that finally redash is going to have query grouping.
Here’re my thoughts on some ideas above
Tagging/Folder
I would like to have something like Gmails label–we have both the folder-ish structure and universal tagging as well. Here’s the use case:
We have multiple teams * multiple feature groups to work on.
There would be some feature groups shared by several teams at the same time.
So we would expect to be able to group queries both by teams and by feature groups.
In this case,
using universal multi-tagging would work, BUT the UI would be kinda messy.
using a folder structure could allow more organized UI but hard to deal with those queries belongs to different groups.
Favorites
It’s fine. Since I would expect the usecase to be more about visualization, maybe simply building a personal dashboard with ease could work as well?
Global search
Here’re the things that I would like to be able to search in addition to current functions:
Owner’s name
Datasource
Viz type used
Some other ideas on content discovery
Feature some recently created/changed/run(those long schedule ones) queries on the top page (use viz, not query name)
Give list of dashboards using the current query
Have a page for queries PV, access users count, etc
Some ideas on content enhance
Add widget easier to dashboard, by
use tag/folder information of last widget to suggest the next query to use
suggest other viz of the same query used already or simply allow adding multiple viz from a query
Support easier queries modify / management to have less similar queries / achieve more with less, by
allow modify request or expand modify permission
have query similarity check or list up stale queries
In my experience the biggest issue isn’t “where can I found a query about X”, but rather “where can I find a query about X that is still being maintained and therefore trustworthy, without having to ask the data people every time”.
To address this issue at my last job I made a very dumb solution, which actually worked pretty well. (We used Tableau, but it looks like this can be done easily in Redash too, using the events table - perhaps this is what’s meant by “queries PV” in the post above.) I created a master dashboard with a horizontal bar graph where the Y axis was a list of all dashboards (not queries, but rather dashboards of a given concept, each containing multiple queries that slice and dice that concept in different ways) and the X axis was how many times they had been viewed in the last 30 days. People knew that we were actively monitoring and maintaining anything in the top 15 or so and these could be relied upon as the source of truth (as well as anything else that we hand-delivered recently). It also served as a great form of feedback for us data people to understand what was being used and what wasn’t, ensuring we prioritized our time on what people truly cared about.
We did categorize these dashboards but that didn’t end up being so useful because it was easy enough to scan through 15 titles and that covered most of our core concepts anyway. The one category that did prove useful though was “One-off”, because that indicated the result was valid only as of the date listed.
We also did a clean up where we archived dashboards that were no longer relevant, every month or two. I suspect this is possible for many organizations at the dashboard level, but it will not be feasible to keep every query pristine.
Hope this context is useful to the ideation here! Thanks for all you do, I love redash!
Ben
We have two use cases requiring search capabilties: development and operations.
Development
A developer needs to identify a query, all related forks, and all related dashboards (independently of execution trends).
The search parameter include: query name & tags, tables accessed, datasource name, related dashboard name & tags.
(Folder categorization may not be compatible with forks; also a quick poll on our side confirmed that our developers don’t have favorite queries…)
Operations
A developer or support engineer needs to identify characteristics of queries and dashboards.
The search parameters include query name & tags, query changes count, dates, and user id (who performed the change), tables accessed, datasource name & tags, query executions count, durations and returned dataset sizes over a period of time, dashboard name & tags, dashboard views count and rendering times over a period of time.
For example:
How many queries were executed against datasource X per day last month?
How many times was dashboard Y viewed yesterday?
What were the average response times and returned datasets by query on April 2nd?
How many queries were changed last week and by whom?
etc…
Any solution that supports these two use cases would be greatly beneficial.
I think there are a few tools that would help a lot:
Make the query table sortable by any of the columns.
Have an automated grouping option that will shows queries by which dashboard they appear on.
Make it more obvious which queries and dashboards are available to which user groups. for instance, I admin redash for my company. Sometimes I need to create a set of queries and dashboards that are just for the QA department, for example. The QA department users are in an appropriate user group, but it’s unclear whether, as admin, I can create a query that restricts to just their user group without creating a duplicate data source.
p.s. It would also be nice to be able to bulk modify a group of queries. For example, select 10 of them at once and set the update schedule for them simultaneously.
Bumping this discussion. Tags are now implemented in Redash. But I don’t see a way to filter the query list by multiple tags simultaneously. For example, suppose I have one hundred queries tagged as Billing and five of those are also tagged Management. If I click the Billing tag from a query list view then I will see all one hundred queries. I should be able to narrow the list down to five members by clicking the Management tag on the right.
It would be most useful to add “Data Source” to the available columns for filtering in the Query List view. As it stands, if you search by data source name this will actually filter the list properly – but the table doesn’t make it clear why the results have appeared.
Login or sign up disabled while the site is in read only mode
