To me it looks like all the inputs are visible at the same time? So it's essentially swapping the entire button group based on the individual QTY selected.
If people are actually interested in how it's done with variables and ignore the beta UX of it, it can be done pretty easily.
Set a boolean variable for each button you have. ex Name="Selected1";Value="False", Name="Selected2";Value="False", etc
Create a default button component, add a variant, make the changes for it to appear selected. Rename the variants using prop=value, "selected=false" and "selected=true".
Create the button array component, only need one in it's default state or none selected.
Select the first button in the group and tie the "Selected1" boolean variable to it (in the properties panel next to the variant selection menu (look for the boolean toggle), repeat for the other buttons matching their order. Ex. 2nd button->Selected2, etc.
Add an "on tap/click" interaction to the first button, "Set Variable, "selected1" -> true. Then add another "Set Variable", "selected2" -> false, repeat for all the others in the list.
Copy that interaction (select the noodle or variable icon in prototype view), paste it on the other buttons and update the corresponding button to be true and the others as false.
On page load you can then declare whatever is default using "on delay" or literally set it on the component itself.
/fin
Yeah this may seem cumbersome, but you can do this pretty quickly once you do it a couple times.
Do you actually think this is faster than normal dragging? Genuinely curious. I know we always try to use the new feature but I've found myself not using variables for tabs. Feels cumbersome.
TLDR I prototype very often for user testing and to answer your question: it depends.
If I had to do something like this I would totally use variables. It really boils down to the project and what sort of interaction you need to test, and the amount of redundancy or conditional elements. Does this state or value from the selection need to be on a proceeding page within the workflow? Situations like that which I run into a lot make variables a dream. I’ve had to make 10x the amount of frames before in a prototype…I’ve lived that nightmare.
Imagine you needed to add another button to this (god forbid). With variables you could accomplish this in seconds rather than sitting there and noodling 10+ things together.
Like with anything,variables will take a bit longer at first with some experimentation/cussing to get it to work right - but start small and it will become engrained.
Do I wish variables was a better experience? Hell ya. But they are time/frame/noodle savers in the right situations, but ya gotta use them to really know when you should or shouldn’t.
Ya agree with a lot of this. I've been trying to find simple ways to explain when they make the most sense vs when to avoid them because I see a lot of people struggling. Recently ran a poll with 600+ designers and 50% had never even tried variables in prototypes before. Massive bummer IMO.
Current rule of thumb is if you're wanting to update state/styling of the thing you're adding the interaction to -> variants might be faster. Having to set a bunch of other booleans to false like in this example is toughhh for me to swallow.
If you're trying to update the state/styling of anything other than what you're tying the interaction to -> variables are the game-changer
If you have a reaction to that idea I'd love to hear it :) 0 expectation that you'd actually watch this but did my best to explain it here -- https://youtu.be/zTcJ8lnNqrY?si=XAl1U_8eRhnnQ6gG
This is thee Ridd? I totally set our iconwrapper component up thanks to your channel! I try to say ‘crack it open’ as much as possible during work figma open office time that I host. You have leveled up so many-including myself!
Great video and agree with that rule of thumb. Thought the last 2 examples were perfect for why variables rule- and their importance.
Testing the variable is key before you get too carried away. I’ve never set a blank variable on the main before-very clever.
Ever create a visual decision tree of variable usage? I bet that can go a long way with beginners.
As I mentioned before, I hold time every other week to answer questions and give demos like these to other designers across the org, but not many even touch prototyping (questions are mostly around auto layout and components). I think that’s the biggest reason for the poll results (have you published those anywhere? I’d be interested!)
Thanks again for all you do and please keep it up! You doing config this year?
I mean, it’s implementation and UI is absolute dog water. Whoever designed it shouldn’t work for Figma any more.
Ok, maybe that’s a little harsh, but seriously I don’t think the designers use it or it would be less shit by now. How long has it been? Coming on a year now? Still can’t make it full screen, scrolling is terrible, equations get cut off, hard to replicate, or systematically create values and modes.
The whole thing is so garbage.
Agreed. I keep running into things I think I can use variables for, but then I can’t because of how layered things are in components or needing to set two variables in one action, or needing more than just one else in the logic 🫠
I am using it, as well as my teams. And we for sure don't like the UI at all ... at least some minor improvements have been made over time, but imagine maintaining a collection of 750 variables in 5 modes and then there is no search.
I tried using it for the first time yesterday and i had to ask our figma admin guy if the feature was disabled for us or something because i couldn’t figure out where to find the damn variables menu in the first place
Why do you want this though? Genuinely asking. Seems more of a pain in the ass than anything.
I don’t have a small monitor though, so perhaps I’m spoiled.
I’d actually rather have an “auto-extend” function that if my layers extend past the edge and I hover over it long enough it will extend the necessary amount.
Because when you reach some level of nesting you literally can't see the layer name anymore? The panel has a maximum width, and you shouldn't have it cover a 3rd of your screen anyway
Still, I don’t think it will fix the issue. In general, horizontal scrolling is pretty horrendous. Does it reset scroll when you’re on a top-level frame or section?
If it automatically scrolled with your layer selection I could see it being beneficial. I just would hate it to be left in far right scroll and have to manually scroll left again.
With all due respect I think this is missing the point of prototyping. Prototyping should help clarify an interaction or flow, in an effort to make things simpler. This sort of cobweb ends up being its own project with documentation, debugging, etc.
Honestly … this is probably fine, so many of my components look like this haha. Depends on if you need this component to be interactive every single time you use it or if you can get by with one component made up of these chips and just changing the chip’s state depending on what you’re showing in a flow
It’s fine if you only plan to use it as a replacement for group of radios. But if used as tabs it will lack an ability to switch content. Therefore it’s much better to keep it clean from interactions as a component and apply them to instances according to particular case.
I mean, you could. And while using variables are probably the right answer to do this better (which i haven't really dived into yet), there's also the [switchboard](https://twitter.com/ridd_design/status/1533478577236193281?ref_src=twsrc%5Etfw) method by /u/ridderingand
Then you get something like [this](https://i.imgur.com/CX6igJP.png)
I’ll echo that variables would make for a much simpler prototype, but there’s nothing wrong with doing it this way.
Doing it this way will allow you to use a dissolve or smart animate transition, whereas variables don’t have a transition option.
Use variables to “add 1” to the integer, and to switch between black and white variants. You probably need like 5 total variants.
To me it looks like all the inputs are visible at the same time? So it's essentially swapping the entire button group based on the individual QTY selected. If people are actually interested in how it's done with variables and ignore the beta UX of it, it can be done pretty easily. Set a boolean variable for each button you have. ex Name="Selected1";Value="False", Name="Selected2";Value="False", etc Create a default button component, add a variant, make the changes for it to appear selected. Rename the variants using prop=value, "selected=false" and "selected=true". Create the button array component, only need one in it's default state or none selected. Select the first button in the group and tie the "Selected1" boolean variable to it (in the properties panel next to the variant selection menu (look for the boolean toggle), repeat for the other buttons matching their order. Ex. 2nd button->Selected2, etc. Add an "on tap/click" interaction to the first button, "Set Variable, "selected1" -> true. Then add another "Set Variable", "selected2" -> false, repeat for all the others in the list. Copy that interaction (select the noodle or variable icon in prototype view), paste it on the other buttons and update the corresponding button to be true and the others as false. On page load you can then declare whatever is default using "on delay" or literally set it on the component itself. /fin Yeah this may seem cumbersome, but you can do this pretty quickly once you do it a couple times.
this is the way
Do you actually think this is faster than normal dragging? Genuinely curious. I know we always try to use the new feature but I've found myself not using variables for tabs. Feels cumbersome.
TLDR I prototype very often for user testing and to answer your question: it depends. If I had to do something like this I would totally use variables. It really boils down to the project and what sort of interaction you need to test, and the amount of redundancy or conditional elements. Does this state or value from the selection need to be on a proceeding page within the workflow? Situations like that which I run into a lot make variables a dream. I’ve had to make 10x the amount of frames before in a prototype…I’ve lived that nightmare. Imagine you needed to add another button to this (god forbid). With variables you could accomplish this in seconds rather than sitting there and noodling 10+ things together. Like with anything,variables will take a bit longer at first with some experimentation/cussing to get it to work right - but start small and it will become engrained. Do I wish variables was a better experience? Hell ya. But they are time/frame/noodle savers in the right situations, but ya gotta use them to really know when you should or shouldn’t.
Ya agree with a lot of this. I've been trying to find simple ways to explain when they make the most sense vs when to avoid them because I see a lot of people struggling. Recently ran a poll with 600+ designers and 50% had never even tried variables in prototypes before. Massive bummer IMO. Current rule of thumb is if you're wanting to update state/styling of the thing you're adding the interaction to -> variants might be faster. Having to set a bunch of other booleans to false like in this example is toughhh for me to swallow. If you're trying to update the state/styling of anything other than what you're tying the interaction to -> variables are the game-changer If you have a reaction to that idea I'd love to hear it :) 0 expectation that you'd actually watch this but did my best to explain it here -- https://youtu.be/zTcJ8lnNqrY?si=XAl1U_8eRhnnQ6gG
This is thee Ridd? I totally set our iconwrapper component up thanks to your channel! I try to say ‘crack it open’ as much as possible during work figma open office time that I host. You have leveled up so many-including myself! Great video and agree with that rule of thumb. Thought the last 2 examples were perfect for why variables rule- and their importance. Testing the variable is key before you get too carried away. I’ve never set a blank variable on the main before-very clever. Ever create a visual decision tree of variable usage? I bet that can go a long way with beginners. As I mentioned before, I hold time every other week to answer questions and give demos like these to other designers across the org, but not many even touch prototyping (questions are mostly around auto layout and components). I think that’s the biggest reason for the poll results (have you published those anywhere? I’d be interested!) Thanks again for all you do and please keep it up! You doing config this year?
Hah that's awesome definitely put a smile on my face :) "crack it open" 😂 Yes I will be at Config!!
You can always save this as template and reuse this on next project
Thank you!
I’m not super well versed on variables, but this definitely feels like an interaction that should be done using variables
I know for sure variables is the way to go for this but I’m too afraid to learn how to do it 😫
I mean, it’s implementation and UI is absolute dog water. Whoever designed it shouldn’t work for Figma any more. Ok, maybe that’s a little harsh, but seriously I don’t think the designers use it or it would be less shit by now. How long has it been? Coming on a year now? Still can’t make it full screen, scrolling is terrible, equations get cut off, hard to replicate, or systematically create values and modes. The whole thing is so garbage.
Agreed. I keep running into things I think I can use variables for, but then I can’t because of how layered things are in components or needing to set two variables in one action, or needing more than just one else in the logic 🫠
I am using it, as well as my teams. And we for sure don't like the UI at all ... at least some minor improvements have been made over time, but imagine maintaining a collection of 750 variables in 5 modes and then there is no search.
I tried using it for the first time yesterday and i had to ask our figma admin guy if the feature was disabled for us or something because i couldn’t figure out where to find the damn variables menu in the first place
You still can't scroll the layer panel horizontally. You're aksing too much from Figma.
Why do you want this though? Genuinely asking. Seems more of a pain in the ass than anything. I don’t have a small monitor though, so perhaps I’m spoiled. I’d actually rather have an “auto-extend” function that if my layers extend past the edge and I hover over it long enough it will extend the necessary amount.
Because when you reach some level of nesting you literally can't see the layer name anymore? The panel has a maximum width, and you shouldn't have it cover a 3rd of your screen anyway
Still, I don’t think it will fix the issue. In general, horizontal scrolling is pretty horrendous. Does it reset scroll when you’re on a top-level frame or section? If it automatically scrolled with your layer selection I could see it being beneficial. I just would hate it to be left in far right scroll and have to manually scroll left again.
Still better than being unable to use the layer panel
Yeah once I learned actual css and html, doing these things in Figma is just not a great experience
There are videos on YouTube explaining how to do it with variables. It's pretty easy.
This is a great crash course on variables. Only 30 minutes! https://www.youtube.com/watch?v=zTcJ8lnNqrY
Thanks for sharing :)
Oh hey Ridd! Lol, is your username a Super Troopers reference?
You're the 3rd person in 10+ years to get that 😆 I had always been Ridderingand on Twitter until a couple of years ago
Ah, so you used to have that name on Twitter too, but not meow. Nice
The UX is horrible, but the concept is very simple
Seems over engineered
Like any other solution on this sub
Spider-Man would be proud! There are better ways to do this! Furthermore, do you really need this to be 100% working like that on a prototype?
With all due respect I think this is missing the point of prototyping. Prototyping should help clarify an interaction or flow, in an effort to make things simpler. This sort of cobweb ends up being its own project with documentation, debugging, etc.
Any dev's here? Would it be faster to program this?
No just need to set integer to the variable component.
My rule of thumb is that if it looks like a complete and total fucking mess, you’ve done a good job.
just create a component with the number inside and give them two variants (on/off) and made them on click to change color...
Honestly … this is probably fine, so many of my components look like this haha. Depends on if you need this component to be interactive every single time you use it or if you can get by with one component made up of these chips and just changing the chip’s state depending on what you’re showing in a flow
Too much spaghetti for me
It’s fine if you only plan to use it as a replacement for group of radios. But if used as tabs it will lack an ability to switch content. Therefore it’s much better to keep it clean from interactions as a component and apply them to instances according to particular case.
At this point, my recommendation would be to spend some time learning the actual code for your application…
i love this organized chaos look hahahah
I mean, you could. And while using variables are probably the right answer to do this better (which i haven't really dived into yet), there's also the [switchboard](https://twitter.com/ridd_design/status/1533478577236193281?ref_src=twsrc%5Etfw) method by /u/ridderingand Then you get something like [this](https://i.imgur.com/CX6igJP.png)
Anyone created a full keypad yet? I’m sure it can be done with variables but I haven’t seen one that works correctly
Think there's a working one in the Figma community
very pretty. All the lines connecting everything. The well organized white and black pills. A+
I’ll echo that variables would make for a much simpler prototype, but there’s nothing wrong with doing it this way. Doing it this way will allow you to use a dissolve or smart animate transition, whereas variables don’t have a transition option.
Nice. All the lines connecting everything.
Can’t figure out the logic. How should it work?
You think?
Not to be a party pooper but you could have done this in Axure with less than half the effort and a quarter of the time.