Hello, im trying to use a list of buttons at the top of a page and have the list display values that match the value of the button. In essence using the buttons as a sub menu or pill list. i have not been able to see how to send a value to the list from a button press. Is this possible without creating a page for each button?
Hello @ryanp 
Just to be sure we understand correctly - are you trying to filter values in a list using buttons?
Something like this, for example:
If that’s the case, how many buttons are you planning to include? 
Yes, exactly i have between 6-8 buttons
Okay, here’s the step-by-step procedure. Be aware that there may be a better way: count on my colleagues to enlighten you on this point if necessary 
Requirements
- 2 columns per filter in the
Userstable- 1 column to aggregate everything in the
Userstable- 4 columns in the
Productstable (or equivalent)- 1 workflow per filter
In the Users table 
-
Create a Boolean column for each filter you want. You’ll store here the value of the filter (like a switch). In this example, we have
Trains?,Cars?,Bikes?, and the configuration is very simple:
-
Create a If → Then → Else column. Again one for each filter. It’s an easy way to display the value to the user. We use a little trick with emojis for that:
- if the value is checked, this is going to show
Bikes - if it’s unchecked, this is going to be “empty” and we’ll have
Bikes
Note that emojis are displayed differently depending on OS and devices. These circles are generaly very similar which is not always the case. You can check that on this website: 🟡 Yellow Circle Emoji | Meaning, Copy And Paste .
Please have a look at the configuration of these columns named
Trains pill,Cars pill,Bikes pill:
- if the value is checked, this is going to show
-
Create a Make Array column,
Array of pillsin this example.
In the Products (of course, you will adapt to your specific case) table
-
Create a Query column -
Active user- to make sure the filters depend on the signed-in user.
-
Add a Lookup column (
Array of pills) to obtain the array we created previously for that specific user.
-
Assuming you already have the Category available in the table, create a Template column to concatenate the “yellow circle emoji” with the category name. This is
Category with emoji(yeah, I know, amazing naming convention
)
-
And lastly, we’ll get to know if the row is part of a selected category thanks to a If → Then → Else column
Category selected?that compares the value of each row to the real value of the filter.
In the Layout
-
Add you collection (List, Card, Table, whatever you want) and use
Productstable as source. Go to Options > Filter Data > Category selected? is checked
-
Add a Button block component. To my knowledge, it’s the only way to nativly force all elements to be on a single row (from left to right, without line break). Maybe in your case, you could go for 2 different components, one on top of each other, for UX purpose. That’s why I asked you the number of filters. Up to 8 in a single row might not be very elegant
You’ll choose of course! -
Add one Action per filter you’ll use to the Button block component. Here there are 3 filters so 3 actions. You can already change Style and Options if you want and also the Title of each action to bring back the values from
Trains pill,Cars pillandBikes pill:
In the GIF, the set up is:- Style = Tiles
- Width = Wide
- Labels = Show
In Workflows
-
Add a new workflow and select App interaction
-
Change the name to something more logical like
Trainsand selectUsersas datasource table.
-
Now, we are going to apply the “switch” and create a 2 branches workflow. One will be executed when the filter is ON (and must become OFF) and one will be the exact opposite. Click on the + sign to Add condition and define the condition to be User profile > Trains? is checked. Then click on Add else.
-
Add a Set column values action below the first condition and change the row to be the User profile > User profile row. Because we are in the Trains workflow when the filter is already ON, we have to change it to OFF so we just write false in Trains?
Now, when you click (App interaction), and the value stored in the User profiles > Trains? column is checked, then the value becomes false (unchecked).
I’ll bet you get the idea, we will do the same thing for the else branch, but instead of writting false, we’ll write true…
-
Proceed exactly the same way to create a workflow for Bikes and another one for Cars (so again, up to 8 in your case). The Duplicate option is very helpful here and avoid a lot of mistakes so don’t miss it!
Lastly, back to Layout
- Change the Action associated to each button to Workflow for Users > Bikes (or Cars, or Trains…)
Everything is now OK and you can enjoy playing with your filters 
The content of this post may seems scary due to it’s length but honestly, it doesn’t take long because you duplicate many things (columns, workflows, buttons…).
I’m pretty sure there are some improvments to find but this will be for another day
Hope that’s what you expected!
3 Likes
You are the man thank you
If it acts just like a submenu and you can only have one section selected at once, Glide has a prototype in private beta that does exactly that, with you only having to configure a query based on the chosen value for it to work.
I don’t see any problems with it after a few days of using, though I don’t have information on when it would come to production.
1 Like
It’s interesting that you chose to store the filter values as global values in the users table and not as user-specific values in a helper table.
Any reason why you opted for one approach rather than the other?
I do that quite often. Especially if I think I might end up using those same filters elsewhere.
2 Likes
I’m going to be pondering this for days.
My train a thought.
A user-specific column seems to be 3 columns under the hood: the record’s row ID, a user row ID and a value.
If a user-specific value isn’t actually an attribute of the record and it’s a user’s preference (such as for this onscreen filter), then really a user-specific columns is now only 2 columns under the hood: a user row ID and a value. We could imagine the data of user-specific columns lives (under the hood) in the users table with row ownership applied to the row and it is displayed in other tables as a relation+lookup in one column (again under the hood).
Data in user-specific columns cannot be used globally within the app. Data in the users table is easily accessible throughout the app.
Based on the above and if it is correct, I’m trying to think of the cases when I should be using user-specific columns and the ones when I shouldn’t.
Back to the thread. Without giving it much thought I would have it used user-specific columns. I’m definitely not saying it’s better. I’m trying to determine if one approach is indeed preferable and if so why.
I’m going to sleep well tonight! I can’t wait.
1 Like
Perhaps I should clarify. I do both. That is, I use User Specific Columns in the User Profile row.
I know that it’s totally unnecessary to make them User Specific, but I do it to give myself a visual cue that such columns don’t hold “actual” data, but rather temporary/transient values that are used for filters, navigation, etc. It’s also a hangover from my days using Google Sheets where I didn’t want these types of columns creating clutter in my Google Sheet.
2 Likes
I should clarify too then. I’m pondering about global values in the users table and user-specific values outside of the users table.
I still find all of these considerations not all that easy to work with, so the clearer my mental models the easier it is the build.
1 Like
Yeah, I also use the User Profile row to store globals. In fact I usually have a whole group of columns that I will prefix constants/
In those columns I’ll store things like the AppID, webhook URL’s and the like - static values that I might need to access from anywhere in the App.
For quite a while a few of us have been requesting a dedicated table type for this purpose, or at least some mechanism for defining and storing global constants that can be accessed from anywhere.
2 Likes
Oh gosh, I need to clarify again. What a mean by “global value” is a value that is non-user specific, a value that can be ready by any user of the app.
Yes, I understood that. And it’s also what I meant 
In the examples I gave, the values are stored in template columns, and so are available to all signed in users. Along similar lines, I often have a series of date math columns in the user profile row that return commonly used date values - 1 week ago, 1 month ago, etc.
1 Like
Gotcha. Using template columns for these is a good tip, I’ll use it 
Put them on a 1 row table and copy them with single value to User Profile… then it works for all users signed in or not. Very valuable trick.. reduce app bloat and make life a little easier
This means that any piece of data could be used globally. So if you need some value before sign in… calculate on 1 row table… instead of user table. Think about it
2 Likes
Yeah, I’m familiar with that approach. I don’t really like it. It’s always seemed like un-necessary duplication to me. I almost never build Apps where users aren’t signed in, so in my view it’s easier and simpler to put everything in the User Profile row.
2 Likes
Easy one @nathanaelb: I don’t see any advantage to use User-specific columns (USC after that) rather than storing data in Users table when you have Sign-in users:
- no access to data stored (as far as I know) which means no ability to get stats or analyses after the fact;
- you must define if it’s a USC or not when you create the column. In my experience, it can be difficult to evolve the data model and/or functionalities later, especialy if you want to give a smooth user experience;
- till now, I haven’t seen any drawbacks (such as bad performances) with Users table’s option.
Once this has been said, I’m sure I’m not enough experienced to make this statement a general rule and it relies on your context. Several Gliders who are references in my eyes use them, there must be a good reason for that - which I have not yet encountered 
I see a good reason to use user-specific columns for custom forms, calculators, and to set a user-specific value of the attribute of an item (such as a star rating of an item). Those are my main use cases.
That being said:
Custom forms
I avoid these. I know they are more versatile and more advanced than Glide’s native forms, but I’m comfortable using Glide’s native features. Given the choice, I will shy away from complexity.
A user-specific value of the attribute of an item
This is an interesting one. Until now I had never questioned this. I had always accepted that user-specific data cannot be used globally throughout the app for other users or for stats. However, if as you suggest a user-specific value were stored in the users table instead (always, no matter what), it would circumvent the limitation of the user-specific columns. Granted, that user-specific data would then be stored in a separate table.
I think using a user-specific column for a calculator is a natural approach which isn’t particularly complex.
1 Like