In recent posts I’ve been talking about Admin User Interface (UI) Design in WordPress (WP) and how different built in WP features can effect UI design in both good and bad ways. The subjects I’ve covered so far are:
In this installment I’m going to cover few remaining considerations to think about when designing the admin UI.
On most WP sites you will find menus under appearance. Menus gives a site admin the ability to add a page, post or URL to one of the navigation menus on a site. This was a good idea for the most part, but I do have a couple of problems with them.
- Only someone in the Administrator role can edit them.
This means that if you want to create a new page on your site and you don’t have admin access then you’re going to need to get an admin to add the page to a site menu if you want anyone to actually be able to get to it. In some cases this is a good thing, but in most cases it just…
- It creates an extra step in publishing content.
Step 1: Create the content
Step 2: Add it to the proper menu
One of the things I’ve talked about in several of my previous posts on this subject is the confusion that can be created when someone needs to go to more than one place to edit the content of their site. Don’t get me wrong, there are cases where I use the WP Menu feature, like for a menu that I know will rarely change.
As far as needing an admin to add a page to a menu goes, I’ve seen few conditions where there was different responsibilities assigned to different people. Usually the same person that’s creating the content will be the person responsible for making it live.
My preferred method is to add a custom field to page and custom post type editors to allow the editor to select if a page should be shown in a menu and/or what menu it should appear in. This can even be used for something like an active/inactive switch for a product or some other item on the site.
If you do have an approval system, then this can still be used since the person creating the page won’t generally be able to publish the new page in the first place and when the person that can publish does so it still removes that extra step of physically adding it to a menu.
I’ve posted previously about considerations when choosing plugins. The only thing I’m really going to add here is that all of the admin UI design concepts I’ve talked about also need to be taken into consideration when choosing plugins.
The Magical UI
What is a magical UI you ask? This is where you do something in the UI and the result of your action is completely unexpected and in some cases the expected result is completely impossible. Let’s look at an example from one of the sites I’ve inherited:
When editing the content on a page of a site the editor attempts to add an image to the content of the page. The editor clicks the “Add Media” button, selects and image and clicks “Insert”. The expected result is that the image will be inserted into the content editor at the cursor position.
On the site in question, instead of the expected result this is what happens: The image in not inserted into the content and the image they attempted to insert is used as the header image of the page in question. In this case, not only is an unexpected result obtained but the desired result is impossible to obtain. The client can never add an image to the content of the page.
To make matters worse, this behavior is completely undocumented; there isn’t any way for anyone to know this will happen and it appears as if the interface is broken because the desired result is unobtainable.
The magical UI must to be avoided at all cost. A user should get the result that they expect to get. All features of a UI need to be documented so that the user knows what to expect if it will be different than they should expect.
The object of creating a site in a CMS of any kind, and this includes WP, is to give the people that will be maintaining the site complete control over the content of the site. I think that by definition that’s what a “Content Management System” is.
I recently took over the management of a site where it was completely impossible to add a page to any navigation on the site. All of the menus were hard coded into the templates. When asked, the developer that built the site explained: “All of our clients come back to us to have content added to their site.”
WTF! That was my reaction to that statement. The second was that I was glad that developer was not in range because I would’ve put my foot up his ass. Why the hell did they use a CMS if they’re gonna make the client come back to them every time they wanna add a page? Do they need the work that badly? Locking a client into needing my services to manage content on their site is not something I want to be known for.
So, as you can tell, I believe that the client should have the ability to manage 100% of the content on their site and it is part of my job to make sure they’re able to do so. When a client comes back to have work done I want it to be because they want a new feature added to their site, something new that it doesn’t already do, not because they need me for simple management. If they want us (the company) to add pages and content, which is another service that we can provide, it should still not involve me. I’m a developer, I’m a programmer, I’m not a content editor or a site maintainer. I have better things to do and our clients have better things to spend their money on than having a developer doing content management.
If you’re good at what you do then you should not need to resort to these types of tactics to get the client to pay you for additional work they should be able to do on their own. Make sure they are able to.
WordPress is a CMS and the main reason for using a CMS is to make the content manageable by anyone. Anything that gets in the way of this defeats the purpose of using it. I have three goals when building a site. The first is to make sure that the front end of the site works the way the clients wants it to and the way that it was designed to work. The second is to make sure that 100% of the content on the site is crawlable by search engines. And the third, and equally important as the other two is to make the back end work the way the client needs it to work to manage 100% of their content and how it is organized on the site in an intuitive and easy to use way.
My goal in presenting this over the course of 6 blog entries was to hopefully enlighten others on how this can be accomplished without adding to the amount of work needing in achieving it.