If you’ve been reading our blog for a while, you’ve probably seen some of our tutorials on developing plugins using different technologies like React and Vue. But when not writing examples for blog posts, we rarely if at all dive into creating a new plugin – there’s a lot more that goes into it before we write a single line of code.
In this week’s post, we’ll be taking a look at everything we do to create a new product or WordPress plugin. We don’t adhere strictly to any specific software development process, but the method we’re using currently seems to work well.
Research and Brainstorming
Obviously everything starts with an idea. Someone on the team (usually Brad) will come up with an idea for a new product and add it to our private Trello board. Sometimes this comes out of personal experience, sometimes out of things we hear from customers, or just a need we see in the market.
Once we have an idea we’ll all mull it over. Often we’ll do this at company retreats, as being able to brainstorm a new product in person can help a lot.
Once we’re fairly sure that this is something we want to do, we’ll do some research to determine if this is a product people will be willing to buy. We’ll create surveys, research any potential competitors, and try to gauge the overall interest of the plugin or product.
Next we move on to brainstorming potential features. This is perhaps the most important part of the process, as it’s at this point that we decide what features should be included and when, and the overall direction we’re going to take.
We’ll start by having a few meetings and collaborating on a document in Google Drive. This makes it easy for everyone to provide input and break the product out into phases.
In the case of our (now released) plugin, WP Offload SES, we decided everything that should be in the public 1.0 release, and any other features that we want to add down the line. This helped solidify what work needed to be done (and when) and avoid any potential scope creep.
Wireframes
After agreeing on the initial scope of the release, we then create wireframes using Balsamiq Cloud to help visualize the user interface. We’ve found that simple wireframes can be completed much faster, and we don’t need Brad to create high fidelity mockups in Photoshop as he has done in the past.
While creating the wireframes, we include everything from general layouts to functionality and even the specific copy that will be used. That way we don’t have to worry about being great copywriters or coming up with new solutions while developing the plugin.
Then, once the wireframes are a little more polished, we open them up for review. One thing we’ve noticed is that comments in Balsamiq can be a bit confusing, so we export the wireframes to Google Drive. Once on Google Drive, our entire team can go in and highlight specific parts of the mockups and comment on anything that is potentially confusing and needs to be changed.
After a few rounds of comments and updating the mockups based on any feedback, it’s finally time to start working on the actual plugin.
Developing the Plugin
Every plugin is slightly different, but there are a few things that we set up right off the bat for all of our plugins:
- Something to compile SASS to CSS and minify JS (like Grunt, Gulp or Webpack)
- Autoloaders
- Build scripts to compile the plugin for releases
Having these in place early helps keep everything organized later down the line. We also have a general style guide for all of our plugins which keeps UI elements consistent and eliminates the need to do any mockups aside from the initial wireframes.
When it comes to writing the plugin code, we work in teams of two. This method lets us write and review code quickly without the confusion and toe-stepping that comes with throwing a lot of developers on a single project.
We have a pretty standard GitHub workflow based on the Gitflow approach of branching – our master branch references the latest release, while we create feature branches off of develop to create new features or bug fixes. Once the feature or fix has been completed, we create a pull request which is automatically reviewed by Scrutinizer and our tests are run on Travis. Once the automated reviews and tests have been completed, the other developer on the team will manually review the code and test it out on a local install. Assuming all is well, the PR is merged into develop. Otherwise the reviewer assigns the PR back to the developer, and the developer makes any necessary adjustments.
Reviewing and Testing
After writing the core features it’s time for another round of reviews. We traditionally have created spreadsheets that cover every main feature of the product that look something like this:
However, this has been a time-consuming process, especially since three team members would run through the sheet on single site, multisite subdomain, and multisite subdirectory networks. We’ve started replacing these tests with automated acceptance tests, which is more time-consuming at first but pays off big time in the long run. Now our testing process is much faster and looks way cooler:
After all features have been completed and thoroughly tested, it’s finally time to release the plugin. Depending on the plugin, we might release it as a beta first, or we might release it straight into production. We write a blog post about the release, create a release branch in GitHub, and use the build-scripts mentioned earlier to release the plugin. If it’s a free plugin, we might even set up automatic deployments to WordPress.org using Travis. Time for a beer!
Conclusions
A lot of work goes into creating a new product, but I really like the process we have in place now. Sorting out the finer details during the brainstorming sessions and in the wireframes helps to eliminate the random questions and scope creep that usually comes up later down the road. Because of that, creating the product seems to go a lot faster and is less stressful.
Do you go through something similar when creating a new product, or do you think there’s something we could improve on? Let us know in the comments.
