What can you include in your theme configuration options? You could go into an overkill mode and provide options for everything, starting from the background color to the spacing between the text and the border. This works well for people who are somewhat tech-savvy and can distinguish between a font size of 12px (pixels) and 12pt (points).
Then again, depending on the type of audience you are targeting, you might want to provide some “canned” options and then some configurations. This can reduce the load on your side, in the sense that you can do your basic theme layout and design, then isolate the customizations (like colors) separately. You also prevent your theme user from inadvertently breaking the layout. You might ask, “How can my user break the layout?” If your theme user had the ability to configure widths of different on-screen elements, at some point he (or she – I am not sexist; I just prefer a convenient shorthand notation) might end up with the total width of the posts and the sidebar exceed the overall content’s width.
And finally, you could decide to provide a set of canned options (like color schemes) and simply let the user pick one and not customize anything else. Eventually what you provide is dependent on two things – your skill and the time you are willing to devote.
This being said, the following is a list of options you can consider providing:
- More color – Let’s face it. Everybody likes a different set of colors. While picking a WordPress theme I have found myself being dissatisfied with the available colors so often that I ended up writing themes myself. So when you are creating a theme, provide options for colors wherever possible. It also helps if you provide some predefined options – one for a light-colored theme and another for a dark-colored theme. The following are potential areas you could look into:
- Body background – An ability to specify a background image is going to be a bonus, for sure!
- Header – This is a hot favorite amongst theme developers and users. In particular if you are targeting small businesses, chances are they will want their company’s logo in the header, so your theme is better off supporting a custom header image
- Fonts and links – Apart from a general preference of colors here, the theme users may also be required to tweak a color based on the background selected. And some people prefer their hyperlinks show up in a color different from the rest of the text, while others prefer the same color.
Coding Complexity: Medium if you are providing a color picker etc. Easy if you are relying on the user’s knowledge of RGB colors.
Testing Complexity: Easy.
Bang for the Buck: Very high.
- Layout: Widths, Heights, Spacing and Floats – Your theme could be fixed-width or fluid. In other words, the widths you give to individual elements like posts, sidebars etc. could be predetermined in terms of pixels (fixed-width), or they could have a percentage of the total window width (fluid). What you provide is really a function of your tastes and both designs have their pros and cons. In either case:
- Provide options to control overall width.
- Provide options to control width of individual elements.
- Allow custom spacing between elements.
- Allow the option to float / align text and content either to the left or to the right. This is useful for themes that go from the right to the left (RTL) as opposed to the left to right (LTR)
Coding Complexity: Medium. The coding itself is easy, but you have a lot of elements to think about.
Testing Complexity: Complex to test, because older versions of IE really play havoc.
Bang for the Buck: Medium. A lot of people don’t fiddle with the widths of a theme, so you might not extract much mileage from this. However, your theme users may cater specifically to people with high-end machines, so they might want to capitalize on the high-res monitors and make the themes wider, or they might want to cater to all audiences and make themes that fit on a 1024×768 monitor.
- Navigation Menu Configuration – It helps to have a pretty navigation menu at the top of your blog. Beware, though, that such a menu needs to be debugged on older versions of Internet Explorer for compatibility. In addition, the following considerations are needed while building out your options:
- When you have created such a menu, you have to realize that not everybody is going to want to have every page displayed in the navigation menu. This is particularly the case when you have a lot of pages in your blog. In such a case it helps to have a selection list of pages to pick from.
- Also, there are some folks who prefer having pages listed in a widget by the side. For such cases it is a good idea to provide the option to completely hide the navigation bar.
Coding Complexity: Complex for setting up the drop-down menu. Medium for listing pages to include / exclude, easy if you are telling the user to manually enter page ids.
Testing Complexity: Complex to test, because older versions of IE really play havoc with floating menus.
Bang for the Buck: High. Apart from a drop-down menu adding a “cool” factor to your menu, the ability to exclude / include pages by choice really takes things up a notch.
- Excerpts vs Full Contents – Some people are in the habit of submitting long posts. If all contents of recent posts show up on the landing page of your blog, things might go ugly. Some other folks like showing the complete text of posts on the front page, but only showing excerpts on the Category or Archive or Search Result views. For such cases it might help if you provide an option to setup “excerpt” views on certain views.
Coding Complexity: Easy. WordPress provides the APIs to display excerpts and full contents, so you only need to apply the right conditions.
Testing Complexity: Easy. You only have to look at different views (Categories, Archives, Tags etc) to check if your setting is working. This is a browser-safe feature, since it is handled entirely in the back-end.
Bang for the Buck: Medium. This kind of a feature is useful if the blog is a “news” blog with frequent updates, where summary views are presented on the front page and the full stories are on individual pages.
- Widgets, Dynamic Sidebars and Sidebar Setup – I like having one sidebar. But there are people who like having two of them. Then there are people who like 3 sidebars or 4. And some others prefer having no sidebar, but they like the contents to be displayed in the footer of the page. As you can see, there are a host of choices you can offer here:
- A configurable number of sidebars
- Ability to define sidebars on the right or left side of the page (or at the bottom). This will allow your users to either put the sidebars together or to have them laid out on either side of your content.
A word to the wise here – by default when you define a sidebar in WordPress, you put its contents in the
sidebar.phpfile. Without special attention though you end up making your sidebar static. Users typically love adding widgets to the sidebar and so a static sidebar might become terribly restrictive. For this purpose it is advisable to make your sidebar dynamic. This is usually managed using a very simple piece of code.
Coding Complexity: Easy. This is a fairly easy option to code, with simple APIs.
Testing Complexity: Medium. Again, a fair amount of testing is required across browsers, to ensure that the different layout options render as expected.
Bang for the Buck: Very High. Your theme’s reach grows rapidly when you allow configurable sidebars.
- Internationalization and Localization: Translation-Ready themes – Most themes are developed for English users. However many users have their blogs in non-English languages. It is for these users that you need to provide translation hooks. This is much easier than it sounds:
- If you have a dynamic sidebar, in most cases you will be able to specify the title of the sidebar in your “Widgets” page. So translation hooks are not needed for any standard widget.
- Drop-down menus for pages, category names etc. don’t need any hooks either, since these are defined by the blog owner and get dynamically pulled
- What you will need hooks for are static pieces of information that you put on your posts, like “Categories: …”, or “Tags: …” or “Edit” or “Add Comment” or “Comments” or “Posted By …”. That’s about it.
- In addition, for the “fallback” mode of dynamic sidebars (i.e. when the dynamic sidebar functionality is not available in a particular version of WordPress) you might have static widgets defined. These static widgets will require translation.
Coding Complexity: Easy. WordPress provides APIs to make fields translation-ready.
Testing Complexity: Medium. To call your theme translation-ready you need to ensure that all elements that can be translated indeed have translation hooks.
Bang for the Buck: High. This feature is a great “nice-to-have” and it surely gains you fans!
- SEO, Advertising, Analytics, Additional RSS Feeds etc – This where you start entering overkill territory. Or maybe not. There are a lot of plugins out there, which do a pretty good job of Search Engine Optimization, hooking up Google AdSense and bundling Analytics into your blog. You could provide a lot of these as features for your theme, but IMHO it takes some focus away. To cite some instances:
- If you are bundling Google Analytics into your blog, you cannot include the Analytics script in your theme and dynamically populate the web-property id. The theme submission gets rejected by WordPress. Plugins don’t typically suffer from such limitations.
- If you do decide to provide such features, which are not purely functions of a theme, be sure to provide “opt-outs”, so that people using plugins can stay with those.
Coding Complexity: Medium. The coding aspect of this is simple, but the concepts and features need thought.
Testing Complexity: Medium.
Bang for the Buck: High. Particularly for users not using any specific plugins, having these features bundled with your theme is a good incentive.