I agree that the UX of inline editing is not great for the end user. Especially if they accidentally remove an element from its place because of its sensitivity. Perhaps a page-level option to lock the UI (prevent dragging), would solve a lot of it. But also it would be great to make it more smooth. I have seen drag&drop web solutions that feel very confident and reliable. Not sure what libraries were they using. 
1 Like
Wasn’t expecting per breakpoint styles this cycle, what a nice surprise
I think that the approach you’ve laid out here is really good and logical. It makes sense that you select the viewport you want to edit and that the changes you make there are reflected in just that viewport, so much better than if you crammed these options into the controls. Like others have mentioned before, an option to make the XS viewport the “global” style for mobile first development would be very nice.
The fact that the builder UI will become even more customizable is great too, I am already quite happy with the current options, so no complaints there.
Not sure how I feel about the Tools dropdown though. Especially for the Color Manager it’s probably too small to comfortably manage a lot of colors. Getting claustrophobia just from looking at that screenshot 
Here’s an idea, what if you implemented the Color and Font Managers into the “Expanders” area. You would be able to edit these things there and see the changes you make in live in the preview, unobstructed by any dropdown or modal.
Overall you’re definitely on the right track and it’s looking pretty good. Can’t wait to try the beta!
Yeah, I would prefer to see colors in a UI (whether it’s a dropdown, modal or whatever) that has a fixed width, so that the colors don’t jump around.
1 Like
Hey @kory,
Awesome as always, can’t wait to get mitts on.
QQ related to related to breakpoints, shall this release at last deal with the responsive image issue?
Understand this on the tracker for some years and is a pain point that even working with a mobile first approach, one of the largest page assets are images. The X/Pro Image Element does not support responsive images and both builders disable native Wordpress Responsive images. The end result being, even though a pages build with X/Pro look incredible but they are anywhere between 2-times to 10-times+ bigger than it need be.
Its would be good to see this resolved. WordPress understood since 4.4, now 5 years ago. Realise you’re well aware this significantly and detrimentally impacts site and page performance, seo ranking and client revenues.
Proper responsive images starting from mobile first approach is a must have, certainly for img tag… if this was extended to CSS background-image property that would be a dream come true! 
If this is not still possible in this release, I ask at a minimum please include a reliable way and consistent way to re-enable native Wordpress Responsive images for all non X/Pro Image Element images.
@alexander has kindly provided code in the past, however whether it works or not differs between code changes through versions of X/Pro.
Hey, everybody!
Lots of great activity going on in here! I’ll do my best to try and go one at a time and respond to everything personally, although some things might get answered in a reply to another person, so do make sure to read through everything:
@Misho, sounds good on the lockable / draggable breakpoints in the builder. This is something we intended to do anyway, so great to hear that this is important to you as well! As for the concern on losing more vertical space, I can definitely see this as a concern and understand the importance of wanting to move the bar to the side potentially to save that space. Of course, doing this will mean we “lose” the ability to do some other neat things if it was fixed at the top or bottom, but perhaps the flexibility here is more paramount.
As for finding certain settings within the “Inspector” pane, I think the tricky part here is that Pro’s Elements are “multi-dimensional.” If you were to compare to something else like a Webflow where things are more flat, it’s easy to group all like controls together because you’re pretty much building everything from scratch. You place one div or p at a time, style it, and if you want functionality, you have to wire it up, et cetera. In this way, everything essentially has one instance of necessary controls (typography, box model, et cetera). With Pro’s Elements, even the most ostensibly simple Element can have multiple layers to it that need to be accounted for. For example, the Button having multiple lines of text that may or may not need to be independently styled means that we have to introduce two full sets of typography controls into this one Element. Of course, we’ve done things to hide controls that aren’t in use (such as turning off the Secondary text in the Button, et cetera), but I do understand and have personally felt much of what you’re speaking to myself when building out pages myself for Design Cloud or personal projects. This is getting a bit off topic for this thread, so I don’t want to focus on it too much, but I did want to just mention these really fast as ideas that I think might help (again, understanding this particular issue is not necessarily part of this cycle, but these are some things we’ve discussed and are hoping to get in):
One, we plan on adding an on/off switch to certain controls such as box shadows, margins, et cetera. There are many controls that you may not wish to use at all, or you may wish to style and then have a simple way to completely disable them to compare these two states. The addition of this control will help greatly as you won’t have to “zero out” all the controls in a box shadow to remove it for instance. The idea we’re exploring is essentially putting a mini-toggle in the upper right corner of each control box like so:
And if disabled, it would collapse the controls within like so, reducing the overall vertical space in the Inspector as well:
You can imagine the impact this alone would have in terms of cleaning up unused controls and getting them out of the way while editing.
Another piece to this puzzle I have proposed internally is adding some type of “accordion” type pattern that matches the navigation for an Element. For example, the Button Element has many different sections such as “Setup,” “Design,” “Text,” “Graphic,” and “Particles.” The idea being that you could collapse a whole section of controls at once so that you can easily focus on exactly what you’re after. So to your point, if you’re trying to adjust the text of something, toggle the other sections closed, and then you’ve greatly reduced the scrolling space you need to traverse to get to where you’re going. Below is a greatly simplified example of what this might look like:
This is kind of like your tabs idea, but keeps with our current navigation convention. Rearranging the controls like you’ve mentioned under completely different tabs would effectively be a re-mapping of everything, which can be tricky and very time-consuming. Would love to know your thoughts here.
As for units being changed on click, perhaps I’m missing something here, but you are still able to type into an input directly and adjust units. We added the unit picker because remember, we also have to help “hand hold” a little bit fore more inexperienced users (and the unit picker also serves as a way to show the “valid” units for any particular input). But you can still click into an input, type in 10rem for example, then hit “enter,” and it will automatically update to rem on the unit picker. I personally agree that I liked the inputs without the picker and just liked inputting manually, but we have to take all user levels into account to some extent, and you can still certainly enter by hand, it just requires an extra “enter” to force the unit update. Perhaps we could explore a “power user mode” or something that takes these away and goes all manual? Just a thought that is occurring to me in this moment.
@icologi, sounds good on the color front, and I agree with implementing some type of tooltip across the different contexts (in the picker, and the Color Manager). I often create palettes with many similar colors, or even the exact same color, but for a different purpose (e.g. box shadows for two different Elements that are the same, but I want to leave separate in case I wish to change one in the future). Having that contextual help when hovering would be very nice.
With regards to setting an element’s default behavior, just to ensure we’re all speaking to the same thing…this is currently possible in the builder. If you have created an Accordion style for instance that you want to be the “default” any time you drag in that Element, if you save it as a preset and then go to “Templates” and then click on the settings modal, you’ll see this screen:
Notice in this example, we have a few different presets to choose from for my Accordion Element in my local install. I could select any one of these saved presets as the default and the next time I drag it in, that style will be applied automatically. If there is something different you are both referencing here, please feel free to expand on the idea more! I just wanted to make sure this particular features was known to all during the course of this discussion.
Finally, please see my notes about the units that I left in my response to @Misho. With regards to the text editors on text inputs for Elements…this is yet another example of how some people have very strong opinions either way, haha. We initially launched without those editors because personally we also don’t care for them much…but there was a large contingent of users that didn’t like this and effectively voiced that it broke their workflow in many ways. This is the tricky part about a tool like Pro and trying to cater to many different workflows and many different levels of user…but perhaps something like the idea I mentioned in my response to @Misho in having a “power user mode” that turned these things off could be beneficial. Or simply independent preferences for each of these (e.g. “Enable Unit Pickers,” “Enable Rich Text Editing,” et cetera). Would love to know everyone’s thoughts here.
@JvP, great to hear from you! Yes, we’re very excited about the responsive styles this cycle as well. Looking forward to having that in natively. Totally hear you on an additional vote for mobile-first…I’m seeing a trend here, haha. Again, as mentioned previously that’s kind of a side-issue to simply getting in the responsive styles, and if it proves to be too tricky for this particular cycle, we may need to move that back some, but I would personally love to see that switch happen if at all possible.
As for the Tools dropdowns…once we have this dialed in a bit more I’ll share with you all some things I’m exploring there. I certainly appreciate the concern of it being cramped as it’s one I share, but in playing around with some ideas at the moment, I think we’ll be able to strike a good balance there. In addition to that, the positives of being able to see the live preview while editing colors / fonts, consolidating tools, et cetera all feel like big wins for this move as well. Additionally, we will definitely work on making sure there’s more parity between how colors are displayed in the Manager and the Picker moving forward.
@strobley, thanks for writing in! Responsive images are not something that was part of this initial planning for this release cycle, but I will certainly take some time to discuss this with the rest of the team on Monday. @alexander is currently out of town but will be returning then, and that will be a good time for our whole team to go through this thread and discuss things in much more detail. I can’t guarantee anything at the moment, but I certainly do understand the need for this functionality. As with everything, there’s a dance to balance out what feels like the most pressing thing at any given moment. Once Alex is back, he and I will be able to discuss this in more detail and see what might be possible or if we need to do more proper research and move this to a dedicated release cycle. Thanks!
Whew! Hopefully I got to everything…this is great, guys! Keep the responses coming, the insight is truly helpful to us all!
1 Like
There’s a lot to go through here, so apologies if I throw things in over a few days.
First, I want to +1 @Misho’s feedback about the canvas preview and being able to scale down to narrower widths. That’s been on my wishlist for a while too, and I like the handle options you’ve described. I also would appreciate being able to preview the screen heights of popular devices too. This comes up most frequently when I’m trying to dial-in the parallax effect for the background of a section, but there are plenty of times where I need to check whether something is above or below the fold of a common device like the iPhone 8. I’ve had to do the “save the page and preview it in another window using the device previews built into Safari or Chrome” dance, and that gets old.
+1 on the feedback about needing to click into text fields. I appreciate being able to use a rich text editor occasionally, but don’t like that I’m always forced to do the double click dance to edit all text. I hear you on the reasons why it is that way - but some form of solution to make editing simple text quicker would be nice.
On the subject of editing elements, perhaps this is just me, but when I think about editing an element I think about the content (text, images, graphics, links, etc.) and styling as two distinct things. And I really don’t like how spread out the content gets within the V2 elements. For example, when editing a headline, the primary text is up top and easy to get to, but then the secondary headline is buried within the text settings down below. I assume it’s done this way since you can turn on/off the secondary headline… but it still creates a lot of friction for me when I want to make quick changes. I too have the same problem with the inline editing as noted by other folks – and it’s seemed to have gotten worse since the last release (at least for me). So, I personally kind of wish that all the content was grouped together independent from the styling so I could make quick changes to all of it.
Your Accordion Concept
Love it. Love it. Love it. Love it. Love it. I would just want a way to collapse them all quickly.
On-Off Toggle for different styling
Thanks for this 
Quick thoughts on the horizontal bar.
- I really like undo/redo being exposed.
- I like CSS and JS being accessible from the top level of the bar
- I agree with your team’s concern about getting rid of the vertical side bar entirely. It’s a tricky problem to solve, and I’m not 100% sure how I feel about needing to either have one really tall double-stacked bar, or having them spread out across the screen.
Unit Pickers
I also still have a problem whenever I use calc() in those fields… as I can’t see anything because of the unit picker. So, something to address all these concerns would be nice.
Other feedback related to the tools
CSS Editor
I’d say 70% of the time, the CSS editing window is too narrow for me. Especially with the V2 elements, the CSS classes can get quite long, and I have to scroll left and right a lot. For example, .x-text-content-text-primary runs right off the screen:
Most of the time, the full screen CSS window is overkill for this particular problem. It would just be nicer if the editor was a little wider. I only bring this up because of all the talk of restructuring the tools, it might be nice if there was a way to make that panel wider. (I know its dimensions are dictated by the workspace panel, just sharing)
Adding Elements
Again, while talking about the tools… since Elements and Inspector share the same panel in the workspace, I understand that it makes sense to have the workspace switch from the elements tab to inspector tab when you drag a new element onto the canvas. However, I often find myself wanting to add multiple elements in quick succession, so it can be cumbersome to need to switch back to the Elements tab – which resets every time - then scroll down to find the next element I want to add, then go through the same thing again and again.
The reason I bring this up is that you said the font and color managers could float on screen so you’d see changes on the page as they happen. Well, I could see a world in which there was a global “add element” button that could function similarly, without losing its place every time someone added an element. For example, there’s a “+ element” button in the bar, and when a user clicks it, a drop down appears (similar to the one that appears if you click + on a column in the layout tab). A user could then search or scroll within the elements, and drag onto the canvas. However, the dropdown stays visible on the screen, and does not reset each time an element is dragged out of it. So, a user could go back and grab another element quickly, then just close the drop down when they were done.
Of course that’s a notable change from how things are arranged today. So, perhaps as a stopgap measure, the elements tab doesn’t need to reset every time you drag something out of it? Or maybe there’s some sort of timeout window for when it resets itself? So if a user dragged an element onto the canvas, and then went back to the elements tab again within a few seconds, their previous scroll/search position was still visible. But if they went back after a minute, it would be reset.
2 Likes
Thanks for time and detail @kory appreciate it Sir
As you know, responsive images have been bouncing around for years and discussed in many previous betas. Completely understand it requires time and research. With this in mind as requested in this release, please provide a consistent way to re-enable responsive images for all non-X/non-Pro Image element images.
This decision to globally disable was made for us. This puts decision back to us, the users. If we choose to re-enable responsive images then we own the responsibility for getting the images looking and working how we need.
Its far from ideal and hacky to use the image tag in the X/Pro Text Element for example, but it delivers the much needed result of device optimised content images; and leaves the X/Pro Image element as is it whilst you work on this.
Event if this is something via adding code to child theme functions.php thats a sufficient stop gap whilst you guys take the needed time to think through. Right now the code provided doesn’t consistently work between X/Pro and WordPress versions as the way Responsive Images have been globally disabled seems to be brute force.
My first thought on this was “Hmm, a site shouldn’t have too many colors anyway, lol.”
But, then I have realized that this can happen unintentionally. For example, if we have elements saved to be reused on another site, things quickly get messy: each element introduces its own colors into the palette, despite the fact that those colors are often not intended to be used at all. The Site has its own colors and the newly imported element will receive those, making the imported ones unneeded.
There is no easy way to distinguish those, so they can be safely deleted after the element was remapped to new colors. Plus, there was an error if a color that is in use somewhere got deleted. It might be fixed in the meanwhile.
I imagine some designers are bringing in a lot of ready-made elements, created in different environments and times. If so, that can result in a huge mass of unused and even duplicate colors.
I think this should be addressed in some way. Maybe grouping colors somehow plus having an option to merge them to an old color that is already on the site. I’m sure this is not easy, but it is something to think about.
2 Likes
Palettes would definitely be a good inclusion.
I find if you’re importing templates, occasionally it overwrote the colours that were already on the site, taking from where the template originated from (although apparently this is fixed) but generally you don’t want them attached/used and you want to update them.
If you had Primary/Secondary/Others that we could set - the ‘Others’ contains all the ones brought in from other templates then you’d be able to safely delete them, knowing your Primary palette has your main ones and maybe count as a ‘fallback’ colour - so if a colour is deleted that was assigned, it doesn’t become transparent.
Not thought too much about it and as @Misho says, probably quite complex but definitely some legs in palettes.
2 Likes
Love all the ideas here. I’m a little too busy for a full workbook, but off the top of my head:
-
+200% for mobile first. Even with default theme stylesheets. We need to move away from max-width media queries and move to min-width. I also set my preview viewport to mobile when I start new pages.
-
Breakpoints: I’d love it if I could define the actual size of each standard breakpoint, whether that be in px or rem, as each project is different.
-
Responsive images: an absolute must. The ‘easy’ solution would be to support WP’s built in responsive images support. But I’d go a step further (WP isnt exactly cutting edge). Why not support
<picture>elements and allow us to override the src for each breakpoint. https://css-tricks.com/a-guide-to-the-responsive-images-syntax-in-html/#article-header-id-1 -
Background images: same as above. Default to mobile breakpoint, allow a new src for larger breakpoints.
-
Asset management: I suggested this last year, and the plan back then was to eliminate stacks and large stylesheets and create a blank canvas for users. Assuming that’s still in the pipeline, I’d love to see styles and scripts broken up into smaller chunks so I can choose to dequeue them per project. Not all of us want those gravity forms styles enqueued
I could do this programmatically if they were separate. But you could also go fancy with a purge-css like functionality based off features and elements actually used in the builder 
-
Accessibility: mega important for me, and any US customer of yours. From the basics of semantic HTML, to fixing styles that prevent outlines on focus, allowing custom aria tags, and improvements in keyboard navigation. Flyouts and modals, for example, need to trap the tab context and bind keypresses like
escto close them. Skip to content links above the header. Proper contexts for screen readers, like dialog for a modal perhaps. -
Smarter defaults. I know we can make defaults for elements, but some of them need to make more assumptions. A V2 heading element should, by default, always look the same as a Custom Headline element. We set our typography options in the theme settings, but those don’t affect builder elements out of the box, leading to a jarring experience for new users.
3 Likes
+10 This would be amazing!
+5 Also a big step forward.
2 Likes
Another thing I’d love to see in the workspace at some point is the ability to control the styling of all aspects of an element.
The specific example I can think of right now is the close button for modals and off-canvas elements. Of course we can change the color and size of that element. However, I’d like to be able to style it like other toggle elements – being able to set radius, background color, shadow, etc. Additionally, the width set for the close button currently dictates the padding for those elements, which is not what I want in most instances.
I’m sure there was a fair deal of debate about how much styling to expose for that, just sharing the request.
2 Likes
@devinelston, with regards to editing elements and the placement of controls, at this time at least we won’t be looking at any sort of re-mapping. The current way things are mapped is due to a couple of factors:
- The process to actually go in and map controls to an element is insanely time-consuming, so to mitigate this in different ways we have different types of control “mixins” we can add into various elements (i.e. groupings of common controls). This works at different levels…at a very base level, we have controls like Padding or Margin which include the 4 unit sliders along with the lock toggle. Some mixins are groupings of controls many different like all our typography options as these are typically always implemented together. At a very high level, sometimes mixins include common control groupings across elements. Without some of these abstractions…it’s very possible we might lose our minds keeping up with the minutiae of getting everything in place correctly in all the right spots, haha.
- Another more practical facet of this was at the time of implementing the current mapping scheme, our philosophy was that of trying to keep various aspects of an Element grouped together. Take a Button, which is quite multi-dimensional as it can contain an optional graphic, optional text (two layers), optional particles, et cetera. So we didn’t want to have say an option to add a graphic at the beginning of the button that is variably bringing controls in/out towards the end of the Element that you’re not seeing. With the content and styles grouped, you at least can see that adding a graphic adds in a bunch of additional controls right there that you can now style. I realize this brings up some friction as you mentioned, but it’s a bit of a give and take.
These things aren’t to say that at some point we wouldn’t be open to streamlining this in some way, but to your other points perhaps there are aspects of inline editing we can improve, et cetera. Hopefully that helps provide a little more context at the moment, but the main factor for this right now is that it simply wasn’t part of the scope of this release initially, and we’re working hard to keep it tight and focused so we don’t keep pushing the goalpost, but we certainly hear the feedback here.
As for the editors, we hear you all loud and clear and our idea at the moment is to make these work more like a floating workspace moving forward. The thought is they will be able to be resized on both the X and Y axis to work best for your flow and placed anywhere on the screen.
The idea of a “+” for adding an element is interesting and I can see the pain-points of switching to the Elements tab, adding something, and it switching to Inspector if you’re just trying to add a bunch of things really quickly. While I can’t say for certain if this is something we can get in on this cycle, it’s definitely an interesting candidate for the revamped toolbar at some point. I’ll think some on the idea of a timeout as well as a stopgap perhaps…my only concern is that it might feel “unexpected” for some users. Perhaps another stopgap would simply be a preference: “Do you prefer to stay on Elements or goto Inspector when adding an Element?” That would give some more control over the workflow.
@strobley and @michaelbourne, as for this release, we will likely not be doing anything regarding images simply due to the fact that it was not part of our initial timeline to begin with. We absolutely hear you all though that it’s a big piece to bring in and it has been noted to be part of a more substantive discussion for a future release.
@Misho and @RubberDuckers, with regards to colors, I’m not sure that getting in some type of hierarchical management will be possible at the moment, but I’ll speak with @alexander more about this next week. The idea of at least organizing colors coming in from a template into something different is interesting, but there’s more to discuss there and see any potential downsides. As for bringing in ready-made Elements with colors and things doubling up, one thought there on a strictly procedural level is to simply omit any color palette assignments to colors for these types of “library” Elements in your personal collections. This would keep them from polluting the space you’re importing to, and from personal experience, I know that sometimes I want to assign / organize my colors for various Elements differently For example, in some projects I might want my button text to be a specific Button text color based on their design, but in other projects I might want my Button text to match the headline text used on the site, et cetera. This way you can per project bring in a Button from your library that has the general layout and style you want, and then assign it the appropriate color context based on how you wish to style that project. Just a thought for management moving forward as I’m not entirely sure how doable getting in palettes will be at this moment, but we certainly plan to bring more parity between the styling of the manager and picker, add tooltips to help with selecting the appropriate color, et cetera.
@michaelbourne, We’re looking into some potential ways to allow users to either define the site as “Desktop Down” or “Mobile First.” This isn’t definitive yet, but @alexander and I did have a really great brainstorming session on this the other day where we had an a-ha moment on this. We understand that while Mobile First is ostensibly a better way to develop a site, in the context of a builder there’s some nuance to it and how those styles get applied, and this might prove confusing to more inexperienced users. Ideally, it’d be interesting for users to be able to “pick their path” so to speak. None of this is ironed out yet, but we have had a few breakthrough thoughts on the matter. As for breakpoints, similarly…we’d love to give you all the option to set them, there are just a lot of implications here. We have some ideas, still working through them…but nothing is set in stone as we are just beginning this cycle.
As for asset management, more longterm this is still the goal, but part of it is getting in more of the features from this cycle like the Layout Builder, responsive styles, et cetera. We will review this more after this cycle.
Accessibility is important to us as well and we have many important features in already with various WAI-ARIA roles and state management, et cetera, but we realize there are more items to address. It’s not part of this cycle, but we hear you.
As for defaults carrying across Theme Options as you’re mentioning, that is again something that doesn’t really fit into this cycle. We’re trying to keep this discussion tight on the items mentioned above. We have some general ideas for this moving forward down the road, but for now we’re wanting to keep this discussion focused on the items at hand.
Thanks guys!
@devinelston, to your point of controlling more aspects of an Element…that’s again one of those very tricky things that everyone feels differently on. X and Pro cater to a very wide range of developers, so we tried to find lines of demarcation to make things very flexible, while also being approachable.
Your example of the close button is actually an interesting one, because it’s one of those lines in the sand we drew for very specific reasons. I know I personally have times where I’d like to style something like that more on my own, but the addition of each control to the workspace is something we try to take into account. And with the case of the close button, it’s interrelated with how the modal works and is spaced out. For example, with our modals the close button sits in the edge spacing defined by the modal. When you define that edge spacing, a lot of things get set behind the scenes: the button gets that same font size, width, height, et cetera…without this, there are situations where the button could appear broken if it’s not set right in this area if we just turned all that control over to the users. And when you compound that with giving a ton more options for styling and the potential to “break” it more and then contrast that with the nature of a close button in general that it’s not necessarily the “star of the show” in that Element…it’s one of those areas where we chose to streamline things a bit and give less control for the sake of making things work a little more seamlessly and effortlessly for novice users, knowing a more experienced user could in that situation add custom styling as they know what they’re doing.
I hope that helps to provide some context there in that specific situation, but it’s actually a great example of many of the little decisions we’ve had to make on these more multi-dimensional elements in how much to expose vs. how much functionality we give. Definitely many, many layers to think about on those Elements, haha.
OK @kory, as requested, at the very least change the way in which native WordPress responsive images are disabled in the builders so that they can be easily reenabled via a code snippet that consistently works.
As mentioned, this would allow in WordPress images to be inserted via the X/Pro Text Element, and used throughout WordPress/WooCommerce. Not ideal but at least a workaround.
This seems related to the cycle with the layout editor:
Could Dynamic content get If/Then, And/Or, +-*/ statements? For example:
If {{dc:global:time}} > 10:00 Then write "Same day delivery if purchased untill 10:00. Hurry up!"
If {{dc:woocommerce:cart_items}} < 3 Then write "Buy one more to get free shipping" .
It could add huge value to WooCommerce Messages element that i guess will have to exist in the builder.
There are also non-WC use cases.
Plus, this is a chance to iron-out many WC UX/Conversion issues in general and build web shops far better than what competition has to offer.
4 Likes
One more thing:
With the new Layout options, will (ever) be possible to have full screen canvas, along with tools on the other screen? I’m considering moving to Asus Zenbook Pro Duo, and utilizing that second screen in full seems very tempting.
Yes please x1000!
I think I’ve requested pretty much the same in a previous cycle but I don’t remember what the conclusion was. This is a great time to bring it up again because now with the full site layout editing coming up, this makes more sense than ever. Just think of the possibilies…