WordPress Sidebars as Menus: Part 2

Continuing thoughts on a different way to display WordPress Sidebars and Widgets.

Happy Thanksgiving.  Here are some more ideas, partly based on the comments left in post #1.  At the bottom is a gallery of all the various mockups, and feel free to download, tweak, etc.

More Compact

Instead of a big Sidebar Locations box in upper left, what if you made location an element in the Sidebars themselves (Primary, Test)?

This has the location selection in the Sidebar Area itself.  I’m not sure if I like the multiple saves, but if you have a long Sidebar Area, it seems sensible I made the space a big bigger with the idea that plugins could hook in and add things.  More on that in a minute.  You’ll also notice that there’s a scrollbar for the ‘Available Widgets’.  Yeah, we lose drag/drop with this scenario, and while I agree D&D is very cool, it’s starting to get unmanageable when you want to drag a widget over to the area halfway down the screen.  My grandmother said it was impossible for her to scroll in two directions (over and down) while holding down the mouse button.  Mind you, she’s a 90-year-old with glaucoma.

Selecting a Location

Here’s what the dropdown looks like.  Obviously we’re on Twenty Eleven here.  The ‘blank’ is for ‘none’ which, on reflection, may need to become ‘(none)’ instead.  It’s obvious to me that blank == none, but I’m not sure how new users would feel about that.  Yes, my rounded corners suck.

Hover Over

Again, my colors  and icons suck here, but this is a large pointer finger hovering over Custom Menu being told “Use this to….”  My (minor) concern with this is that Akismet, for example, has the description of … Akismet.  Singularly useless.  You’d think it’d be better.  But they’re not the only ones who slacked off on descriptions, so some of these will suck.  Still, color it any which way and a hover-up will provide information.

The major concern I have, again, is accessibility. I’m hoping that this has already been hashed out before and we don’t have to invent something all new to allow screen readers to parse what things are for.  That would be a deal breaker to me.

New Sidebar Screen

Here is the ‘new’ screen, complete with directions and a button.

Jane's Suggestion - Green

By the way, since I suck at gradients, I opted not to make ‘Create Sidebar’ in the button, but that’s a nice idea too.  Of course, with Jane’s recent post about the square button, that  works too.  I spun up a inverse of that, since it mimics the blue background and looks ‘obvious’ to me.

With Description

I LOVE the idea of a visual guide to where the sidebars are. Makes me think of Stephanie Leary’s layout fiddling with IDs:http://sillybean.net/downloads/widget-admin-ui-altered-with-ID.png (Trac ticket #18334:http://core.trac.wordpress.org/ticket/18334 – some other cool ideas there, too.)

I love Stephanie’s idea too, but. I really didn’t like the ‘uneven’ feel of her screen (not her fault, it’s just CSS layouts drive people to drink).  Her’s works because you see where the widgets are going to go.  I would want to have it be a wireframe.  This is one idea for where to show the description, though I’m not really sold on it.

Sidebar Logic

know that Jane mentioned per-page widgets as a priority (maybe in IRC?), but we’ll have to wait until after the core team meet up to see what they decide on as goals.

On the other hand, I really like my idea for Sidebar Logic.  If you’ve used Widget Logic, you get the idea.  Put in the PHP to say ‘This Sidebar shows up on the Main Sidebar area IF these parameters are met.’  It’s not as ‘per page’ as Jane probably had in mind, though, and I’d like to see it avoid the need for PHP, but on the other hand, I’d love to see something plugged in there.

That’s all I have for you today, but here’s the Gallery, as promised!


  1. IMHO, one of the benefits of this approach is the UI consistency between Navigation Menus and Widgets; so, I think that if you’re going to propose changing the UI such that the theme_location resides inside the “set” (i.e. “menu”) meta box for Widgets, then we should do the same thing for Navigation Menus.

    But, I’m wondering if we shouldn’t consider keeping the separate theme_location meta box. I think there is value in the UI indicating that custom menu != theme_location (and its analogue, that Widget set != theme_location). In the current mock-up, the UI implies that theme_location is meta data for the Widget set, when in reality the opposite is more correct.

    Granted, the analogy between Navigation Menus and Dynamic Sidebars begins to break down in the theme_location meta box, merely because a Theme is only likely to have 1-3 Navigation Menu theme_locations, but may have anywhere from 1 to 70 dynamic sidebars. So, the UI would have to account for that (e.g. the meta box would have to be limited in height if listing dynamic sidebars as text inputs – or would need to list them as a dropdown select instead).

    • I’m far less concerned about making them ‘exactly’ the same as I was 4 days ago 😉 To the point that I was thinking of switching the columns so they resize differently. See, on my small (skinny) example it all looks nicely balanced, but if you pull it out wide it wouldn’t scale as well. Look at all that dead white space on the right now. It’ll only get worse, and people like Nacin who like it full screen would suffer.

      The 70-fucking-widget-areas. We’re talking about A Theme With 70 Different Widget Spots (areas, Jeff 😉 ) and yeah, that was on my mind when I looked at this. My feeling is this: That’s a shitty theme and while it would be easier with the dropdown to manage assigning your named sidebar to the theme’s defined sidebar area, that shit’s unsustainable today.

      Taking a quick look at menus today — http://cl.ly/1O2u0p2h0R2W3m1H0j0t — Yeah. Width is an issue when you get ‘too many’ menus, but it very nicely scrolls left and right so I think … I think that the extreemes on each end (no sidebar areas, and a gazillion) should be dropped from the discussion. None are easy to handle. Over 40 would probably never be okayed by theme review. Would it, Chip? 😉

    • Great work on the sidebars as menu concept! I’m a big fan of this idea because the widgets are too clunky when you have different sidebars for different pages. I’ve been either creating different page templates with different sidebars for my clients or using Custom Sidebars so that they can create their own sidebars and have different widgets on a “per page” basis. To be honest I’m not a fan of either of those ways but it’s the best solution I’ve found for the meantime.

      I had a serious chuckle when you mentioned “The 70-fucking-widget-areas” cause that’s pretty much the reaction I had when I saw Jeffro’s post on that theme as well. I can understand the need for lots of widget areas in a theme but I’d love to see the look on someone’s face when they click on Appearance->Widgets and see 70 sidebars waiting for widgets!

      Keep up the good work Sir!

  2. I really like this concept and think it would be a great improvement over what widget management is to become (especially with the new changes to handling configs from previous themes).

    I agree with Chip on several fronts. This would bring us a long way to building UI consistency between Menus and Widgets. I’m also on the fence about keeping the theme_location metabox. On the one hand, you get the more compact feel if the location selection is in with the widgets, but it might be prudent to consider that it’s not something to be overlooked by being crammed in with a bunch of other elements.

    I like the checkbox selection for widgets (also in keeping with Menu UI) as you’ll be able to list more available widgets in a compact way. But I also think that removing the D&D aspect will make the UI more mobile-friendly, specifically touch-friendly. The only thing nagging me a little bit about going frm D&D to checkbox and click-to-add is consistency between how to A) Add widgets and B) Move widgets around. Currently, with your checkbox dropdown, you click-to-add then have to use D&D to move them around. Personally, I like D&D to re-order stuff so it’s hard to make up my mind whether consistency should rule.

    One idea that immediately sprang to mind for handling widget descriptions might be by using tooltips. Personally, I’m kind of partial to click vs. hover tooltops (also more touch/mobile friendly).

    Finally, +100 for integration of sidebar logic. Not everybody would have use for it but those who did would likely appreciate it (maybe hide/show via screen options).

    • One idea that immediately sprang to mind for handling widget descriptions might be by using tooltips

      That works too. Mostly that image was just to show you what’s visually possible, and I’m far less invested on the click vs hover debate. My gut feeling is a newbie would notice it if it hovered.

      Maybe use the new WP tooltips in 3.3 so the first time you open up Widgets it says “New feature! Hover over/click on the widget name for more information about it before you add it!” and then the education part is done. Can’t make ’em RTFM, but you can CYA.

      The only thing nagging me a little bit about going frm D&D to checkbox and click-to-add is consistency between how to A) Add widgets and B) Move widgets around.

      For what it’s worth, that’s the same as it is on Menus today. Click to add, drag and drop to organize. I think it’s better than the way we do images in the gallery, or the old way for pages (with the order number).

  3. Some more thoughts:

    Definitely need a way to see description before adding to the menu. Maybe if you click on the label it can show something somewhere, whether tool-tip-esque or even a dedicated div somewhere on screen.
    Given how much of a PITA long menus are, I’d REALLY love to see a “send to top” button/link on an individual item.
    Consistency between widgets and menus screen is an awesome idea, especially as I’m still thinking about the pursuit of responsive admin for 3.4. We could definitely address the use of whitespace 🙂

    • Consistency != identical, though, which we must keep in mind. In the endless form vs function debate, we shouldn’t sacrifice functionality to make everything matchy-matchy.

      As for seeing the description, maybe if the mouse icon flipped to a ? when you hovered as a cue to click?

    • True. I can’t imagine that they would be exactly the same, and in fact the whole checkbox thing is still kind of a hang up for me. Some kind of similarity seems like it would both help to ease in users and to make UI work a little easier, at least. The lack of a large-screen plan for the widgets screen was part of (most of?) the downfall of most of the planned responsive stuff in 3.3, so it’d be nice to have it be a little closer to another screen, or vice versa.

      I think my whole issue with the checkboxes or some other way of displaying the description on interaction is exactly that – there’s one extra step and also one extra thing to have to compensate for when thinking of mobile/touch screens. Not that drag-and-drop is mobile-friendly to begin with, though. I’m just trying to start from an all-inclusive mindset more often.

      I still really like where this is going! And new-style buttons 🙂 Might have to start referring to them as widget groups and widget areas instead of sidebars for real now.

    • We’re using checkboxes on menus right now, though, for pages and all. Or are we talking cross-purposes again?

      The lack of a large-screen plan for the widgets screen was part of (most of?) the downfall of most of the planned responsive stuff in 3.3, so it’d be nice to have it be a little closer to another screen, or vice versa.

      Yeah, I was thinking about making the widgets on the right show up in double columns, but that doesn’t work at all either. The best I can think of is make a ‘defined’ width for the widgets on the right, and then let the items on the left shift over to fill in the space?

    • A little at cross-purposes 😛 I don’t like it for the widgets screen because the widget title doesn’t always tell you what the widget is for, whereas (one would hope, anyway) page/post titles usually tell you what they’re all about. Maybe this would help kill off plugins that name their widgets stupid cutesy things, though!

      My recollection is that the original plan for the widgets screen at wide res would be to pop them up next to each other instead of having them all in one column. It would have been nice, and if the widgets screen doesn’t change, maybe that will still happen.

      Also, looking at your widget logic bit – also awesome. Now, to come up with terminology for the average user 😀 And a good UI. Actually, that Chosen multi-select one you saw last night might not be a bad choice…

  4. Thanks for publishing this. I’ve been saying that sidebars need to be handled like nav menus since the new nav menu system was put into place. Using the theme locations idea would do away with most of the problems people have with sidebars/widgets today, especially when switching between themes.

  5. This is such an elegant solution to managing widgeted sidebars on WordPress! We are constantly dealing with sidebars, trying to find user-friendly ways for clients to manage different ones for different pages.

    I hope your idea gets taken beyond the concept state!

  6. Almost everything important was said but what I really would like to see there is some kind of list for ALL widget locations/areas in theme with assigned widget sets. As I see it is quiet important to know what areas are still unused or what is where. It would also be great if I can unset more widget locations/areas at once.

    I hope it will be implemented to the core soon.

  7. Interesting approach. I attempted to tackle widgets from a different direction.

    I used the Advanced Custom Fields plugin by Elliot Condon, them created a new Widget custom field. It allows you to list all configured widgets for a sidebar and select which ones you want on a page-by-page basis.

    Since ACF already provided the fantastic UI, the widget list is filterable for those 30+ widget sites.

    I added my custom field file to one of ACF’s forum posts if anyone wants to check it out.

    I’ve since added inheritance (inherit widgets of parent) and a few
    optimizations. It’s working well for us.



    • Alas, I cannot get those attachments to download (don’t worry about typos, I’m a typo queen).

      One of my pressing concerns was ‘How easy would it be for newbies to use it?’ That’s a massive drawback to Widget Logic, in my mind. It’s easy if you get !is_home(), and it’s a PITA if you don’t. Anything implemented in core must be straightforward. On top of that, we have decisions, not options, to keep in mind.

      If you can link to a screencap of what it looks like? Obviously I’m a bit visual sometimes 😉

    • My apologies. I should’ve posted screencaps from the beginning. Not sure what’s up with the download.

      Image 1 is what the user see’s on each page. For each active sidebar, there’s an ACF “relationship” field that lists all configured widgets on the left and all selected widgets on the right. Credit goes to Elliot Condon and ACF for the interface. You can click or drag items from the left to the right. The search box above the left side filters your options – making it very simple to sort through long lists of (in this case) widgets.

      Image 1

      Image 2 shows what the inheritance option looks like. When inheritance is set, you get an option to “Inherit from Parent” in your list. You can select this option to inherit all widgets used by the page’s parent (or menu parent), plus add and additional widgets this page should use.

      Image 2

      Image 3 shows the ACF configuration. You simply add a new field, select Widget Filter as the field type, then select the sidebar it applies to and what type of inheritance it should use.

      Image 3

    • Aaaah! I see what you mean. I have a different idea 😉 Working on it right now actually. That looks crazy complicated for new users, but very powerful. That balance is so hard to find.

    • The last screenshot is just when you initially configure the ACF field. Image 1 is all the user has to deal with. Our users have loved it.

  8. Hi Mika. I really like the interface and I agree that it’s way easier than the drag and drop one, especially with a lot of widgets and a lot of sidebars, good job! I also thought about per-page or even per-post sidebars, with such an interface, where users can create as many sidebars as they want, they would be able to “assign” a different sidebar to override a default one on a certain page. Like have one with a map widget on your Contact page. There are “sidebars manager” plugins being built to do just that, but obviously a mess with the current interface.

    Anyway, thanks again and hope this makes it into the core sooner or later 🙂
    ~ Konstantin

    • I’m very split on ‘Should we manage per-page menus on the page or on the menu-page?’ decision. It would clutter up either way, but as a meta-box on the actual page…

      “Sidebars: Default” and then a drop down to use different widget “sections” per page? That is, if I define a sidebar as ‘Front Page – Footer 1’, then I go to the static front page, and there under ‘sidebars’ select the ones I want from a drop down… Doodle time!

  9. This is a great idea and an interesting conversation. I felt the need to chime in and give a large thumbs up to this getting the continued discussion and due diligence it deserves within the community:)

Comments are closed.

%d bloggers like this: