Beta 1 – Theme Options as a primary tab

I can guess why it lives there, but I’m not a fan of the Theme Options permanently sitting alongside the other content settings up at the top.

image

I change the theme settings fairly infrequently, so it strikes me as odd that they live with settings that will be changed fairly often.

Also, I keep accidentally clicking on that tab because the gear icon makes more sense to me for page settings than the toggle icon. (Especially since there’s only 1 toggle in the actual content settings)

I’d personally be OK with the only entry point to Theme Options being within the Hamburger menu. (I know the length of the Theme Options settings makes that tricky… but still, just sharing the feedback)

1 Like

Totally agree with this. The theme options is not a primary builder tool and is more a global / secondary theming tool. So definitely odd for it to sit within the active builder.

Personally, I think the Elements need to be in the primary builder pane (not the left bar / separate popout) and theme options should be a little settings cog in the left bar as an accessible global option (when needed).

Not sure if :point_up_2: that articulation makes any sense at all… :slight_smile:

Totally agree with this one. I would go as far as to say you could also take out the Content Settings button as well and only leave the primary buttons, which I would consider is the Content Outline & Inspector.

Maybe the Content Settings could go about the preview on frontend icon?

Agreed. So… purely hypothetical here but (@themeco team) what if there was the builder pane (outline, elements inspector) and then there was a settings pane that opened up the same way it does in the beta but just the settings isolated like so(ish):

So when actively building, you’d have just your builder tools. And when tweaking settings, you’d have have just your settings tools (content settings & theme options).

1 Like

Just to add, this :point_up_2: would also solve the element pane issue from the other thread…

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

  1. 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

  2. Potentially remove Theme Options from this release for simplicity sake and add it back with the Theme Options update.

Hi @alexander,

Appreciate the thorough response!

I love that Theme Options is accessible from anywhere in the builder. That part is incredible and is definitely not my point of discussion. And yes, Theme Options could be more useful (and sounds like it will in the future) but I don’t think that’s the driving force behind my opinion here.

Theme Options is still a global change that – even though it may affect things on my current page build – is more widespread than that.

Outline directly involves my active build.

Inspector directly involves my active build.

Elements directly involve my active build.

Settings and Theme Options are not isolated to my active design (page title, layout / stack building). So even when Theme Options becomes more robust and is essentially a Stack builder it still (IMHO) doesn’t make sense living in my active workspace (maybe workspace isn’t the proper terminology – but I’m referring to specifically the outline/inspector pane).

CSS can be both page / global so it makes sense to live outside of my builder pane
JS can be both page / global so it makes sense to live outside of my builder pane
It seems like settings would make a ton of sense functioning exactly as they do now but but in their own “settings” experience and the builder pane would be for just that – building.

I have no problem improving / changing my workflow but just to give you insight into how I typically build: I spend most of my time in the element pane + inspector. So, as you can imagine, it was frustrating to have to mouse click, reposition popup, search, drag, close, repeat.

I guess, in a nutshell, I totally get the need for bumping things out into the side bar but why not make it things that aren’t directly associated with the active design.

Love the dialog so thanks for taking these ideas into consideration :slight_smile:

I see your point here. We actually went back and forth quite a bit internally with some spirited discussion because it’s difficult to quantify what the idea of “my active build” (to use your words) is for any given users. Just within our own team it was pretty split and some viewed Settings/Theme Options as more prominent.

Truly, there’s no right or wrong way of looking at any of this. It’s all very subjective and based on personal preferences. Even with our team it was hard to get consensus, which I think is a good thing because it helps expose how many different perspectives are possible

Because there are so many ways people find their own workflows and approach building things, we had to take a step back and find less subjective criteria.

When you interact with Outline, Inspector, Settings, or Theme Options, you will want that interface to remain open and you will be observing changes in the preview area (not clicking the preview).

Interacting with Elements is actually a hybrid action that involves the preview. You don’t actually do anything inside the panel and watch things change. Rather it’s more of a transient interface used to get elements into the design.

In that behavioral respect, Elements becomes the the odd one out - but again, it’s all perspective and there’s no right or wrong here. If we had one more primary panel we’d probably have to start over with the organization :smile:


Long term, I’m really intrigued by the idea of multiple workspaces instead of one. Imagine when you dragged “Inspector” it would tear off like a browser tab and you could snap that to a different edge of the screen. You could have a workspace docked to each side for example. This would be really helpful on larger screens.

Near term, and before the official release, it is clear definitely need to improve the experience working with elements. The next patch has the preference to auto close it, but we really need to explore some snapping ideas so you’re not interrupted by it covering the preview area, and potentially covering the area you need to place an element.