Widgets: Initial Thoughts

Widgets 2.8Widgets are part of the “secret sauce” that make a WordPress site yours. Dropping a text block, your latest tweets, and a menu into one of your site’s sidebars is one of the core features used for customizing the content of your WordPress site. Widgets were first introduced as a plugin from the fine folks at Automattic, and originated on WordPress.com in 2006. They were added to WordPress Core in version 2.2 in 2007. In 2009, version 2.8 brought with it a redesigned widgets interface with a focus on inline editing and drag-and-drop interactions. Since then, the interface for managing your widgets hasn’t changed much.

Widgets in WordPress 3.6

Widgets 3.6In the latest version of WordPress, 3.6 “Oscar”, which was just released on Aug 1, 2013, widgets are cleaner in their appearance but otherwise work the same as they have since 2009.

Enter MP6

In March of 2013, Matt Mullenweg introduced the MP6 plugin on the Make UI WordPress blog. Outside of being the poster child for future WordPress development, MP6 aims to simplify the wp-admin interface. Here’s how MP6 (version 1.9) displays the widgets screen on my site:

Widgets MP6

A few problems…

Lets go over a few of the bigger problems with the existing widgets UI.

The Sidebar Connection

First off, its a little confusing at first glance. The concept of sidebars, which is where widgets are placed, it not very well defined anywhere. The vertically stacked boxes, which each represent a sidebar in your theme, have no actual association to their location while viewing the theme.

The Wrong Focus

More than 75% of the page is consumed by the “Available Widgets” area. This is a collection of the all the widgets that are installed, including those from core, plugins, and themes. With even a few widgets (12 in my base core install), this screen is very intimidating. Add to this the “Inactive Widgets” area that may show if you have saved widgets, and you get a large page full of little boxes.

For the initial setup of your widgets, this layout isn’t terrible. Ignoring the huge potential for analysis paralysis, its likely that during your initial setup you’d like to pick and choose from a list of available widgets. However, after you’ve got things the way you like, updating those widgets becomes a huge pain. The sidebar area, where you update and reorder your selected widgets, is very narrow. Reordering widgets in, and between, sidebars could easily be constrained by the window height making it difficult to drag and scroll.

How do I install widgets?

For new users, the fact that widgets can’t be installed alone is confusing. We all know that widgets come from a few places (core, plugins, themes), but this isn’t obvious to those new to WordPress.

Fixing the Focus

The connection between widgets and sidebars is related to the focus on the “Available Widgets” area. What if we flip the focus around, giving sidebars more room and pushing the “Available Widgets” to the side.

Widgets - Flip Focus

This is a little better, as it gives more breathing room for sidebars, but we can only fit two sidebars before needing to wrap to a second row. Also, this doesn’t really fix the problem of having to see all the available widgets everything you visit the section. Lets take it one step further and dedicate the entire screen to managing existing widgets.

Widgets Become Sidebars

Huh, this is getting interesting;  Removing the “Available Widgets” section all together shines a light on something. What we’re now looking at is a list of sidebars, which contain widgets. Putting the focus on the sidebars, even renaming the section, actually helps reinforce the connection between your widgets, their sidebars, and their theme. Since removing the list of available widgets, there’s no way to actually add a new widget.

Lets see what we can do to further reinforce that connection.

Sidebars Proper

Adding visual and description locations for each sidebar helps emphasize the connection with the Theme. Taking things one step further, we can add a reminder of the current theme and the total number of sidebars available with that theme.

Adding a Widget

This is starting to take shape, but we’re missing a key piece: How do I add a widget? In the wireframes above, I’ve added an “add a widget” link. I first thought about having a single link for adding widgets, but you can see in the last wireframe that I added a link for each sidebar. With a single link, once you choose the widget to add, where do we put it? We could put it in the first sidebar, or ask the user to select a sidebar — or we could add a link for each sidebar and make it a more implicit decision.

OK, but what happens what I click that link? I have an idea, but lets talk through the thought process a bit. Here’s a few key points I have in mind for a successful widget selection UI:

  • When you click the link, you want to choose from a list of available widgets.
  • There may be any number of available widgets; Its easy to imagine having anywhere from 10 to 100 widgets available.
  • With the possibility of having a large number (20+) widgets being common, it should be easy to browse, filter, and search through them all.
  • You should be able to choose from your inactive widgets, as a sub-set of the available widgets.
  • It should be just as easy to add one widget, or 5 widgets at once.
  • You should be able to customize your widget as you add it.
  • However it looks/works, it should be future proof.
  • The process should feel like a natural part of WordPress. Lets not reinvent the wheel.

About that idea…

3.5 Media UI

In WordPress 3.5, the new media interface introduced a brand new modal convention to WordPress. Its a beautifully simple way to browse, add, and edit a large number of media items for your site. It defines a design language for things like searching, navigation, editing details, loaders, buttons, and more — I’m a huge fan.

It also happens to be a great starting point to solve our problem of adding widgets. Clicking on the “add a widget” link could open a media-like modal which lists all the available widgets.

A Few Concepts

I’ve worked up a few mockups based on the ideas above. I’ve tried to respond to many of the key points we outlined above:

  • New ways to filter and search widgets.
  • Added a way to browse inactive widgets, navigable via the left-hand side).
  • Choosing a widget displays its option on the right, letting you customize it as you place the widget.
  • Just like media, you can select multiple widgets to add. I haven’t thought about adding multiple instances of a widget.
  • Widgets get an icon!
  • Editing widgets happens similar to how it works currently.

What do you think?

So I’ve laid out my thoughts, and presented some wireframes and early mockups. I plan to march forward and continue work on this rethink. I’d love some help. Leave a comment with your thoughts; Catch me on twitter; Ping me on IRC or in the Make p2’s (I’m shaunandrews). Lets work together to make widgets in WordPress even better than they are today!


14 replies on “Widgets: Initial Thoughts”

The concepts appear to be a big improvement on the current situation, but I have some thoughts.

We build sites for clients who are not very technically savvy, at all, and when it comes to widgets the issues we have are:

1. Clients initially have trouble thinking of sidebar widgets and page content as separate things. When they click ‘Edit Page’, they expect to be able to edit everything, including widgets in the sidebar.

2. Clients almost never want the same thing in the sidebar for any two pages.

Those issues are mainly issues with sidebars, they have an easier time grasping footer widgets or things in other weird places that they expect to be constant.

I don’t have a solution for this, but to me it appears that Widgets just aren’t intuitive to regular people. Maybe they were when all that existed as a list of posts on one side and ‘widgets’ on the side. But with a lot of themes going with more complex layouts it’s not at all intuitive how to edit the various bits.

I think your mockups are a good idea for how to improve Widgets as they are currently implemented, but I think some thought needs to go into re-imagining how editing works entirely, along the lines of what they’re looking at in Make UI.

I agree. Clients expect to be able to control the contents of a page from the edit page link. Why wouldn’t you? Let users choose which widgets appear on each page.

The Joomla-style module approach is a decent, sustainable alternative.

One should be able to drag a widget and drop it anywhere on a page. This means widgets needs to be available on the side in any page/post. For instance click the drop down select the widget, fill in the options for it and then drag and drop it anywhere on the page. I have created a mockup for this and other ideas for instance incorporating templates, a table like grid to where one would drop elements. http://easywebdesigntutorials.com/wordpress/wordpress-mockups/

I think the concept and mockups made by Shaun are, IMO, right on-the-spot.

Still, the considerations Jacob made are equally reasonable.

These are my 2 cents on viable solutions for these problems:

Problem: Client wants different side content for each section of the site
Solution: Make sidebars chosable on single-template basis. For templates i mean not only the ones defined in the theme, but also the built-in ones (generic/blog, categories, archives, front-page, ect.). Then, put a link below the template select in the “Page attributes” meta box which points directly to the edit screen for that specific sidebar.

Problem: Sidebar and Widget editing and/or location is not clear for the end user
Solution: Put the editing in the front-end. I think this is already a milestone for 3.8, and it could be super-useful when applied to widgets. Adding and modifying widgets could be a no-brainer when you see the result at once. Also, the add-widget modal concept explained by Shaun could fit perfectly even in the front-end.

What do you think?

Hey there,

I come from two worlds where I started with Joomla! as a CMS first, and then moved into WordPress. Both have their strengths and weaknesses (WP has more strengths than Joomla!, IMO), but widgets (or modules as they’re called in Joomla!) and ACL have always been something that Joomla! has been far superior with.

Since ACL isn’t the topic right now, I’ll focus on the widgets side of it.

The way Joomla! handles module / widget control is to have a single page for the list of all the modules, with a details page to actually manage the details of the module; very similar to how pages / posts work within WP right now.

Then, within the details page, you can set the data as you normally would for a widget / module. By default, J! has basic display / non-display setting, based on the selection of pages. So, you either include the module on “x” pages, or exclude it.

Now, there is a “plugin” (referred to as extensions with J!) called “advanced module manager” for Joomla! that allows you to dynamically display the module based on menu items, pages, categories, hierarchy, browsers, dates, location, users, user groups, etc. Very, very, veryyyyy detailed display capabilities.

Personally, I love this. It makes the possibilities for displaying a single module almost endless, while still keeping the overall management of the modules simpler on a global level. I think that WP widget management could stand to review this setup for some direction, with obvious WP awesomeness added on to make it even better.

Now, the whole idea of visibility of a widget based on users and their roles (which a user within J! can have multiple roles associated with it), will require a revamp of the very basic and restricting feature that is the current user management setup for WP; but again, that’s a whole other topic (perhaps one that would be addressed in WP3.9).

On a side note, and in relation to what @lucarosaldia R. mentioned about the front-end editing may bring, there’s definitely merit in that. We’ve seen a lot of positive response to projects like Concrete5 from site managers (aka—a lot of our clients). I know that the Pagelines people (www.pagelines.com) just came out with something to start heading in this direction, but my initial testing of it (I have a developers subscription) wasn’t very positive… too many UX things to work out right now; but given it’s the first true stab at front-end management on a global level, it wasn’t bad for their first go-around.

Anyway, my 2¢…


Totally dig this new widgets interface – terrific work. The fact that it uses the media library interface is a great bonus. Love the widgets icons 🙂

Jacob – you’re absolutely right about clients being confused with going back and forth between pages/posts/widgets/menus screens. But there are actually lots of possible solutions for that, that are very client-oriented, and answer their need to “edit it all at one place” – just google “widgets in pages”.

Here a fresh article about it:

I like these thoughts.
Some additional ideas (which may already have been covered elsewhere.)
– I tend to have several text-widgets with empty title: But I’d love to still be able to somehow name them, for my own convenience. I.e. something that wouldn’t be seen on the outside. Perhaps just a check-box “Hide widget title”?
– And an easy way to clone a widget, please. Either to further edit it, or to drag it into a different sidebar.
– Uhm. Should we still say “sidebar”. A more generic “Widget area” better matches the fact that a sidebar can be located just about anywhere on the page: Top, After the top-menu, on the sides, between posts, or in different parts of the footer…

Totally agree with Tor-Bjorn about the naming. Widget Area is definitely more semantic than Sidebar. For developers, get_widget_area() and register_widget_area() could replace their _sidebar() equivalents, which should stay as aliases.

One of the things I’d really love out of a widget/sidebar revamp would be a clean way to deal with conditional sidebars. Our site has information from a multi-country team. Each Country has a page with a country-specific sidebar, and each post uses a country-specific sidebar (country specific contact information).

Every time you add a post you need to scroll through 44 sidebars! And it’s essentially telling the system the same thing twice “This is an X country post” in categories, and “This is an X country post” in the sidebar chooser.

I would dearly love for there to be a canonical way of doing conditional widgets. i.e. “In this widget area, if category of post = ‘Madagascar’, then insert ‘Madagascar Contact Information'”. I suppose you could make it work with taxonomies in general.
The other issue isn’t so much with the widgets screen as the ability to over-ride settings on a per post basis. This seems like a really useful tool for novices who don’t really grok the whole widgets concept – some themes could simply default to empty widget areas with the expectation that people would fill them in on a per page basis.
As for the naming, I think that while Widgets Area is more general, its much less intuitive for beginning (and even some advanced) users. I might go “Sidebars and Footers” as the high level name.
Lastly, it strikes me that if Mel is doing a “Content Block” approach to building page and post content… Aren’t widgets essentially just a form of Content Block? Might there be a grand unified approach to content blocks whether they appear in a sidebar, footer, page, post, front page, etc.?

One more comment – it would be nice to have a robust preview function for widgets, maybe with an auto-generated lorum ipsum post. As it is, figuring out what a sidebar is going to look like is not super intuitive.

Very nice work, but i really don’t enjoy the editor style mode.
The pop-up introduced looks heavy sometimes.
If was possible using ajax or something more on demand, not a popup.

BTW. 10x times better than now.

These are nice concepts, but I loathe the concept of “click to add a widget”. I’d rather go with a mix of the media manager-like concept, letting you add multiple widgets, maybe with a tab or virtual steps (eg. #1: select widgets => #2: select sidebars you wanna add em to). Prolly gonna tackle this in a seperate post at my site with an analysis about the “whats the major caveats” or similar.

The custom sidebar problem is an entirely different one, which is already being adressed by countless frameworks (currently working with Jumpstart / Themebvld, which solves this rather nicely, but still too nasty for real developers). I’d address that in a seperate step, AFTER giving the widget section a good usability overhaul.

cu, w0lf.

Leave a Reply

Your email address will not be published. Required fields are marked *