Join the Webstudio community

Updated last year

Improving token selection ?

At a glance

The post discusses an issue where the default token selected when switching between HTML elements is always "local", which can be confusing when editing parents and children. Community members suggest memorizing the last selected token to address this, either for the last instance or for a limited time. There are discussions around the trade-offs between preventing accidental edits and providing a better user experience. The community members explore different approaches, such as memorizing the last 3-5 tokens or having the tokens expire after a certain time. They also consider the needs of different user types, such as those who use "local" frequently versus those who prefer custom tokens. While there is no explicitly marked answer, the community seems to converge on the idea of memorizing the last selected token as a potential solution.

Useful resources
I might not be the first but everytime i go back and forth trough html elements, the default token selected is always "local".
When editing parents and childs this can be confusing. I expect be go get back on the last edited token everytime i switch html element. but the current behavior leads to either:
Messing with the local token before realising it is the wrong one
Constantly clic on the token i want to edit.

Also tokens with short strings are currently hard to select. They are too narrow.
O
L
T
68 comments
Short tokens - def a problem we need to address @Taylor
Reg default selected token - concern is that you end up editing something you didn't actively chose.

With local it's a safe thing to prevent accidentally editing wrong token, so it forces you to select the token.
I wonder what we can do here
I guess we could memorize 1 recent selected token
So when you go to the previous instance, it would still have same selected token, exactly to solve the case of going back, would that fix it?
Yes i think memorizing 1 token would do the job. Maybe it could be run trough a user test sequence too
I see how this can be frustrating for sure. Especially if you don’t want to style Local, you’ll have to deliberately select your token each time you switch instances.

As Oleg said, the thinking was to prevent the user from editing the wrong token by accident. Local styles can be converted to a token after all.

I agree that memorizing the last used token is a good idea. Let’s do that
I also have some design improvements planned that make the selected token a bit more visible and obvious, which will help prevent mistakes and make the tokens input a little nicer to use. This is a distant future thing though since we have other priorities.
Creating an issue then.
oh you were faster
@Taylor reading your isssue I am understanding this as memorizing the last selected token on EACH instance, not on last instance
what I. meant was kinda only memorizing token on the last instance where user selected a token
If I select token, then select different instance, then select the previous instance - token is still selected

If I select token, then select different instance and select a token, then select the previous instance - token is local again
Is there a performance reason that we can't do it the way I suggested?

bc my solution would be much nicer for the user if its feasible
It means users who don't use Local aren't constantly annoyed by it. If we can't use my solution then we have to find another solution to that problem. That extra click of switching from Local to the desired token can really slow down someone's workflow over time.
from ux perspective, if we are memorizing every token user ever clicked on every instnace, we basically completely loose the protection we created initially to avoid accidental wrong token edit
Are you sure? I think its the opposite
what we can also do is:
  1. memorize last 3-5 instead of 1
  2. forget the memorizatins after X seconds (per item)
So are you saying there are performance limitations or you aren't convinced of the ideal UX?
well after certain amount of clicks you don't remember what token is selected, so there is no way user will know what there is supposed to be selected, unless they look
another option is to not limit by amount but make them expire
so that we kindof assume for the next 10 seconds user still knows
and then it reverts back to default
deep down its a problem of
  1. whats the best default - we agree its Local
  2. how do we let user have the last thing they KNOW they have selected to stay selected
seems like user will know for X amount of seconds
User who uses Local in their workflow:
  • most often, Local will be their last selected token
  • UX for this user is pretty much same as current
User who doesn't use Local:
  • they never want Local to be initially selected
  • their last token is probably same as their desired token (most users won't have multiple tokens per instance)
  • they are saved from having to click the desired token every time. Imagne manually selecting the token you want for every instance. Can be a huge potential slowdown.
Users have to know what token they are working on or they will make mistakes. There's no UX that gets around this. We just have to make it easy as we can for them to worka s they intend.
they never want Local to be initially selected

Yes, but we also can't know what they want, so Local is just safe default that can't break much if changed accidentally
Actually we know that people change wrong tokens because it happened on our team already serveral times as we had situation where Local wasn't last token yet from the old days and the last selected token was literally some token and people changed it accidentally.
That's why I like my solution - because it's close to knowing what they want. Chances are, it's the last token they deliberately selected.
I agree, but lets time it out. You can't have deliberately selected it after a while.
If you work for 1h, you don't awant all instances to have selected tokens you selected like 30min ago
Can we time it out when user logs out?
I feel like users don't know what they selected last time within minutes
and they most of the time just need to. select something else, then return, its basically within seconds that they need this behavior
just like having something copy pasted into the buffer, you never know whats in it in like few minutes
I expect most instances with either have the Local or Local + 1 token.

As a user who prefers to work with custom tokens, I always want that 1 token selected because I never want to work with Local.

This is the user for whom this change is most impactful. For them, it's not a temporary thing, it's like a soft user preference. Remember the last token I worked on for as long as possible because that's probably what I want to work on again.
This user does not want it to revert to Local because that doesn't benefit their workflow
The user who uses Local will see no change
I agre if user has one token, with functional style we have 2-5 tokens on each instance and this logic breaks
For the user who likes multiple tokens, I think this is a net positive.

This user probably doesn't want Local to be selected automatically. It might even help them to be reminded which token the last used. They are accustomed to selecting their token intentionally because they have so many to manage, so they are not prone to inattentive mistakes.

It doesn't help them as much as it helps the 1 token user, since they are still selecting deliberately, but it helps a little and it doesn't hurt.
Local user: not much change
1 token user: huge benefit
many token user: small benefit
alright, lets try this
btw same problem with scroll position of style panel/settings panel
should we memorize it?
also what about last used panel: settings, style
Interesting question. I just tested Webflow and it seems they memorize scroll position per class. Not per instance or anything else
memorizing last used panel sounds good. So if you're changing settings for multiple things you don't have to switch out of the style panel each time
I think it's not a huge deal. We could not memorize scroll position, or make it per instance.

Probably doesn't make sense for us to memorize per token, right?

I have no strong opinion on this one
Webflow doesn't memorize the tab when switching instances
and webflow just memorizes scroll position generally
when switching instances it doesn't reset depending on last state on the instance
and since style panel depending on values has different positions of elements there, memorized scroll position basically results in jumping sections when switching between instances
Yea, I don't see much value in memorizing style panel scroll position so I say we leave that out.

Here's a demo of Webflow remembering scroll position based on class. Notice scroll position changes ONLY when a different class is selected, not when a different instance is selected with same class
it may be just accidentally what you saw, try this way:

  1. select instsance, scroll to a position
  2. select another instance ,scroll to a position
  3. select first one again
since panels have different sizes depending on content it may just look like its remembering simply because of where it is based on the same position for all instances
Oh you're right - it was all an illusion
So either we scroll to the top when instance is selected or try to remember and get jumpy behavior.

Either way is fine but if asked my preference I would rather go to the top of the panel each time.
Hey there, what you said is quite the inner debate i had with myself before commenting. The more i read, the more the taylor suggestion seems rational to me.
On another note, a good way to emphasis where the user sits with his token would be to get a color indication (either the selected element, or the pannel 🤔 ). For example, keeping the white/greys color for the local, and a blue one whenever a token is selected so the user knows that his action could potentialy impact many other elements on his pages.

I could use a figma file of the webstudio UI if it does exist to test things out
That's an interesting idea @Ludovic

I agree there is potential benefit to coloring 'Local' differently than the custom tokens. It needs to be a color other than gray though, as gray indicates an unselected style source.

Would you like access to our figma file to try out some designs?

We welcome community contribution! If you want to design a solution to a problem you're experiencing, that would help us make Webstudio better. Let me know if you need anything design-wise and I'll hook you up.
BTW this is my prototype design for improved style sources UI - shown with a ton of tokens applied as a test. @Oleg Isonen

  • more clear which token is selected
  • more compact UI
  • token options menu is more discoverable
    • no more hovering the token to reveal the menu button
    • this would help the pseudostates be more discoverable @Alex
Attachment
Screenshot_2023-11-07_at_8.34.11_AM.png
As i am sensitive to this topic i would contribute with pleasure 👏 . I could at least, prototype or anticipate solutions while commenting instead of just writing ideas like so.
Do you have a design system of any sort packed into a figma file?
Got it thanks
Following up in DMs so you can ask me stuff directly
Add a reply
Sign up and join the conversation on Discord