A WordPress theme options panel should be something designed to help users to manage their sites. A common trend of these days, instead, wants these panels to be incredibly sophisticated and visually appealing, thus completely neglecting the usability issues that may arise from admin panels which are too complicated to be effectively used on a daily basis. Many theme selling sites (Theme Forest above all) insist on graphic quality and seem to overlook other topics related to theme development. In short: are we missing something?
Usability first
It's too easy to assume that our users will read our documentation and will also be able to use our option pages from the very first time. This is a wrong approach. For example, a user wants to set up his social network links but this action takes too long to be completed. Why?
Because you've forgot to create a section labeled as Social Networks and put the social network option under the General section. This is not so obvious as it could seem if you don't know what the word label means from an usability point of view.
So here's the first rule: use labels appropriately. To follow this rule you have to get rid of all the conventions followed passively by many themes: what does General really means in a WordPress site?
Second rule: users read the documentation only when they're in trouble. The sad truth about documentation is that users don't read it unless they have no other choice. For that reason you should not rely on documentation when creating and organizing your option pages.
Instead, insert contextual notes and explanations within your pages to make clear to the user what a particular option does and how a particular field should be filled (e.g. a link should always start with the http:// prefix and so on).
In that vein, I'd like to tell you what's happened to me when I had to set up the PayPal payment gateway in the Eshop plugin. I didn't know that a Business PayPal account was actually required to make Eshop work properly with PayPal so I kept getting incomplete PayPal landing pages until I found a small note on the plugin's Wiki about the necessity of having a Business account. Why this basic information is not present in the corresponding option page?
You're in the WordPress backend, not on a spaceship
For the sake of consistency, you should try to not turn an option panel into a spaceship control panel. WordPress has a very plain backend with no special effects or particular design features. It's a simple administration panel with simplicity in mind.
Users are accustomed to the WordPress default structure. Any attempt to change this structure with new layout settings is always risky. When users save an option in WordPress they expect to see a simple faded yellow box appearing after the page reloads. If you modify this default behavior, you can't be 100% sure that all users will understand it as you think they will.
Consistency is the key: don't try to force the WordPress backend to look or behave as you want. Try to make the WordPress backend work as users want instead.
Are you still procedural?
Functions are addictive. You create a function, you bind it to a WordPress hook and you keep doing the same thing over and over again. Then you create a new theme and try to make your functions work in the new design model. Unfortunately, this won't always work and you'll end up with having a gigantic and bloated code sooner or later.
OOP (Object Oriented Programming) helps you to keep your code tidy, tiny and organized. With OOP you can simply create an option class with properties and methods. Using visibility will also help you to keep your logic and behavior separated by defining public, protected and private properties and methods.
You can, in turn, separate your logic from your HTML markup by defining templates and modules that can be used by your main class. For example:
class Slider {
static $metaBox = '/templates/metabox.template.php';
public function __construct() {
add_action( 'add_meta_boxes', array( $this, 'addMetaBox' ) );
}
/**
* Adds the meta box container
*/
public function addMetaBox() {
add_meta_box(
'some_meta_box_name',
'Some Meta Box Headline',
array( $this, 'renderMetaBoxContent' ),
'post',
'advanced',
'high',
);
}
/**
* Render Meta Box content
*/
public function renderMetaBoxContent( $post ) {
$viewData = array(
'name' => get_post_meta( $post->ID, 'name' ),
'field' => static::$fieldName
);
$templatePath = dirname( __FILE__ ) . static::$metabox;
echo View::render( $templatePath, $viewData );
}
}
As you can see, we're using a separate PHP template whose variables will be set by our public method. By doing so, we keep our logic separated by our markup. This is one of the major advantages of using OOP.
