Plugin architecture is undervalued for building great UI/UX products at least for IT-sector
Tanshihelair
Do you have an X in your product? Could you add Y to your product? If you had Z in your product we could buy thousands and thousands of seats… and we know that no one would use it, but we would use it!
Everyone knows such kind of customers requests! This is because customers want everything under the sun!
Even my 75-years old professor from military university in Russia told that even military want “tanshihelair”: which means tank, ship, helicopter and airplane — all in one.
And this “tanshihelair” concept is well explained with the picture below:
— where adding more and more features leads to a feature creep and products become incapable do their job well anymore.
You don’t want to build such crappy products. From the best intentions you try to please everyone. But you end up pleasing no one. And this is true. But not a complete true.
Customers who code
I’d wanted to point us to a special category of customers: to Software Development specialists of any kind and Software Development companies in general. They are customers who code. And it changes everything!
If you write software for IT-guys, then you can use their ability to write code to solve their own problems. How? With plugin architecture!
Build software that supports UI/UX plugins. Build software that allows writing and running plugins instantly: nothing to install, just start writing your own plugin in the system!
How this approach appeared?
I develop SQA Mate test cases management tool. And I do my best to keep it simple and clear. But as any product, SQA Mate is expected to have more features and functions as it grows.
This expectation comes from different types of customers who have different types of tasks. And they want to hire SQA Mate to help them with that tasks. But “it would be nice if SQA Mate had …” So, you know: this is a sound of “Tanshihelair” that appeared on a horizon and is running to you.
It would be nice if we had export to XML. It would be nice if we had export to JSON. It would be nice if we had export to MS Word…
Instead of making export menu with 10 types of export, why don’t implement plugins for export? Plugin for export to XML, plugin for export to JSON… And disable them by default. Customers will enable plugins that they want. Customers will disable plugins they never use. Customers will buy plugins from Marketplace. Customers will write their own plugins and publish them on Marketplace. They will — because they are IT-guys!
Benefits
The best benefit from giving plugin architecture to end-users who are IT-guys — is that they (some of them actually, the geeks) will write solutions for their problems. And their problems — for the most cases — are presentation problems, are view problems. Data is presented not the way it is needed. Not the color is needed. Etc. I.e. data is fine. We have UI/UX problem in most cases. And plugins can solve the problem here.
It’s like a Linux in early days: don’t have a driver for CD-ROM? — code it!
You can change UI completely for the customers who want it. And leave UI/UX the same for the customers who want it. They don’t want your new emoji — they don’t enable plugin. Easy!
Another benefit — is that you keep software clean and simple all way long, but provide scalpel-shaped plugins for solving problems.
Disadvantages
You have to deal with potential conflicts of different sets of plugins. But this — is a real engineering task for you as a software developer. Provide solution for this problem, make running and stopping plugins safe and easy.
Plugin architecture in SQA Mate
A year ago I implemented inside SQA Mate this simple plugin window where you could write any JavaScript code and it has been executed on every page refresh:
I used it to write different things: from dark theme skin to export test cases in different formats.
And I liked it! This feature made this software incredibly flexible — because now I could write code that is executed just for me, to experiment and do not affect anyone. If my experiments succeeded I could share that plugin with others in my account! It was a really cool insight for me! That’s why I decided to rework SQA Mate UI and build it with natural support of plugins. I wanted the whole UI of SQA Mate started to be a set of plugins:
Now I continue writing plugins for a new UI of SQA Mate. I address any issues that appear, solve problems, think on documentation for plugins and API.
And I really think that plugin architecture is undervalued for building great UI/UX products at least for IT-sector.
