Do you use widgets for layouts?

General Discussion
1

This question comes from me as a community member and not a director.

I’ve been reading up on some old discussions to see what people want from CP. One thing I noticed, a lot of people like using widgets to build websites.

I was curious to see what do you think of widgets, do you use them to build layouts for websites?

EDIT: This has evolved from my original idea/post. For an updated version, refer to this reply below:

Old idea

An Idea

This is not a petition, just an idea I’m sharing that came from a discussion about if not Gutenberg then what?

What if we turned widget area where we create sidebars into a widget manager where you can create layouts?

What would need to change is the UI a bit. For example, instead of a vertical stack for sidebars, the “layout” area would allow vertical or horizontal layout of widgets. So you could create modular layouts, which could be assigned to pages. This would require metabox on edit page screen to select layout.

A few points:

  • Most of the functionality is already there.
  • One important thing that separates this from Gberg is separation of frontend and backend.
  • Theme would be responsible for styling, so it’s possible to retain a layout but switch theme

This is just an idea based on some of the community comments in various discussions over the years. Maybe it’s plugin territory, but I wanted to get feedback.

If this received support, I could mockup a possible UI.

Thoughts?

2

It’s already possible to have horizontal widgetized areas. The term sidebar is a bit misleading in that respect.

3

Look at @joyously theme here Twenty8teen – WordPress theme | WordPress.org.

It is all widgetized.

It’s a good example of possible implementation.

To me the widgetization is theme territory because not everyone needs widgets.

By forcing that into core, de facto we will be repeating WP by forcing a feature on everybody while it’s easier letting people select a widgetized theme.

1 Like
4

In the frontend yes, but not in the backend. Maybe the first step would be to improve wording, getting rid of the word sidebar. Functions like get_sidebar() can be kept for backwards compatibility but new functions introduced like get_widget_area().

I’ve used “sidebars” for all sort of layouts over the years. The main issue trying to explain to clients was the way it looked in the backend. You have a 3-column footer in the frontend, but in the backend, it’s either 1 sidebar per column or 1 sidebar with 3 widgets inside stacked vertically. Clients are usually confused trying to understand it.

I need to update ClassicPress website, and I’ve been thinking. What exactly are we trying to achieve? Are we simply WordPress without Gutenberg? Or are we trying to build something different, something better, and leave WordPress shadow.

That brings a different question, who are we building it for? Our homepage says “CMS for creators”, who are the creators? Are they non-technical users or developers? We continue to make CP better for technical users, the developers. Yet we haven’t really thought much about non-technical users.

If we’re making a CMS for developers, we should update copy on the website to say that. If we want non-technical users to be able to use it, we should look at ways to make it easier for them to create and manage their website (Gutenberg isn’t the answer).

Sidebars were introduced in 1.5.0, I believe. They’re almost the same 15 years later, and people continue to use them in a hacky way for various layouts that are no vertical sidebars on the left or right.

We need to address that, we need to align UI/UX to how it’s used.

It’s already in the core, I want to improve UI/UX so it’s easier to use for non-technical users. And yes, I’ve seen Joy’s theme. That’s what made me think of improving the widgets page.

My idea is to continue to allow themes to manage widget areas (sidebars) as they did. We would simply extend and improve on that functionality to make it more usable and friendly.

I’m only now thinking about it, so I only have a few ideas I’ve wished widget areas did:

  1. Grouping widgets together using a group widget, which basically would wrap a div or something around that set of widgets. Something like this:

image
image778×526 18.7 KB

  1. I’ve always liked Beaver Builder’s panel with all the modules. They group them, make it searchable so it’s easy to find and they don’t take up as much space as available widgets. For reference, compare them:

    image
    image2530×1781 336 KB

  2. Ability to save widgets, so they can be re-used in another widget area easily.

  3. Ability to duplicate a widget with all the settings.

  4. Ability for themes to load widget presets, so widgets don’t start from scratch.

  5. Ability to export/import widget configuration/settings. Make it easier for theme developers to provide demo content importer if widgets will be a big part of theme development.

  6. Themes/plugins registering their own custom widgets should be grouped together in a separate category/section. Sometimes developers use generic names, and it’s hard to figure out custom widgets from a theme, plugins, etc.

EDIT: 8. I forgot the ability for widgets to have tabs to separate options - content | styles | options (or custom tabs set by the developer). Point is, that we shouldn’t have scrollable widgets because they have so many options. Plus it’s easier to find what you need. Do you need background color change? Styles tab. Do you need to edit title of the widget, content tab.

Whatever we do, we do need to improve UX/UI and align them with the actual usage - not obsolete sidebars.

Remember, take your developer shoes off for a moment and put on the shoes of a typical non-technical user who will be using it. This is what we have right now and need to improve:

image
image650×650 83.8 KB

2 Likes
5

The themes I use on my sites have origins in WordPress 1.5! They are long abandoned and I have amended them myself over the years to add widget support, convert to HTML5, add a darkmode and update CSS layout for browsers.

I may be alone here but design for me is getting into the theme HTML and CSS and editing it, broad layout functionality can be done with a widget but fine tuning is code.

3 Likes
6

This is very well presented. And it makes sense.

But it somehow is like saying: “hey, let’s convert the old widget world into an actual page builder”.

I always create themes FOR the end user. That is, the theme uses custom fields to allow some degree of dynamism, but the layout is somehow fixed.

It is aimed towards non technical users but it’s technical behind the scenes.

Allowing users to build their own site without a need for a developer is nice too, but here I have to say: WordPress is way better for that.

Gutenberg is an amazing page builder. I don’t see any benefit in creating a new page builder based on widgets, when you can use Gutenberg which is f****ing amazing for non technical users. And getting better every day.

My personal view of ClassicPress in the long term is a stable CMS based on the good old WordPress which devs can use to create an amazing setup for non technical users (clients) to use.

And I’m not saying ClassicPress should be only focused on developers. Non technical users can always use Beaver Builder or any nice theme and do their thing.

But I would also avoid taking the page builder route, WordPress took that route and it’s excellent. No need to reinvent the wheel with a crappier solution. Blocks are the way, for that matter. I would focus on modularity, stability, security, efficiency and simplicity.

We can use the proposed meeting about longterm view to cover this topic. It’s extremely important to cover because it will give a clear answer to ideas like this one. For now and forever.

2 Likes
7

It’s not about making it into a page builder, but simply improving already existing functionality. My suggestion is to do what you said in another post - make it better :wink:

Whatever that looks like is for us to figure out. I just wanted to start that conversation.

Minimum would be changing “sidebar” to “widget area” in text and functions.

2 Likes
8

With this I really agree. A fresh life and more appropriate semantics. As long as the focus isn’t “let’s build a whole page builder system out of this”. But you already clarified that.

1 Like
9

I agree that it would be good to improve widget management.

  1. Grouping – this nesting thing is difficult. The whole point of widgets is that they are independent. The widget render function is only called once, so it would have to save the nested widgets as its option data, and invoke the render functions of those. And could you have a group within a group? Is there a limit to nesting? Is there any real benefit (perhaps if there are style options) to a group? If style is the main benefit, how does the theme account for user styles, or does the theme supply the style options (as my theme does)?

  2. rearranging widget list – I personally don’t like icons and since I know the list is alphabetical, it’s easy to find things. I am not averse to having three groups: core, plugin, theme. The core widgets don’t really need descriptions, but the custom widgets usually do.

3,4. I think saving a widget for reuse and duplicating a widget go together. I have often wanted to be able to do this. The Inactive Widgets list could be improved to handle this.

  1. widget presets — YES! I tried my best to achieve this in my theme, but it is not really correct. I think the core logic for the widget areas could be made into more logical functions that are filtered. The existing filters do not cover all the cases.

  2. import/export widgets — there is a plugin for this. I don’t see it as needed in core.

  3. custom widget group — I mentioned this above. What needs fixing is the core logic for guessing widgets when switching themes. I was helping to test that code in WP, and they ignored my report that custom widgets get dropped. This is important for my theme, which is all widgets.

  4. tabs for options — perhaps. If you look at my theme, you’ll see it adds styling options to every widget. But every theme would have different style options. If you think core should be involved in basic styles, you should just go use WP. If you want the widget screen to show a preview, you should just use the Customizer (or go use WP). Every widget has different options. There shouldn’t be so many options that it needs tabs, although some plugins have complicated widgets, but they can provide tabs and the JS to handle it, if they want to.

2 Likes
10

I see you included here questions about who CP is for. I hope you don’t mean to re-open discussion about the tagline.

11

I’m with @joyously on the grouping of widgets. In my case, it’s less about disliking icons and more that I often guess wrong about which group the thing I’m looking for is in. So then it takes me longer to find it than simply relying on alphabetical order.

I agree that BB’s layout looks nicer, but that’s just more modern CSS. The whole CP admin could benefit from a CSS overhaul. But prettier isn’t necessarily more functional.

1 Like
12

If you are going to try doing something here, I’d suggest starting by simply laying out the widget areas in their appropriate places: at the top, left, right, bottom, or whatever. Then at least you’d have more of a match with the front-end.

Not sure where you’d put the list of widgets themselves then, though. A modal seems to be what you’re considering, which might work well if you can ensure accessibility.

13

I’m with you on this. And, even when I first started using WP years ago, I always found widgets one of the easy things. Drag, drop, and done!

14

Laying out the widget areas “where they go” is done in the Customizer.
Doing this on widget page would be difficult in my theme, since you can choose left/right/no sidebar on every page. Also, header or no header.

Trying to drag and drop from a modal doesn’t seem that great.

The thing about the admin UI is the user often forgets that visitors have all different window sizes. They usually only use one, and want it to look right on that, forgetting that not everyone will see it that way. The Customizer has a control to shrink the preview, although it’s not very prominent.
Web publishing has to be flexible, so any presentation of front end in the back end needs to de-emphasize exact positioning of items.

15

Is it really? I hate that thing so much that I can’t remember the last time I used it. And how on earth is there room for that?!

Absolutely! After I left my last comment, I have been thinking precisely about that. What might be a horizontal widget area on a desktop screen would be vertical on a phone, and phone browsing is far more common than desktop or laptop browsing these days. In addition, CSS might dictate that what is nominally a left sidebar goes below what is nominally a right sidebar when on narrower browser windows.

16

I used to hate the Customizer, but they improved it a lot.
Since it shows the preview of your site, the sidebars are “where they go” regardless of which page you navigate to, and any changes you make are instantly shown there. And you can click the Preview Size control at the bottom of the Customizer panel to see how it would look at different window sizes.
One downside to widgets in the Customizer is there is no Inactive Widgets list. The other is no drag and drop between areas.

17

Isn’t providing non-coders with layout capabilities what page builders are for? Unless I misunderstand (entirely possible), seems like we’re talking about twisting widgets into something they aren’t meant for.

2 Likes
18

The idea wasn’t a full blown page builder, but rather an easier way match backend and the frontend. BUT, after spending some time thinking about it and trying to figure out the best way to do it I realized there’s really no middle ground between a page builder and a more advanced widget area. There’s too many options to consider, which ends up in page builder category.

So I want to go back to my reply about improving the existing functionality of the widgets and the widget area. It would remain in the original vertical layout.

Based on what I described, I did a quick mockup of what it might look like. There are no modals. The mockup includes numbers, which you can find below the image. This is a ROUGH, quick mockup.

image
image3466×1781 172 KB

  1. Widgets would be grouped based on where they are registered.
    • Available (could also be Default or Core) widgets are the ones shipped by the core.
    • Theme widgets are registered by the theme, this is also where presets shipped by the theme can be found.
    • Plugins widgets are the ones shipped by the plugins. Ideally, we would want to add additional sections per plugin to help users see what’s where but might not be necessary. This is also where presets can be found shipped by plugins.
    • Saved widgets are those widgets users saved to be re-used. Unlike inactive widgets, the widget always remains in the saved tab until user deletes it from there. So when user uses a saved widget, it duplicates itself keeping original and using a duplicate in the widget area. Refer to number 4 below for the saving part.
  2. This is a search. It filters all registered widgets and shows the ones matching user query. It’s a quick way to find widget you’re looking for.
  3. The widgets would be a bit smaller, with no text description be default. A text description could be provided by either a tooltip on hover or a question mark icon to display a tooltip with a description.
  4. The widget itself would have a “Duplicate” option, which duplicates the widget and its settings right below the original. And the “Save as” option allows user to save the widget and its settings to be re-used later as discussed in #1.

This is a rough mockup. Accessibility would follow in the footsteps of the current accessibility features.

If this is something we want to explore, I can work on making a more details HTML version.

On a separate note, specifically for widget options that theme/plugin developers can set, I think it would be good to give developers an option to break down their widget settings into tabs so it’s a bit easier to navigate when widgets have a lot of options. Example uses Joy’s twenty8teen theme, which registers this gallery widget.

Here’s an example mockup of tabs:

image
image1578×731 37 KB

If we wanted to standardize these tabs, we could create Content, Styles, and Options (or Advanced). The developer, when registering a widget, would also register which tabs the widget will use. No tabs registered means no tabs shown.

Goal

The goal is to improve user experience, so it’s easier to navigate and no options overload.

Borrowing an example from aviation, planes have a ton of switches but the UI/UX has improved over the years making it easier to use:

image
image1920×554 140 KB

Credit Aviation Maintenance Magazine.

1 Like
19

This is exactly what the Customizer is for! You can see it all as it will look to the visitor, but it isn’t published yet. The widget page saves to the options table, so any changes are live immediately.

My theme does not register a gallery widget. That is a core widget. My theme adds options to all existing widgets, so they can be styled individually. I could easily make it tabbed myself, but I didn’t want to add more JS, and I didn’t know if a plugin might have made it tabbed already. I don’t think widgets should have tabs, especially not a Style tab, since styles should be done by the theme unless it’s a plugin’s widget that is styled by the plugin.

Aside: I just saw this commit at WP

WordPress commit r53633
Editor: Alphabetize block lists in various places.

20

Yes and no. Yes, it offers a preview but it doesn’t always match the layout. They’re always stacked vertically, so modifying a row of 3 widgets in the footer doesn’t match the sidebar’s vertical layout in the widgets section of the Customizer. It helps for sure, just not the way I was thinking about it in terms of layout.

Then why does your theme add styles to widgets? :thinking:

The idea is that the theme/plugin could declare support for tabs, similar to how CPT declares support for various features using supports. It is still controlled by theme since theme declares support and provides actual options, but the user is given a little control over the widget. This is basically theme options specific to the widget.

In your theme, you’ve given the user an option to change size/position and alignment.

My example using tabs simplifies UX/UI of the widget, reducing options overload and grouping options using relevant and standardized tabs.

While doing a lot of training for clients showing them how to use Beaver Builder (8 years worth of feedback), they’ve always liked the tabs in the modules because it’s easy to see where options they need reside. They also love the ability to filter using search, so they don’t have to keep looking for something.