WordPress Widgets and their effect on Admin UI Design

In my recent posts I’ve been talking about Admin User Interface (UI) Design in WordPress and how different built in WordPress features can effect UI design in both good and bad ways. The subjects I’ve covered so far are:

In this installment I want to discuss Widgets.

What are Widgets

You can read the full explanation of widgets in the WordPress Codex. I just want to highlight some of what it says there:

“WordPress Widgets add content and features to your Sidebars…”

“Widgets were originally designed to provide a simple and easy-to-use way of giving design and structure control of the WordPress Theme to the users…”

“Widgets require no code experience or expertise…”

All of that sounds pretty good, doesn’t it? All of the things I’ve been talking about in my posts. And it would work well if all developers kept this in mind when creating and using them. However, like all things in WordPress they can be used to improve the Admin UI or to make it into a confusing mess.

The Good, the Bad and the Ugly

First I want to take a look at the widgets and the widget UI that is installed with the default WordPress Theme, it is pictured here with some annotations:

Looking at the above image you see the three main ideas here:

  1. The widget area name: The name of the area should be a good indication of what it is used for so that it’s easy to spot when we need to change something.
  2. The widget area description: This should be a good enough description that even someone that is unfamiliar with the site admin can figure out where on the site it will appear and what it does
  3. A simple, Intuitive UI: Of the 3 major points made about using widgets in the WordPress Codex this encompasses 2 of them.

Now let’s take a look at some of the ways I’ve seen widgets bastardized and ways to correct and avoid them.

Poorly Defined Widget Areas

When a developer adds widget areas to the site they call a WordPress function in the theme functions file. The arguments supplied to this function allow the developer to set the name and description of each widget area. What happens when they fail to include these values or do not use descriptive names? You get something like this:

What we have here are generic names that have no meaning whatsoever and no description of how or where they are used. This means that the user of this interface will need to:

  1. Already know where they are used and remember this when they need to alter a widget.
  2. Make changes and then search the pages of their site to see where the changes appears.
  3. Understand PHP and WordPress function and search the theme files to see what templates use each of the sidebars.

There is only one way to define this and that is poor and lazy workmanship and it does not reflect well on the developer that did it; their attention to detail is poor. The fix is simply to take the time to add names and descriptions to every area that will allow others to easily identify how they are used.

The Text Widget

The text widget is, in my option, the most used and abused widget in WordPress. Let’s go back to the WordPress Codex Page. At the top of this page, like I already discussed, they go into detail about why you use widgets; to provide an easy to use interface that does not require coding experience. Then we get to the part where they’re explaining the different built in widgets and the only one that gets any real attention is the Text Widget. They go into detail about how you can put HTML and other coding into a text widget. This is completely contrary to the stated goals and reasons to use them in the first place.

I was going to provide an image here, but I don’t think I need to. If a site is going to be given to a client to maintain and they will need to alter what is in the widgets on the site then using a text widget is a poor choice. If you’re going to use widgets to manage content then you need to learn how to build custom widgets with intuitive interfaces, otherwise your best choice is to forget that they exist.

A better alternative to using the text widget is, as always, custom fields and possibly custom post types. You could create a custom post type and add a WYSIWYG editor custom field to it to allow easy editing of this content. You can also add a custom field to allow the user to select where the content will appear on the site. I’m not going to go into great detail on the specifics of doing this because it depends on the specifics of what needs to be done for a given site.

Widgets for Content

Using widgets for content means that you’re going to use multiple text widgets which we just a talked about above. I bring this up because I want to tell you about I site that I had the pleasure of working on, NOT!

The site used widgets to add multiple content areas to a page and posts. There were in excess of 50 pages on the site and there were 2 widgets for every page on the site to allow the addition of editable content to the left and right columns on each page. Did you do the math? That’s 100 widget areas listed on the widget page just to hold content! It meant that the editor had to edit the main content on the page in question and then go to the widget editor page and figure out which of the 100+ widgets to edit to change the rest of the content on the page. This job was not made easy either since all of the widgets had generic names and no descriptions, not to mention that if the editor ever wanted to add a new page they’d have to contact a developer to get new widgets they would need added. Is there any question why this site did not get maintained or updated? Is there any question about why this site was poorly built? If there is than you  haven’t been paying attention.


As you may have already figured out, I’m not a big fan of widgets. Widgets are for adding items to many pages of a site that will not likely be altered; for showing navigation menus and other site-wide content that will rarely need to be edited. For any other purpose widgets are a poor choice if your goal is to create an intuitive admin UI for your client. There is almost always going to be a better way to accomplish the same thing by using custom post types and custom fields.