Great feedback here. This topic (and bleeding into the Elements pane discussion) is something we’ve had hours of internal discussion unraveling. We were definitely expecting it to come up in beta feedback and have been looking forward to discussing it. Let me kinda of unpack where are heads are at, and we can keep the dialogue going from there.
First off, we’re on the fence about leaving it there for this update, but think that will be the eventual home with the Theme Options update on the horizon.
Transparently speaking, there isn’t much to do in Theme Options right now, and in a way it could be highlighting that weakness. The way sites are built with Pro are heavily focused on styling elements themselves, and repeating that style. So you’re right, it’s not something you will be using often at this time.
When you are in the standalone Theme Options, and you see an element in the preview, there can be a bit of a disconnect that you can’t directly edit that thing. You have to leave and go edit it somewhere else, then come back. One way to solve that is invert the problem, and make Theme Options adjustable from any builder.
Something to keep in mind is the next big cycle will be the Theme Options reboot, at which point you’ll basically be designing your own stack from hundreds of controls under Theme Options. These options will determine your site Chrome, and have more widespread effects over Elements.
Imagine the use case of configuring your site’s base level typography options. You could be working on a page and add a whole bunch of headline elements, then you could go through Theme Options and configure how your typography is laid out from a global perspective. This has less context switching because you don’t have to go back and forth between Content Builder and Theme Options to make adjustments to the actual global options, or the content you’re viewing it on. It’s just a matter of toggling the workspace tab.
And finally, and more of an aside, bringing the Theme Options experience into the builders is what allows Global CSS and JS to seamlessly be part of the code editors.
TL;DR; It is admittedly less useful now, but will be important when Theme Options allow rolling your own stack.
Why the Settings tab?
One of our goals was to bring consistency in the experience of using all the different builders.
- There were things related to headers/footers (Assignments) that were managed on a separate screen.
- The page builder settings were in the main settings modal, but in a tab that would hide and show depending on if you were in the content builder.
We consolidated this by bringing back the old top level Settings pane from Cornerstone V1 and making it the home of anything you change directly related to the entity you are working on. Those settings will be different depending on the builder you’re working in, but at least you can start associating that screen with top level setting changes.
Why move Elements out of the main workspace navigation?
So now we have 5 tabs… (Outline, Inspector, Elements, Settings, Theme Options) it’s getting pretty cramped up in that workspace navigation… @Maratopia_Digital and @DoncoMarketing you’re basically going down a similar path that led us to a different conclusion, but yet the logical thing would be moving one of the interfaces into a bar icon. We opted for Elements for a few reasons.
Originally (early versions), the elements pane would stay open after you dragged an element. By popular demand we changed the behavior to immediately inspect new elements at the cost of not being on the Elements tab anymore. By making the Element library standalone, we can support both approaches. The element is still immediately inspected, but you don’t lose the library.
Of the 5 interfaces (Outline, Inspector, Settings, Theme Options, and Elements) the elements panel is actually the least like the others. It is the only one that lets you directly interact with the preview pane. And it’s the only one that doesn’t have controls that can be adjusted to trigger changes in that area.
In a perfect world I’d like to explore the idea of multiple “workspaces”. For example, you could have Inspector on the left edge and Outline on the right, and each could have any combination of tabs. This is a taller order programmatically and while I’d love to explore it we’d be introducing more delays to the update.
Summary and Potential solutions
-
Make using Elements less awkward. Please take a look at this thread: Beta 1 - Elements Floating Window We have some ideas on improving the experience of the Elements panel there
-
Potentially remove Theme Options from this release for simplicity sake and add it back with the Theme Options update.