After seven years working with WordPress, I have never seen a plugin like Multitool. That is exactly why I created it. I mean, if there is a little gap, even if niche or experimental, we need to try it right?!
I think we do, so I made a plugin that adds new items to the Tools menu (a menu that is underused in most of my own blogs) and the goal is to create the ultimate Swiss-Army-Plugin!
What makes Multitool a plugin “I have never seen” before (you’ve probably never seen one like it), is the multiple different views for different types of tools. There are three tool types and any new tool being added to the plugin must fit into one of the three views.
- Quick Tools View
- Configuration Tools View
- Advanced Tools View
Quick Tools are the most condensed of all the tools. They are presented in a table like the one posts are listed in. We can search tools and apply other filters. There isn’t much use in those features this early in development but when there are many tools you’ll understand my decisions to use tables.
Quick Tools require a single click to use. There aren’t any options for each tool. That does not mean the plugins main settings page won’t affect the behavior of some tools. It means there are no form fields to be seen in the Quick Tools view – keeping interaction to a minimum because that is the nature of a “Quick Tool”.
This is where my design decision starts to make sense. WordPress list tables are responsive, meaning they adapt to screen size or browser resize. The Quick Tool view becomes a very appealing service for running a WP site while on the go.
You have noticed the “Version” of tools being displayed. This is part of my intention to make it clear to users when tools change.
Configuration Tools View
Configuration Tools have some options alongside them. There is no limit to how many options a Configuration Tool can have. My design predicts a long list of options for any new tool I might add. Technically such tools could still be presented in a table, a little Ajax and an overlay to present a window of options. I wanted to use the WordPress options API though. I also want development of new tools to be very easy, so anyone can quickly add more tools to the plugin. That meant avoiding doing anything too fancy and sticking to a standard settings page approach. So that is what the Configuration Tools view is, a Settings page.
The trick to the Configuration Tools view is that each tool begins with a checkbox. The checkbox acts as a switch. A tool isn’t included in the plugins activities until we check the box. When checked, the tools options appear, without having to submit the form. All options are registered in WP using the options API. A single tab has a single form, so that is one click to activate multiple tools.
It’s very early days, but as you can see the view has the potential for multiple tabs should we need to spread them out a bit. I’m still confident that my approach will allow long lists of tools without causing too much confusion.
Advanced Tools View
Advanced Tools (not yet released in version 1.2.0) is the boldest part of the multiple tool types approach. It is the part that could unorthodox in the world of WordPress and here is why.
An advanced anything requires flexibility. I can’t constrain advanced tools to the other views and mess around with the users experience from tool to tool i.e. when we use the Quick Tools view we have to know that it will always be a very quick experience.
The approach I’m taking and offering developers for any tool that is considered advanced is a multiple step interface. A lot like a wizard, each step can be dynamically based on selections made in the previous step and so on. I feel this is unorthodox because it is essentially the idea of offering something that would normally be in a plugin of its own. How many of us have installed plugins that do very little i.e. add a single script line to the header of all pages so that a service like Google can confirm ownership of the domain?
I dare to say it and the thought actually excites me. The idea of assimilating plugins is not the reason for creating Multitool and it is not the reason for my design decisions. It was after I visioned three different tool types and made a final decision on the approach for advanced ones. Only then did the thought of assimilating a lot of small plugins come to mind and why not?!
I’m very keen on adopting abandoned plugins that are still used. I saw one of those not long ago and evidence suggested that it had hundreds of active users. Plenty of them were still requesting support and some were discussion the abandonment of the project.
I’m sure you now agree with me that “resistance is futile”, and if this all works out. I might actually provide the WordPress community with a very good service.