UI Proposal and Discussion

[kory]

Howdy, Beta Group! I hope you all are doing well and that you had a restful weekend. The primary feature of our next release cycle that we are focusing on is the addition of our Layout Builder, which will allow you to build out generalized site layouts (“templates” in WordPress parlance) for your posts, pages, archives, and more. Once this is in, you will effectively be able to build out full site designs from scratch with almost no limitation.

For example, instead of having to use the standard post layout utilized by the Stack you have chosen in the theme, you could create an entirely unique post layout using the Elements you’re already familiar with—Sections, Rows/Columns, Grids/Cells, Buttons, Text, Images, et cetera—and then assign that layout to all posts to be used in place of the standard design. There’s a lot more to get into with this, but we won’t dive into all of that today as there are other matters to discuss that we would like your input on.

Something we’ve discussed implementing for a while now is how to introduce fully responsive styles natively within our builders. Currently, if you have a Section outputting a padding value of 45px 0, that value is present all the time at all breakpoints. However, there are many times that you may wish to adjust these values as the client’s screen size goes up or down. Having full access to adjust these controls at every breakpoint is what we’re talking about here…and for every control on every Element.

With the inclusion of the Layout Builder now coming into focus, this felt like the appropriate time to finally tackle this feature as well, as having full responsive control over every control at every breakpoint is essential to creating flexible, fluid layouts that work well and look great across all viewports.

This finally leads us to what we would love your feedback on today. What we are discussing below is born out of what has already been mentioned above. The implementation of the Layout Builder necessitates fully responsive controls, which will in turn necessitate some UI changes to accommodate all of these new features. So let’s jump right on in to some of the currently proposed UI changes that we have arrived at after much discussion and deliberation:

The Current State of our UI

Before we begin, let’s take a look at the screenshot below and define some terms so that we can use them throughout this discussion:

1. The Bar: The primary hub for all of the tools and navigation used throughout our Builders.
2. Workspace: Where all controls for manipulating Elements are found. Shown as “floating” in this screenshot so we can showcase some other pieces of the UI, but this is initially docked and can be moved from this vertical orientation to a horizontal orientation, which can remain floating or be docked along the bottom of the screen.
3. Canvas (or Preview): The live preview (or as we call it “The Canvas,” internally) is where all changes made to your content are shown.
4. Control Navigation: The control navigation is what allows you to quickly move through the options available for the currently inspected Element.
5. Breadcrumbs: Shows you the path from the top of the document down to the currently inspected Element, and gives you a way to quickly move up that tree to select any parent Elements.
6. Expanders: The builders currently feature numerous pieces of functionality that are housed in what we call “expanders” internally. This includes the history (currently pictured), CSS editor, and JS editor.
7. Settings Modal: A catch-all for certain functionality such as preferences, the Color Manager, Font Manager, page settings, keyboard shortcuts, et cetera.

Responsive Management

The first thing to discuss is how responsive controls will be managed in the next update. One thing we have decided that we don’t want to pursue is trying to cram responsive toggles into the controls themselves. Many builders tend to work these as inline elements into the controls themselves, which leads to a lot of repetition and a cramped workspace. The pattern we are particularly keen on at this point is something like the following:

Note that in this wireframe, The Bar is adjusted a bit from how you know it currently. There is a new “settings” toggle by the hamburger (which we will come to later), but the main difference is the responsive controls seen in the middle. The idea behind this approach is that in a responsive builder we’re trying to surface as many tools as possible that are “mission critical” to the minute-by-minute building process. Having these controls front and center makes previewing changes across breakpoints much more accessible, but there is also a dual-purpose in these buttons. In addition to toggle between breakpoints visually to see changes, the breakpoint that is currently selected will be the breakpoint that the styles you are currently adjusting will be applied to. The main workflow would look something like this:

1. The XL breakpoint is the default viewport. While that viewport is selected, any styles added are “global” meaning that they are applied to all screen sizes.
2. So if you were designing a Row and setting the padding on it, you would start by defining the padding on the XL breakpoint to have that apply to everything.
3. If you then wanted to adjust the padding on the MD and XS breakpoints, you would simply select the MD breakpoint while your Row is inspected and make your changes, then select the XS breakpoint and do the same.
4. As overwrites are made for certain settings at certain breakpoints, there would be styling to indicate that the “original” value set globally has been changed at this breakpoint.

The great benefit to this approach is that it doesn’t change the control layouts at all. There aren’t any new buttons or toggles to learn in that space, you simply select the viewport you want to edit for (which you’re already accustomed to from the responsive toggle we have currently) and make your changes in a familiar interface. In our opinion, this approach will help to both put the responsive controls more front and center and make editing responsively easier, while also adding in true responsive editing of any value in the inspector without having to adjust that Workspace interface at all.

Composability

Currently, the layout of the of the builder “chrome” is fairly malleable in that you can orient the Workspace either vertically or horizontally, have it display as a floating popup, and you can also move the Control Navigation / Breadcrumbs to a few different spots. However, we understand that some users prefer to move various pieces around to fit different workflows across different screens, so one thing we’d like to improve along with the updates above is to make the interface more composable. Below are a few examples of what this might look like in a quick wireframe format:

The examples shown above are by no means exhaustive, but hopefully represent the spirit of what we’re trying to do. Essentially, we’re looking at a few parameters here:

1. The Bar will be dockable across any edge of the screen (top, left, right, or bottom). Because of the simplified nature of its content, The Bar should work great both horizontally and vertically.
2. The Workspace will be dockable across any edge of the screen, or be able to utilize a floating context similar to what you can do now (where the Workspace is hovering above the Preview area). The Workspace already currently supports vertical and horizontal orientations, what we’re simply allowing for here is more configurability on where you might want to dock this element.
3. The secondary bar seen there for navigation will be dockable across the top or bottom edge of the screen. Because of the nature of the content inside (Control Navigation and Breadcrumbs), we need to have a long, horizontal space for this bar to occupy so that you can see as much information as possible here. Moving forward, these will be the two main orientations for showing these navigation controls. We have considered the idea of leaving a legacy option to place these back “inline” with the Workspace, but ultimately we are trying to move away from that setup as it is a holdover from the old days of Cornerstone when we had a much simpler Element tree and control navigation. Now, with complex Elements and layouts that can in theory be infinitely nested, this pattern simply doesn’t hold up as well.

The general idea with moving these around is that you’d be able to grab them anywhere within the tool and simply drag it to a side, and it will orient the way you want it automatically. No more buttons in The Bar, it will just be a matter of moving things where you want them.

Tools

Another primary difference in this direction we are wanting to explore is how how the access and management of various “tools” are handled. Previously, some tools were found directly in The Bar (code editors, history, et cetera) whereas others were found within the Settings Modal (Color Manager, Font Manager, preferences, et cetera). Going forward, we’d like to consolidate that more uniformly under a new “Tools” dropdown that might function like the following (the icon used for this dropdown throughout these wireframes is not final, only for demonstration of the idea):

Notice in the above wireframes that we’ve clicked the new “Tools” icon next to the hamburger for general navigation, which opens a dropdown. From that screen, you will see a selection of all tools available in the builder you’re currently in (this might differ based on context). Keyboard shortcuts will also make these tools directly accessible without needing to go through the tools menu. Clicking on certain options such as the Color Manger (pictured above) will open that tool in a sub-page within the dropdown. There are a few main benefits of doing it this way vs how we’ve done it previously:

1. Many of these tools such as the Color Manager or Font Manager are mostly set during the beginning of a build and not used again, or are used infrequently, so tucking them away won’t interfere with workflow (and if things are truly used often, they will be accessible with shortcuts).
2. For things like the Color Manager and Font Manager that were previously in the Settings Modal, you were not able to see the changes made to these tools in real time as the Modal was over the entire page. With these tools directly within the dropdown, any changes made will be able to be previewed in realtime.
3. The interface is more predictable having everything in one uniform place and with any “deeper” tools managed via a 2nd state.
4. In conjunction with the composable ideas mentioned above, many of the icons that were previously in The Bar will now go away entirely (such as the orientation button or the popout button), cleaning up this interface considerably.

Conclusion

I know that’s a fair amount to take in, but we wanted to try and make things as clear as possible before forming and sharing any opinions. The general goal of what we’re trying to do here is to expand the functionality of all these tools without changing things too drastically. I think you’ll see from the screenshots and ideas discussed that things are not wildly different, we’re simply taking a step back to assess where we are currently and how we can better improve the general site-building process within our Builders. We look forward to hearing from you all and seeing what you think as we work on these ideas!

[devinelston]

First of all, I love the ability to customize elements at different breakpoints within the tool. And it’s clear you folks have put a lot of thought into this. I’ve been anxiously awaiting this layout builder update, and can’t wait to get my hands on it.

Based on your description and my own workflow, I do have a few thoughts right off the bat.

More and more, I’ve been trying to switch myself to Mobile-First In terms of how I code sites. When I was first getting started, I would start building at the large sizes and do custom CSS for smaller sizes. But I would run into issues, so I’ve been doing it the other way around more recently – using the native Pro builder to get things right on the smallest sizes, and adding custom CSS and media queries once they reach a certain breakpoint.

So, that immediately brings up a few questions for me:

1. What’s the reason for making this XL-first? Is it primarily because we’re building these sites on larger screens ourselves, or are there other considerations?

2. Let’s say that I want to have the XS - LG breakpoints all use the same design, and then do something slightly different just for XL. Would I need to set 4 individual overrides in this case (one each for XS, SM, MD, and LG)? Or will there be a way to set a range of breakpoints that will use the same styling?

3. In the primary workflow you described, where we set the Xl styling and then make changes where we want… what shows up in the builder before we make changes to the other breakpoints? (Will it show the same values, or will it be blank, etc.)

4. Did you folks consider implementing this functionality as an “Add override” action rather than breakpoint by breakpoint? For example, I set up the element as I see fit, and then click an Add Override button, select the breakpoints I want it applied to, and then make relevant changes?

The Bar
In your proposed design, I like that the size toggles are quickly accessible. However, it adds a new layer of abstraction that I’m a little worried might get confusing. It’s hard to say for sure without actually using it, but here’s a scenario I can envision:

• I’m working on the LG breakpoint, but resize the overall window dimensions so that the canvas is at the MD breakpoint.
• In this case, what would happen to the builder? Would it automatically switch the element controls so I’d be overriding the MD styling? Or would it function like the row editor does today, where it highlights the breakpoint active on the canvas, but you can individually select whichever one you’d like to edit?
• If it’s the latter, since the Bar might be docked in a different part of the screen, I might not notice the highlight change and end up editing the wrong breakpoint.

Again, this is just a quick take based on how I’ve observed myself using the builder for the past couple years. Looking forward to trying it out soon!

[devinelston]

The Tools
In general, I like your new drop down approach for these.

For colors though, I’d personally like to see the drop down match the layout of the color picker from the workspace. The reason why is that I like to organize the colors in a particular way, with rows for different “types” of colors (text, shadows, branding, etc).

In the color picker from the workspace, the colors are presented in rows of 8. And in the current color settings modal, they’re in rows of 4. Although it takes a bit of work, it’s relatively straightforward to drag the colors around to get them in an order that I like because they’re both divisible by 4. However, in these new mockups, you use rows of 3 in the new color drop down. So, I could see myself getting really frustrated trying to get things in the right order.

I’m probably a bit more sensitive to this because I’ve been working on setting up some new sites, and needed to change the colors around while evolving the designs.

Keyboard Shortcuts
In the mockups, the keyboard shortcut for jumping to the CSS editor is command C. I’m assuming that’s just part of the mockup and not reflective of what the actual shortcut would be, right? (Because wouldn’t that compete with the copy shortcut?)

[Misho]

Hi!

Great to see a new Beta thread, it always means something great is coming soon.

I will come back with more later, but for now, I’d just like to point out that a standard 1920px screen is starting in the MD breakpoint right now. This would mean most folks would be confused if the XL is expected to be a default viewport. And it is not even the most used viewport globally. 1366px has the largest share.

[kory]

@devinelston,

Thanks for chiming in, and all great stuff to think on! Here’s my initial thoughts I have regarding the things you’ve brought up (again, this doesn’t mean anything is final, just hoping to clear some things up and share what I’m thinking at the moment):

Mobile First Styles:

1. The short answer is yes, we would certainly consider looking into making all of the CSS mobile-first moving forward. I actually intentionally left this out because I didn’t want to get to sidetracked on it myself, and the fact that there are numerous technical considerations to take into account here (e.g. how do we revamp the static styles within the theme files, how do we gracefully update dynamic styles, how do we update media queries, et cetera). The longer answer is that as much as we really would like to do this, there simply may be some limitations with all of the legacy styles and how things are handled, and doing it proper might be another update in and of itself. There are many moving parts, and while I personally would love to get this in (I also do all of my own projects mobile-first now as that became more commonplace many years ago), it may prove to be too large for this particular cycle. For now, I can certainly say it’s on our radar and we’d love to get it in as long as it can be done cleanly and without causing issues for users going backwards.
2. As for how you’d do overrides, again this is a tricky thing to think through. For the current iteration of the Row and Grid Elements with their responsiveness, those changes happen at that particular breakpoint only (e.g. min-width: ___ and max-width: ___). There are some nuances to this, but ideally we’d love it to be a type of “cascade” going forward where you set the base, and then if you want a change at a particular breakpoint, it would flow up or down (depending on desktop-first or mobile-first) to other breakpoints, which would avoid you needing to overwrite the same value 4 times as per your example.
3. We have not yet arrived at what would be displayed before making changes, that will be part of exploring these concepts more in the coming weeks, but I am leaning towards it showing the “default” value already set and then if overwritten, there would be some sort of color or indicator to show that the value has been updated from its “default” state.
4. The “Add Override” concept is interesting, however I’m concerned it would become more cumbersome as you add more and more changes. We’d have to think through a way to show all of those edits somehow, introduce a new button into the Workspace I’m guessing (which we are trying to avoid), and it feels like it might not surface as much information to the user as readily as possible. With the approach we’re considering exploring, the thought is it would operate somewhat similar to the responsive controls on Rows and Grids now, automatically changing to a breakpoint for you when resizing the browser, which would allow you to see all relevant values change automatically as you’re resizing up and down (or as you click to a breakpoint and the Preview resizes).

The Bar

See what I mentioned in #4 above…that is one likely scenario for how it would behave. Another would be something like the following: when in the “default” state, you can resize the browser as you wish, but doing so does not automatically switch you in the breakpoint toggles. To do that, you have to explicitly select a breakpoint to edit that value (which will be possible as the Preview changes size to match). Again, there’s still some stuff to explore on our own here, but I lean towards the first in having the browser always “observing” what size the Preview is at and changing your values behind the scenes to suit. As the controls would always be visible, they’d always be a glance away to see what breakpoint is currently highlighted, and if you really wanted to be super careful, you could always just use those buttons explicitly to ensure you’re never accidentally editing the incorrect breakpoint.

Tools

Definitely open to exploring other layouts here. I simply added the 3-across version to showcase the idea. The color picker tool in the modal is actually responsive and will wrap to a different number depending on how big your screen is, so I was just kind of borrowing that idea here. With a more fixed space though like in the dropdown, we could define things more explicitly and perhaps even allow for users to drag and drag and drop into rows or things and organize how they see fit like you mentioned. That’s a really cool idea.

As for keyboard shortcuts, I simply picked “C” for “CSS” and “J” for “JavaScript,” but they would definitely be something different so as not to interfere with the copy shortcut for instance, haha. Sorry for any confusion there.

[kory]

@Misho, great to hear from you! Looking forward to your thoughts. Can you please elaborate on what you mean by “…a standard 1920px screen is starting in the MD breakpoint right now…”? I’m not quite following that. And maybe you could just elaborate on the 1366px thing as well, while you’re at it so I make sure I’m fully tracking with you. Thanks!

[Misho]

H @kory!

Sorry, I have missed the key point: the Canvas is in the MD view on 1920px screen, 15’ laptops. This is due to the sidebar (Expander) that takes up space. So the default for many users is the MD width, unless they expand the canvas or detach the sidebar.

If the Builder is set up in the way that the default is XL, many have no practical way to drag and drop anything from the Expander because it automatically puts the view in MD. At least this is how things presently are.

Also, there are designers who prefer mobile-first approach of building sites, so the logic needs to work for them as well.

[Misho]

To continue on the above, I think the best option would be for you to create some meaningful defaults per Breakpoint, and then have Elements Defaults in the Template manager expanded in the way that each setting can be saved as a default for particular Breakpoint, or something along those lines.

This way we could tune-in the default behavior of the elements accross all breakpoints, right from the start. I’d be happy to stop removing the Box-shadow from each button, and doing other kind of element resets.

Also, I still need to hack the browser in order to see the 360px mobile width in the Content editor, which is much more relevant than 480px. Also the 320px, as the lowest real-life device width. Things are very different there, than they are on 480px. Many X/Pro sites have long-word headlines sticking out of viewports on mobile, because of this. Non-professional folks take the mobile preview for granted.

I understand that Breakpoints cannot be added just like that, but this is more about the preview. Ideally, the Canvas could be locked to the breakpoints, but also draggable, with an indication of the current width. Like the Chrome Dev tools do.

[Misho]

Ok, finally got a chance to sit down and read the post more thoroughly.

Composability:

1. Dockable bar is an excellent idea. I am worried about the “simplified nature of its content” though. I hope that the most used stuff like Custom CSS, Undo, collapse bar and Preview page will not be placed one more click away. They should be right there where they are in my opinion.

2. Secondary bar is great. I think there should be an option to move them both closer together. I am doing this with Custom CSS, because it is much easier if they are on the left next to each other, than traveling to the far right of the screen.

The overall idea of undocking individual parts is great!

Tools

Generally, I like the idea, as long as custom CSS is not here . I use it too much to have it one more click away. Also, keyboard shortcuts are not always the fastest way.

Plus, they don’t work always. For example, duplicating is CTRL+D, and in Chrome that invokes the “Edit Bookmark” modal, so duplicating is not possible.

CTRL+SHIFT+E is great, but it doesn’t leave the Custom CSS part visible, so for that reason, the button for collapsing the sidebar needs to stay visible in a single click, unless some better solutions comes along.

Exit to dashboard can stay hidden, but I’d also love to see “Exit to front-end”. On a daily basis, I click “Exit to dashboard” only to click the “Visit Site” again. This is because the “Page preview” icon is not present in all places.

[devinelston]

@Misho

1. Secondary bar is great. I think there should be an option to move them both closer together. I am doing this with Custom CSS, because it is much easier if they are on the left next to each other, than traveling to the far right of the screen.

I’m still doing this too, so would love a native option as well.

@kory, is there any particular area you’d like focused feedback on? I sort of treated this like an open feedback session on anything that occurred to me based on the mockups. However, if there’s an area you’d like us to pay special attention to, I’m happy to focus on that.

[kory]

@devinelston & @Misho, I’m tracking more fully now on the responsive issues you brought up. Unfortunately, as you know there’s nothing we can do to allow people to see a breakpoint larger than their computer screen will allow. However, that does make me think more that going mobile-first is even more important to consider with all of this in some way. Again, we cannot guarantee this shift will happen during this cycle because there are many implications (static styles vs dynamic, legacy sites, people with child themes, handling the update gracefully, et cetera), but it definitely makes a strong case for going mobile-first in the sense that people would at least be able to see everything more clearly and could at least leave that MD breakpoint style for everything on up from there if needed, and it should look fine. As mentioned previously, I also prefer working mobile-first these days, there’s just a lot of moving parts in the X/Pro ecosystem to consider (many of them which are out of our control, such as how users are implementing their own changes and whatnot).

As for saving Element Defaults, you would certainly be able to save your own personal defaults at all breakpoints. That would be necessary to make sure that part of the system works as expected.

With regards to breakpoints in general, I agree that there needs to be some way to get a better idea of what other screen sizes need to be considered when designing. As you mentioned, 320px is effectively the absolute minimum for older iPhones and other devices, but 360px is a more modern minimum standard. One thought I had was if you selected the XS breakpoint for example, maybe the preview sizes down to 480px as it always has, but it could have a handle on it that would allow you to resize the preview down. My thought is that this would be contextual for each breakpoint you select, so maybe for the XS selection, you could resize the preview from 320px up to 480px and see how it looks at every pixel value possible. Then, if you were to select SM, that might resize from 481px up to 767px, and so on. Then, if you just wanted to see “everything,” you could go back to the “default” view and resize your browser up and down as needed. I think all of this is effectively what you mentioned as well with the canvas being “locked to the breakpoints, but also draggable.” Can you confirm we’re on the same page here?

As for your thoughts on the composability side of things and focusing specifically on “The Bar” for a moment and all of the tools within, there were a couple of things that some were worried about internally. Primarily, that they didn’t want to do away with the vertical orientation as they felt users were quite accustomed to it and removing it completely would be too much of a shift. This was part of the reason for having this bar be able to move to any side of the screen.

That being said, I have some personal concerns that the vertical orientation might prove to be limiting as we begin adding in some additional features that will come with this release such as the context switching (e.g. previewing a header on different pages, et cetera), and that trying to make the primary bar dockable on any side of the screen is kind of taking away some potentially useful functionality for the sake of keeping things as they always have been. A personal thought I had was to make that primary bar dockable on the top or bottom only, like the navigation bar, which would allow us more horizontal space to place in some other items such as a contextual switcher, maybe show icons with labels, et cetera (the following is a super quick mockup of what this might look like):

I’ve also shown in this example what it might look like if that bar was fullwidth across the entire top (or bottom) of the screen, which helps to give it more prominence. Notice that we have room for the “Current Preview” section, which you could click on to open a page switcher but you always have that visual reminder right there at all times. Also, to your point of not wanting to lose certain tools in the top-level, I’ve thought it’d be helpful to add in a simplified history in the bar potentially of just an undo/redo mechanic. You would still have access to the whole histroy in the Tools somewhere, but this would be a quick thing that is accessible at all times while building. We could keep the CSS, JS, and frontend preview as well. Here’s another version without the labels, which is slightly more condensed:

Another variation would be to keep it inside the canvas area like mentioned previously:

One thing I left out is a potential “More” or “Tools” button to open a dropdown for other things like the Color Manager, Font Manager, Preferences, Histroy, et cetera…that could either be towards the end of all the tools in the middle there, or could be placed next to the main menu button to the far left like before. What are your thoughts on any of this? Again, this is all very much in flux at the moment as we explore these patterns more.

Quick note on the navigation elements within the navigation bar: yes, we’d like to have some way within that bar for you all to arrange it in whatever order you’d like, and orient the navs within that space how you prefer.

@devinelston, as for your comment about particular areas of feedback, it’s really just kind of an open discussion at this point for the Beta group as we’re beginning the process ourselves and are looking to gain as much insight as we can, especially from our users who really utilize the tool to the full extent all the time.

Thanks, guys! Looking forward to hearing back from you all!

[Misho]

Hi @kory!

@kory

I think all of this is effectively what you mentioned as well with the canvas being “locked to the breakpoints, but also draggable.” Can you confirm we’re on the same page here?

Yes, absolutely. That is exactly what I meant. It would give us ultimate control over the entire responsive spectrum, without having to save and preview in another window, or hiding the sidebar and narrowing the entire browser, or using other non-native methods. Fantastic!

@kory

What are your thoughts on any of this? Again, this is all very much in flux at the moment as we explore these patterns more.

I like the concept. Having it all horizontally would make a bit more getting used to it, but if the undo/redo, custom CSS/JS and preview are visible at the top-level, then it is all fine. If it is modular, allowing us to make our own arrangements, even better!

I am a bit concerned about losing additional vertical real estate in case there are two bars now. It took me a while to get used to even to the single one with breadcrumbs when first introduced. Also, it seems to me that placing stuff at top right makes a long mouse round-trip in everyday work. Any extra “mileage” increases the cognitive, physical and time load. The more the things are grouped, the better.

I know Photoshop is an example of an app that is all over the place with tools, but it is an predominantly mouse/pen tool. Building a web page involves a lot of combination with keyboard, continuously entering some parameters and text. As such, it means a lot if most-used stuff is as grouped as possible because mouse movements are often interrupted.

Another thing that might not be a topic right now is the way tools are organized. I know you guys will redo this at some point, and I am looking forward to it. Right now, there is too much scrolling and searching for stuff.

I know every tiniest part of the entire system, but I still need to slow down, stop, concentrate and then find a setting that I need. This is because the layout forces us into multitasking a bit more than it should.

For example, If I am focused on a particular task, like getting the font parameters right, I’d like this not to be interrupted by scrolling half-way down to find another font settings for a sub-heading for example. Or if I am concerned about borders, I need to stop and move way down to find another set of borders for some other part of the builder. Or shadows… Shadows are shadows, being it box or text.

For me personally, UX of tools is a lot about reducing multitasking. There are limited sets of tasks designers are focused on in each moment. The sweet spot is getting tools grouped around those individual focus points.

One way to tackle this are tabs. Two to three tabs, each having set of settings focused around a single focus like entering text. This includes entering the url in links.

One more interesting observation I had was when I had to add some content to an old version of X. it was so nice and easy to simply drop the text into the text box in the sidebar. Now we have this additional click to expand the text window first, which is an unnecessary addition in my opinion. Yes, expanding it is a nice thing to have, but only if we need it. Very often we don’t.

I know that inline editing is possible. I don’t know about the others, but for me that never took off. First, the builder is too sensitive on dragging. it is hard to stop and concentrate on having the mouse perfectly still before making a double-click. If we don’t do that, very often the element simply flies off into the neighboring section, usually above. Then there is occasional non-responsiveness of it, where double-clicking does nothing. Finally, there is a slight delay. All this is “too expensive” for me to rely on, so I much prefer getting to the text box and simply dropping the text into it, preferably without the additional click needed to expand it.

One more friciton is the fact that the units need to be changed on click. The settings used to accept units written after the number, but that has changed. For example, if the margins are set to pixels by default, and we write 3em into the box instead, ti would be really nice for the unit to change after hitting the tab or entering the next field.

Those are small fricton points from the everyday use. I hope that pointing out some of them is useful.

[armillaria]

@devinelston

For colors though, I’d personally like to see the drop down match the layout of the color picker from the workspace. The reason why is that I like to organize the colors in a particular way, with rows for different “types” of colors (text, shadows, branding, etc).

In the color picker from the workspace, the colors are presented in rows of 8. And in the current color settings modal, they’re in rows of 4. Although it takes a bit of work, it’s relatively straightforward to drag the colors around to get them in an order that I like because they’re both divisible by 4. However, in these new mockups, you use rows of 3 in the new color drop down. So, I could see myself getting really frustrated trying to get things in the right order.

I’m probably a bit more sensitive to this because I’ve been working on setting up some new sites, and needed to change the colors around while evolving the designs.

+1 for presenting colours with a uniform layout in all contexts! It gets confusing quickly if you have similar colours (with different purposes), and they move; eg. white / off-white.

I’d like to add to this by suggesting that the name of a colour be displayed as a tooltip on mouseover, to avoid such confusion

@Misho

I’d be happy to stop removing the Box-shadow from each button, and doing other kind of element resets.

+1 on this!!! I really like @misho’s idea of setting default element behaviour through the template manager. This would be a great step forward in being able to set up a design system in Pro.

@Misho

One more friciton is the fact that the units need to be changed on click. The settings used to accept units written after the number, but that has changed. For example, if the margins are set to pixels by default, and we write 3em into the box instead, ti would be really nice for the unit to change after hitting the tab or entering the next field.

+1 on this also. Requiring the click was definitely a step backwards in productivity (speed).

[armillaria]

@Misho

I know that inline editing is possible. I don’t know about the others, but for me that never took off. First, the builder is too sensitive on dragging. it is hard to stop and concentrate on having the mouse perfectly still before making a double-click. If we don’t do that, very often the element simply flies off into the neighboring section, usually above. Then there is occasional non-responsiveness of it, where double-clicking does nothing. Finally, there is a slight delay. All this is “too expensive” for me to rely on, so I much prefer getting to the text box and simply dropping the text into it, preferably without the additional click needed to expand it.

This is EXACTLY the reason we went with X instead of Divi 3, or the WPMU Dev builder that was in beta way back when.

For me, the biggest appeal of X (and now Pro) is that I can teach a staff member how to use the tool, and once they know how to navigate the controls, and what they are looking for, the builder rarely gets in their way… unlike the annoying in-line editing approaches taken by other tools.

For what it’s worth, I think the click-to-edit Text elements in the preview made the UX less good, particularly because it doesn’t expose the same editing functionality as what is shown in the Expander version. Particularly, this trips up juniors because when they copy/paste text from another page, it brings all the HTML with it, but is not always obviously so.

[Misho]

@icologi

For what it’s worth, I think the click-to-edit Text elements in the preview made the UX less good

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.

[JvP]

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!

[JvP]

@devinelston

However, in these new mockups, you use rows of 3 in the new color drop down. So, I could see myself getting really frustrated trying to get things in the right order.

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.

[strobley]

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.

[kory]

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!