Previously, we looked at why a client-side plugin architecture might be a good idea and why it might not be.  Now, let’s formalize our recommendations.

Some Final Thoughts on When You Should and Shouldn’t

Now that we’ve discussed some of the benefits and pitfalls of taking on plugin development, hopefully you have a better feel for when leveraging a plugin is appropriate for your project. However, there is an additional aspect that I factor into my evaluation:

• perceived appropriateness for the platform

Basically, this factor is meant to gauge both how frustrated your users will find the idea of a plugin and how friendly the general developer community is to the idea of plugins for the platform category to which your host application is perceived to belong.

This is how I break down platform categories as they apply to this particular question:

• desktop software built on the idea of plugins
• desktop software that has a plugin API, but isn’t plugin-oriented at it’s core
• web browsers

Desktop and Based on Plugin as the Core

Software of this variety tends to be complicated, valuable, and used for sophisticated work. The most well known examples are Adobe Creative Suite and Eclipse. Less prominent members of this class are smaller, albeit popular, applications such as Emacs and command shells on various platforms. The products are built in such a way that core product development is often done as plugins. In these ecosystems, plugins are not just encouraged, they are expected.

For disciplines such as media design and software programming, these nuanced products tend to have highly technical users asking for a solution to very specific problems. In environments such as this, plugins tend to flourish. If this is where you’re project is targeting, you should have few concerns about the appropriateness of using a plugin as the delivery channel.

Desktop with an API but without Primary Orientation

This is, more often than not, the Microsoft Office case. While there are other products that fit this category, Office is the prominent player. Typically, there is a very polished extension API and even a large and committed community around extending the products. But unlike the more technically-oriented applications mentioned above, the technical fluency of this class of software’s users can vary widely.

Plugins can be successful and popular here. The appeal of having software do new and cool things is a universal draw. You don’t have to be a geek to love a new feature.

However, because the broader audience tends to be less tech-savvy, UI, delivery, and support decisions typically need to be more conservative. In general, you want to make sure your design and marketing message are closely aligned with the attitudes of the people likely to install the plugin.

Because the user of these applications tends to be less technically-oriented, the place of plugins in the ecosystem tends to take more of a secondary role. Your plugin would need to become phenomenally popular to give it comparable clout with the internal Strategy and Architecture teams at the host application. On these platforms, you must be prepared, and frankly expect, to rewrite the plugin often and abruptly in these ecosystems.

Web Browsers

Early in my career, I tended to think of web browsers in the same class as the “Desktop with an API but Nothing More” camp. The browser was an extremely widely-used desktop application with a good extension API. However, over the course of time, I’ve significantly revised that assessment. Browsers are in a class of their own.

Because browsers tend to lag only operating systems in terms of usage, browser plugins come up very often on product roadmap wish lists. However, the size of the audience is almost always more of a curse than a blessing.

One of the most resonant messages uttered by advocates of the “pure web” movement has been that things on the web should be free and that they should be universally available. I have been shocked often at how articulately non-technical users can attack any bit of software that doesn’t fit the free and universally available model of the pure-browser-delivered web. Even if your plugin is free, it will run afoul of the “universally available” purists if it doesn’t seamlessly run on every platform without any user interation.  Just ask Adobe.

Personally, I think this frustration often boils down to the fact that most people don’t care about technology, only the things technology can do for them. So any point of view that affirms those two notions is innately appealing.

Because of that, most of that uber huge audience of browser users tends to be:

• annoyed that they should have to install anything for any !@@#-ing reason
• skeptical that anything they are asked to download and install is actually free or safe

Installing software can be a pain, especially on a system like Windows that often insists the user close an application or reboot the machine to complete an install. Users expect access to a site’s information or functionality to be available as soon as the page loads.  Anything that gets in the way of that is an annoyance, plugins especially.

In general, I’ve found web browsers are an unforgiving platform for plugin development. Expectations for cross-browser support and the ability to override or circumvent security mechanisms tend to run pretty high. Because the zero-friction, potentially cross-platform delivery channel of HTML is available literally right in the same application, the question of ‘why aren’t we doing this as a web application?” essentially never goes away with web browser plugins. Because of this, in my opinion, browser plugins should be avoided.

Conclusion

That’s my take on plugin development.  Hopefully the information will help you in determining whether a plugin is the right choice for a software project.  Like I said above, this series is based on my experiences in building plugins and not intended as gospel truth.  Like all things in software, your mileage may vary.