WordPress Custom Fields and UI design

In my last couple of posts I’ve been talking about Admin User Interface (UI) Design in WordPress. In my first post I went over the importance of good admin UI design and next I talked about custom post types and taxonomies.

Now I would like to discuss custom fields and the proper way to use them to improve your admin UI design. First I want to highlight what I feel is one of the biggest reasons for UI confusion and complication in the admin area of a WordPress site. The correct use of custom fields is probably the most important thing to consider when it comes to the difference between having either a good UI that is intuitive and having a bad UI that is just confusing and unusable.

You may be familiar with the standard Custom Fields area in the WordPress admin, it looks something like this:

Looks pretty simple, doesn’t it? Just enter a new custom field, type in a value and you’re all set. Now go to the theme template and with just a “little” modification you can show the new custom field on the site. No worries, right?

Now let’s take a look at this same area after a bit of customization has been done:
First of all, I could have made this up, but I didn’t need to. This is from a real site; one of the sites I inherited from another developer. I have blurred out text to protect the guilty, however, I left enough of it clear so that I can point out what’s wrong with this setup. If you look back at it you’ll see HTMC, CSS and Short Codes in the values for the fields. Before I look at anything else this is bad. This interface was created for a client that has no experience with HTML and CSS and the developer that built it was aware of this before beginning development.

Short tags as far as I’m concerned should almost never be used. I’ll get into that more in a later installment of this series, for now I’ll just say that I think they are a rather poor way to do things and one of those WordPress features that should be avoided whenever possible.

Looking back at the example you’ll see that besides the values that are entered there is a drop down list of other custom fields that have been added to other posts. To add to the confustion, just because there’s a drop down doesn’t mean you’ll find the one you’re looking for. WordPress shows the 30 most recently used fields. This can be increased but 30 is confusing enough; imagine looking at a list of 100 or more fields used on some sites. In addition to the fields added by the developer there are lots of things that add fields to this list, like plugins you may be running and the theme you’re using. There is a very good chance that a majority of these fields belong to a plugin which should not be altered and that the field you want to add will not be listed so you’ll need to remember them all.

The other huge problem is that you have no idea what’s needed in the value; is it a simple value? Do you put HTML in there? Does it take something else? This might be mitigated if some intelegence was used when naming a field to give some indication of what should be in it, but since it seems most developers I’ve had the pleasure of dealing with hate to type for some odd reason and others just seem to enjoy making life difficult you end up with field names like “prod_det”, “prod_nm”, “prod_c”, “text_12” and “field_22” there’s very little chance of figuring out what to put in the field by its name. The fact that this list also holds fields used by plugins and theme features could have also been corrected by the plugin or theme developer as it is rather simple to hide fields from this list if they’d just put a little more effort into it. The really good plugins and themes take advantage of this fact and do it correctly. However, the majority of plugins and themes do not and we need to deal with what the majority of developers do.

So here is my list of problems with using the interface as provided by WordPress:

  1. HTML in field values, you must have development experience to use this interface.
  2. CSS in field values, again you must have development experience to use this interface.
  3. Short Codes in field values, rather confusing, you need to know where to edit the content for them and how to find what you want to edit. You’ll need to go to several places just to edit the content for this one page.
  4. You must know ahead of time what custom field you need to add without being able to see it since there’s a fair change it won’t be listed, so you need to memorize what fields belong to what types of posts.
  5. You must know ahead of time what kind of value the field expects, again, you need to memorize what you are allowed to put in each field because these fields allow you to enter anything you want.
  6. Users can add and edit values for custom fields that are for a plugin, theme or another sections of the site, potentially breaking their site in the process.

This is what I was talking about back in my first post on UI design when I said that most developers build based on their level of understanding instead of the end user. This is an interface in WordPress and the developer that built the site knows how to use it or at least they believe they do. They understand everything that needs to be in there, what they can edit and what they should leave alone, again because they built the site.

All that needed to happen was that the developer that built this needed to ask: “Would someone that has never looked at this site and does not know html or css be able to maintain it easily?”, or perhaps “Would someone that is not familiar with WordPress understand it?” The answer to both of these questions is absolutely not. This is a confusing mess that hurts MY head, to say nothing of what someone without my level of understanding would think. Why would you ever give something like this to a client that has absolutely no knowledge of development or experience working with this type of interface?

My personal opinion is that the basic custom field interface should be completely removed from WordPress. If you’re a developer and you’re going to maintain your own site, fine, use it. Otherwise you should ignore it, remove it or otherwise forget it exists. Its existence makes it too easy for developers to take the easy (lazy) way out when it comes to custom fields.

A Better Way to do Custom Fields

Fortunately there is a better way to do custom fields. There has always been the ability for the developer to create a custom interface for the custom fields they add to a site. However, this is not an extremely easy thing to do and it can be rather time consuming. Adding these custom interfaces is likely beyond the abilities of you average WordPress developer and would also cause development to take longer and cost more than the time and funds the developer probably has in the budget for the project.

I could go into a lengthy technical discussion on the proper way to add custom fields, but again, fortunately, there is really no reason for developers to add these interfaces themselves except on rare occasions. This is do to the hard work of a guy named Elliot. He create what I feel is one of the best WordPress plugins there is and that I think should be installed by default on every WordPress site. It’s called Advance Custom Fields. There is also a premium add-on that’s well worth the investment for anyone that does any amount of WordPress customization called Repeater Field. I would not build a custom site without either of these plugins.

This plugin does not remove the need to edit the theme templates to show the custom fields on the front end of the site; not much will. However, that is not the point of using it. The point of using this plugin is to create a simple, intuitive and extremely powerful UI.

Let’s take a look at an example of some of what can be achieved with the Advanced Custom Fields plugin from a site I’ve recently put together:

I’m not going to explain the fields of the different interfaces as I feel they are self-explanatory. Take a close look at it. Isn’t that a lot better than the mess created using the standard custom field interface?

Did this take longer than it would have taken to simply use the built in interface? The answer to that is yes, initially it did.

However, let’s look at the bigger picture.

  • There are quite a few fields here of various kinds.
  • The WYSIWYG editor alone would have taken me as long to add if I hand coded it myself as it took me to create a good portion of this entire interface.
  • It would have taken me longer to create test data because I would not have had a simple interface to add the data with.
  • It would have taken me longer to complete development of the custom templates for the custom post type these fields are attached to because I would not have had a good reference to remember what fields I had added.
  • Then add the time that would have been needed to explain and re-explain the UI to the client and others that needed to enter and edit the content.
  • On top of that you add the inevitable time I would have spent maintaining the site because others could not (and the last thing I want to do is maintain a site, I build sites, I don’t manage content.)

The extra time involved with setting this interface up was inconsequential in comparison to the time I would have spent without using this plugin and taking the time to create it.

Looking over this interface there are several different types of fields and each field has a label and description that quite clearly tells anyone that’s looking at it exactly what’s expected. Not only will this save time in the future, but it should save initial time to launch the site as there is very little explaining or learning required before anyone can start adding the needed content to the site.

And there are other added benefits as well. Using this plugin removes the need to use 90% of the other plugins that exist. Need a photo gallery? Just create it. Need related products? Just add the right fields. You can forget about short codes when you can create any type of field you want. With fewer plugins added to the site there is less chance of slowing the site down so pages will load faster. Combining this plugin with custom post types means that it would be extremely rare that you’d need any other plugins to manage any of the content on a site. Add this to custom post types and taxonomies and WordPress becomes a true powerhouse of a CMS.

Proper Naming of Custom Fields

The last thing I’d like to mention about custom fields is how to name them. Remember above when I said that plugin and theme developers can hide their custom fields, it’s such a simple thing to do that it’s amazing to me that everyone doesn’t do it. All that needs to be done is to start the field name with an underscore. This is right on the WordPress Codex page and there is even a section of that page titled “Hidden Custom Fields”.  People must be really are averse to typing because this is only one extra character to type, oh, and that shift key. Either that or they simply don’t know and it seriously bothers me that someone would call themselves a WordPress developer and not know this. You just name your filed “_product_number” instead of “product_number” and no one will ever see it. When you’re creating a plugin that uses custom fields there is never any reason for anyone but another developer to know these fields even exist. Most, but sadly not all, of the best plugins do this. So, when you’re creating your custom fields, always use the _ to start a field name unless there’s some specific reason that the field should be visible to everyone.