Last week, we looked at why you might consider plugins. Now let’s look at why you might not.
This Sounds Awesome! Why isn’t Everything a Plugin?
Although plugins are powerful, can save you time, and can help in user adoption, they are not free of drawbacks that must be considered.
A quick list of potential pitfalls that you should consider when developing a plugin are:
- technical restrictions placed on plugins by the host application
- how to play nicely within a UI you don’t fully own
- licensing requirements that may be imposed on your plugin
- how hard will it be to find and install the plugin
- where does “help desk”-style support for your plugin end and for the host application begin
- Lashing yourself to a “narrow” platform
This is far from an exhaustive list, but covers most of the challenges I’ve encountered. Your circumstances likely will govern just how complete this list feels.
It’s tempting to believe that because plugins are typically written in “native” code that developing a plugin will provide the same degree of freedom that developing a stand-alone application does. More often than not, this isn’t the case. Even if the host application allows your plugin to execute in an effectively unrestricted manner, your ability to control and interact with the host application in a sanctioned way is still constrained by the host’s plugin API.
Even more importantly, just because you technically can do something, doesn’t mean that you should do it. Your plugin is a guest in someone else’s house, so it is typically a good idea to act on your best behavior. A healthy amount of respect for the plugin’s operating environment will go a long way toward preventing future maintenance and compatibility headaches as your plugin and the host application grow old together.
How to Play Nicely in a UI You Don’t Fully Own
Continuing with the notion of respect for the operating environment, more often than not, a plugin should visually and functionally fit within the host application. The visual appearance of menus, dialogs, buttons, etc… should all take their queues from the host application. The same thing applies to more functional notions such as the concepts of navigation and initiating actions. If the host application tends to use buttons to initiate an action, then the plugin most likely shouldn’t use text links as the primary mechanism for initiating actions.
Like most things of a design nature, this particular advice is a bit subjective. If you have a good thought on differentiation through the look and feel of the UI, have a thorough appreciation for how a drastically different appearance may be perceived by the end user, and you still feel strongly that you should implement a custom look for your plugin, then the last thing I want to do is advise you not to do so. Just go into such decisions with honest conviction. If you are on-the-fence or ambivalent at all about making that kind of design decision, you probably shouldn’t. If you’re confident you understand what you’re doing and that it’s the right thing to do, then with all sincerity, Godspeed.
A related aspect to general look and feel is that the UI shouldn’t strive to dominate the host application. In my experience, a Development team usually looks at this position as “not a big deal.” However, once you involve teams like Strategy and Marketing, their first impulse likely will be to make their product as apparent and prominent as possible.
It is a natural impulse and, realistically, the “right” position for those teams to take, but it’s also a move almost guaranteed to backfire if you are too aggressive about it while running within the context of another application. I assure you, that if a user installs your plugin and then sees it within the host application as a 600px wide sidebar that they cannot resize and are presented with a nagging dialog asking essentially “why no love?” when the user tries to close said sidebar, your user (also known as the customer) will hate you. They may leave that sidebar open forever. They may even use it’s unbelievably awesome feature from time to time. But she or he will always hate you. And they will never voluntarily do anything for you again.
The essence of this guideline is that by agreeing to be part of a larger application, you are implicitly seeding some degree of design control to the host application. If you think Outlook is a usability disaster and a primary element of the value proposition of your plugin is world-class user experience, then you may want to rethink whether an Outlook plugin is the right delivery channel for your application.
Licensing Requirements and Impositions
A review of source code licensing will likely take a big role in the later stages of your project. It will likely manifest as a big checklist from the legal department asking what open source projects have been used; for copies of every third-party header included in the project; for assurance that the proper license disclosure is in all source files, etc… The need to cross ‘t’s and dot ‘i’s regarding how source is licensed and used is a big concern of any company of reasonable size.
And if you’re delivering a plugin, the chances are really good that you’re going to have additional questions to answer than you would if you were delivering a stand-alone product. At a minimum, you should be familiar with any licensing requirements imposed by use of the host application’s plugin SDK and get sign off on its use from your company’s legal team and senior management before you start the project. I’m not a lawyer, so don’t treat this as legal advice because it’s not, nor does it intend or claim to be in any way. But you still should.
How Hard Will It Be to Find and Install the Plugin
This one usually isn’t a deal breaker for plugin projects and is generally a common concern for any software product, but people tend to overlook this regarding plugins until late in the development cycle for some reason. When designing the product, think through how a user will both find the plugin and how they will install it.
If the host application has a site or integrated install/update feature that the user can search to find the plugin, then that’s a good sign. Figure out what you need to do to be placed prominently in that ecosystem. If the user can install the plugin directly from the host application without requiring a restart of the application, regardless of where they get it, even better.
If the user has to go to your company’s website, download a TAR file, go to a different website to download WinRAR just to unpack the TAR, unpack it, run a command script with admin privileges, and then reboot the computer, all just to install your plugin, then you’ll likely face some adoption issues regardless of who your target user is.
What Does Support Mean for Your Plugin
Regardless of how clearly branded your plugin is and how distinct the host application makes plugin UI from the base UI, to an end user, your plugin is part of the host application and the end user typically has no notion of where the host application’s bits end and your plugin’s bits begin.
While this can be a goal to aspire to regarding the user experience, it can lead to headaches for your support organization. Your team will need to think through what is and isn’t a question that your support organization should field. Realistically, you should also prepare resources that can be referenced, even informally, so that Support can at least steer people in the proper direction if it’s appropriate to do so.
Additionally, your plugin becomes colored by the perceived stability of the host application. If the host application crashes all of the time, especially if your plugin looks like it’s doing something when the host does crash, your plugin becomes a candidate for blame whether it was actually at fault or not. There’s little you can do to categorically prevent this beyond ensuring high quality in your plugin and possible messaging on a social media channel. You’ll need a thick skin and fully invested management to weather a plugin quality critique whether or not your plugin is the root cause of the problem. I strongly encourage ensuring you have both before setting a plugin loose into the wild.
Lashing Yourself to a “Narrow” Platform
This particular constraint can be an interesting one and related push back is typically fueled by the background and general work outlook of the organization. Many developers loath the idea of building for a single platform. Most companies do as well, albeit often for different reasons.
While the vast majority of widely-used software has established some notion of multi-platform support, two of the most widely targeted plugin platforms, Internet Explorer and Outlook, historically have been decisively single-platform, and in IE’s case, still so in a largely concrete way.
You must make sure that you have a good answer to the question of multi-platform support. If the majority of your customers are on a single platform, then targeting the plugin for that platform while providing comparable functionality in a less-targeted manner for your secondary platforms will likely be not just regarded as a good solution, but a great one. But you need to think through how that will look early in design.
Next week, we’ll look at some special considerations regarding plugin development and formalize recommendations for when you should and shouldn’t use plugins.