which is why I want to make it more consistent and make them reset any section
not just the layered sections
that means title would always be a button if the value is defined
that means that if the value is set title can't be used for collapsing/uncollapsing
because it becomes a button
or alternatively it never works for collapsing consistently
probably this is for the best to be consistent there
but the point is my indication with chevron helps to see what is a collapse trigger and what is not
when you hover the button-title it doesn't show chevron, it always shows when you actually can click to collapse/uncollapse
Understood now. One likely cannot avoid such structural inconsistencies (here, Section Name is also Property Name / Button).
Deactivating Click on Section Title to collapse sections should cause little effort and would teach us, to always click outside the label to expand and collapse.
Also Chevron on hover teaches
Google Login returns Localhost refused to connect. GitHub is inactive and I have no secret. Just to let you know. I've seen your clip and can wait for the update 🙂.
we have auth secretfor staginbg
its in the pr description
just so you know how to try prs in general
this way you can test anything we are working on any time you want 🙂
It's helpful, but looks a bit dense. Maybe using a lighter grey for Chevron was in order. Due to flashing, it should still grab attention. Used Grey found in your Inputs.
subtle vs secondary (from our ds)
I tend to go with the first one - not too dark, not too light
Arrow on hover should be hidden when there's nothing to fold / unfold.
maybe, I thought though its useful to see its empty when clicking, I think its a minor detail
I ran into this too. I think the arrow should be hidden as well. Very minor though
I will note though that the initial problem was that at a glance I couldn't tell which panels were collapsed or open. The hover effect doesn't solve this
yes, this is a general solution to the problem of understanding what's the collapsible trigger there
and the afct that its collapsible at all
without it most people won't even know you can collapse
your problem is solved by the colored dots
in style panel it was never the problem, I think you made a screenshot with it as an example and mislead us
the problem you had was with properties panel
I still find Section-collapsing in Styles flawed. The newly introduced arrows don't solve all existing problems, and they cause new issues.
- Collapsing ambiguous with + sections
- There's no proper place for arrows
- Collapse triggers are inconsistent (click in/outside Title)
- indicator dots (for settings inside collapsed sections) require mental transfer and are not immediately actionable
The reason for collapsing Style panels sections that I can see are:
- Hide rarely or never touched properties (=remove mental load)
- Reduce input delays (less scrolling)
Here's an alternative way to deal with this problem.
Sections were no more collapsible – but one could hide them from view.
Screens 1, 2 As soon, however, as an element gets selected via Navigator or Canvas
that has properties from a hidden panel set, it gets shown as a temporary panel in a second row
Screen 3. That panel is immediately actionable, you see modified properties right away.
This looks too busy?Webstudio uses Flyout panels anyway (> apply font).
Screen 4It's tedious, that you need to access a context menu if you want to add a rarely used property.Well, you will have had reasons to hide it. With the upcoming Spotlight Style Command-Panel, this problem would go away anyway.
There were options to make visible panels even more context sensitive, but I leave it for now.
I need to process what you just wrote, will answer tomorrow!
The biggest reason why its hard to do that contextual panel hiding is because on the web any element can receive any styles, even though normally you would use a different element.
So hiding panels based on what component is selected is probably going to be weird
If user would hide things manually, lets say I don't always need outline or transitions. Then once I need them in a week or so I will need to enable that panel to change it. On principle additional click isn't a big deal, but it needs to be extremely easy and natural to find those panels and turn them on/off. I am not convinced yet menu on top will do it
On principle, when panel has no items inside, like the box shadows, filters, transitions, it doesn't take much space. So, is it really worth removing from the view?
These empty panels won't really help with the problem 2 you mentioned and probably won't fix much problem 1
bigger panels like typography on the other hand - yes it would be nice to have them only when needed but then again, its difficult to know when they are needed, I guess typography, size, layout, spacing are frequently used once.
Opening panel when there is a set property is definitely doable, but this only works if we can hide them in the first place without causing frustration in finding them initially
More thoughts, lets imagine we did it and I hid box shadows panel. Obviously I don't keep in mind which panels are hidden, so next time I need it, first thing I do is scroll and look for it where it was in the panels list, only later realizing that I hid it and now I do 2 clicks to enable it and probably scrolling again. Now if we imagine more beginner users or users who don't use it frequently, they might have even forgotten they hid it and might be even struggling to find how to show the panel again.
Last but not least, users who don't even know what they are looking for need to somehow be able to find the panel, which could be potentially workd around by showing them all initially and only letting user hide manually, but then again I am not sure person is generally smart enough to rememember what they hid.
For professionals who use often, it might be even a problem that in the moment of building, they might just not realize right away they hid a certain panel and then it takes some thinking to realize that.
I think in general hiding panels that are not used is great, but I struggle to find a way that will with 100% certainity lead to quick recovery of the panel
I understood and described the case that elements may have unexpected properties assigned: An old project of yours (where you cannot remember how you solved something). Other people's work, that you're totally unfamilar with...
What I suggested, offers a first class handling for hidden panels: Right in the face, instantly understandable and editable.
Currently, with collapsed panels, you serve abstract colour dots on a collapsed section. These collapsed sections do not automatically scroll into view, you may have to scroll first. Next, you have to understand the dot-symbol. Then you have to uncollapse the section – and have to know how that. In Webstudio, you – unintively – have to click outside the Section- Label, as Labels may also be buttons.
It would not be a disadvantage to hide sections from residing permanently in the Styles panel. It would rather be a display preference. Thinking of the upcoming Spotlight-like UI, advanced users could configure their style panel with just the most important elements always on screen – this could e.g. be the Advanced section. In my screenshot I also snuck an option to reorder sections...
Tools like Photoshop offer a similar property window that may repopulate and re-size, depending on current selection (on canvas, other subwindows).
I believe that people will be very hesitant to hide elements they will use. Customizing UI is something people usually start when they know what they are doing.
Tools like Webstudio or Figma have ridiculously shallow UIs compared to almost every advanced desktop software. Any Adobe App, every advanced 3D modelling app, table applications… they all hide tons of vital creation-tools (for certain contexts) in Menus, Submenus and Subwindow Context menus.
They don't do this, because they suck at GUI-Design. It makes sense. And their professional users can handle it.
Those who look into Webstudio are willing to face some complexity, too. There are better options for those who only want to vary some manufacturer-supplied templates.
- The solution you mentioned only solves cases where you have set property, this is nice but incomplete
Currently, with collapsed panels, you serve abstract colour dots on a collapsed section.
- Well the color system is consistent with labels, it needs to be learned in any case. Dots are there to indicate there are set styles, I think this is relatively intuitive, but ofc you can argue with that
. These collapsed sections do not automatically scroll into view, you may have to scroll first.
- Yes but so will you if you have more panels than you can fit into the view
Then you have to uncollapse the section – and have to know how that. In Webstudio, you – unintively – have to click outside the Section- Label, as Labels may also be buttons.
- we don't save the collapsing status forever, so if user knew how to collaps, they will be able to uncollapse as well, though i do agree it would be nicer if the enter header was a button, we didn't have a choice with multi-layer panels
It would not be a disadvantage to hide sections from residing permanently in the Styles panel. It would rather be a display preference.
- The trouble is how do you know what people need most of the time? I know the outline and maybe transitions are not needed all the time, but I don't know about the rest.
Tools like Photoshop offer a similar property window that may repopulate and re-size, depending on current selection (on canvas, other subwindows)
- Yes that's our "Floating panel" as we call it
I believe that people will be very hesitant to hide elements they will use. Customizing UI is something people usually start when they know what they are doing.
- So the optimizations you are proposing are for advanced users, for all regular users the experience would stay the same, we would be replacing collapsible sections with hiding sections via a menu, right?
Those who look into Webstudio are willing to face some complexity, too. There are better options for those who only want to vary some manufacturer-supplied templates.
Sort of, webflow for example is also being used by marketers a lot and for wider adoption you also want to be as beginner friendly as it gets, especially when person is learning the tool.
Overall we are not discussing the fundamental look of style panel here when user opens it for the first time.
What we are discussing is replacing collapsible panels with a list of displayed/hidden pannels over menu and then showing the panel even if it was hidden from menu in case it has a defined value.
Lets sleep on it a bit more. I am not happy with the current state either. TBH I am never hiding panels and I would find it very annoying to have to open and close those panels every time I need some value, even if I see the dots.
Making the panels open by default when they have a value makes sense to me. I guess the question for me is if I would ever hide any panel via that new menu.
I think I would potentially hide outlines panel but that alone won't save much space.
It would be nice for borders to have less space by default when not specified, but I would need borders on a lot of elements in general, wouldn't hide it by default.
I think the logic when I would hide something and how to make sure its visible when I needed needs more thinking
Btw webflow has focus mode, which turns sections into accordion, so you never see more than one open section, the rest is always collapsed, did you see it?
I find it problematic as well, not sure who uses it
Overall we are not discussing the fundamental look of style panel here when user opens it for the first time.
5) Yup. The app appearance would not change.
The default appearance would be showing all sections.
Resetting (in my screenshot) would restore the default config. Offering to dock a floating section (screenshot) would make it permanently visible again.
7) Correct.
My main point is that I don't consider your Style Panel collapsing solved convincingly. It conflicts with the (great) button-nature of your section labels.
TBH I am never hiding panels and I would find it very annoying to have to open and close those panels every time I need some value, even if I see the dots.
Neither would I, as a Learner.
With options to hide and re-arrange, I fast-forwarded a bit, indeed. Customizing default entries will make more sense, when you can quickly add via Hotkey or Spotlight-style Popup what you need.
There is another idea that I can think of: hiding panels that don't have a user defined value, but showing panels that have a default browser value.
E.g. a button has a border by default. Having that panel visible allows user to see that and delete the border for example. If I were to hide that panel because I hid borders panel, it would be not practical in case of a button. where first thing everyone does is overriding borders.
Btw webflow has focus mode...
I know a similar implementation from my RAW editor. Could be useful for people who use Desktop by default (and know where to look) and only have a Tablet with them, while travelling.
I think
initial discoverabilty is crucial. Once you know that something is there, chances for rediscovery are much better. One of my CAD programs is Commandline driven. After half a year of pause I may have forgotten single command-names. But I know the function is there.
its kinda as if your menu with hidden/open panels would not be used manually (referring my previous message)
Overall the idea with menu feels like another half-baked approach as we have with hiding panels or webflow with focus mode.
It seems useful as an idea, but practically, I won't ever want to hide/show panels all the time.
But I think this direction of thinking may yield some truly universal solution
A big problem with sections in general is that some of them are not 100% known to contain certain properties
We tried to solve it as much as possible, in case of webflow its much worse
E.g. their effects section is completely not intuitive
The problem with knowing what property is in what section is not only about learning it once, but when I need a certain property, remembering quickly which panel to open, without mental gymnastics.
Maybe another way of thinking about it is pinning/docking - I define which sections are ALWAYS visible, no matter what, the rest will be visible depending on context I mentioned before:
- user set a value
- browser set a value
so this way the broders and outline sections will be gone most of the time
In figma you don't ever have to manually pin/dock sections though, they are contextual without any manual setting up
This is actually an ideal model imho, though it seems figma has waaaaay less sections compared to us
I wish we could find a way to compliment this idea with some kind of UI that would make accessing hidden sections super easy/fast. Fasster than a dropdown menu in a corner of the screen.
In theory headers of collapsed sections is effectively a very visible and fast way of accessing a section.
I don't know how much trouble is it having collapsed section headers visible all the time if we could apply automatic expanding based on context.
hiding panels that don't have a user defined value, but showing panels that have a default browser value.
There were many options to make the Style panel more context-sensitive (now assuming that there are ways offered to access the functionality through hotkey or Popup and edited properties are marked or shown in a Flyout)
For my own projects I could rule out to ever giving text a shadow. Hence, with a text element selected, that shadow-section would not have to sit in the Style panel by default.
It also appears as a valid approach to store section visibility by project. Many programs allow you to store Layouts by work-context (Photoshop Retouching vs Painting). This would be a variation of that mindset.
What's the most annoying part today when you have all panels open? Like real pain point?
Scrolling too much? Seeing too much? Seeing things you never need?
My main point is that I don't consider your Style Panel collapsing solved convincingly. It conflicts with the (great) button-nature of your section labels.
I would consider an improvement to turn collapsing off.
Yeah, I think turning it off in style panel won't hurt the style panel overall
if you currently don't use collapsing at all, its probably not hurting either, its just not very useful
What if we added a setting "Collapse automatically" and would simply collapse sections when they don't have values (no browser defaults, no user defined)
If I was an advanced user of your app, I would likely want to slim down the GUI, quite the way I do everywhere else. I want to have orientational panels visible at any time: Layers, hierarcharchical structure. Stuff that provides readout value at any time – even when not interacting with them.
Now you will correctly say that every section may acquire this readout quality, by showing its own or inherited settings.
Which for the specimen of user I decribed supports the statement that not everything has to be visible. If sections with nothing at all set were hidden, but you know that you can access them via Hotkey or Popup, this sounds like a clear arrangement.
I am still debating the "completely hidden" vs just collapsed, the benefit of being collapsed is its accessible and discoverable without shortcuts
I think, for now, you cannot afford full hiding, correct. Once you have Hotkeys and Popup you could offer this option.
Have you considered a hotkey + autocomplete to search all properties in the panels? I think Webflow has CMD+E or something to reveal a search of all components to add.
The idea would be that when you want to find some property in the Styles panel, you press CMD+E (or whatever) to show a search dialog and start typing the property name.
There's autolcomplete, so you find the property quickly, then select it and press Enter or something and the Styles panel jumps to the correct section and property field.
yes we already designed it, its waiting to be built
but it won't solve the fundamental problem with the style panel
if you don't know what to type you won't find it
that's why all the basics need to be discoverable visually
that's why all the basics need to be discoverable visually
A related issue is the division between basic CSS properties (selected by the Webstudio team to appear the Style panel) and what's considered advanced / less frequently used. For users, it is not at all evident or even memorable, which CSS property belongs to which group. That may be a problem for debugging.
The Section
Advanced does not answer this question. Yet, it quite easily could.
Right now, the Advanced Section in idle state seems to list pre-applied
sane defaults. As soon as users start adding new properties to Advanced, they create a mixed list with
project-defaults and
less popular CSS-properties. What's missing are the basic (GUI) properties.
I added a few filters in my screenshot. GUI would, of course, only add properties which carry values.
Yeah this could be interesting in the future
Central place to change any styles
