An open letter to plugin developers: more flexible plugins needed

Need help Plugins
1

This is not meant as a complaint or critique, but as a general observation and hopefully a constructive dialogue on how we can make the Bubble plugin ecosystem better for end-users, and more profitable for developers.

I’m working on a major project now, which has been nearly a year in development and has a huge range of different challenges, many of which were solved with plugins.

So what’s the problem?
The challenge is, I can’t tell you how many times I’ve had to ditch a perfectly good plugin, simply because it lacked the flexibility to solve my specific problem. The plugin is awesome at doing exactly what the plugin author intended, but a mere step in another direction stops me from using it.

The website I’m building is for a highly brand-conscious client, and I’ve had to ditch a lot of paid plugins simply because they wouldn’t let me assign the correct font or change a color. I’ve struggled immensely with using any of the many different date/time pickers, because none of them support dynamic time zones. I’ve tested four or five different rich text editors, having to give up one after the other for lack of flexibility in customizing which buttons to show in the toolbar, how the border should look, it doesn’t support Auto Binding, etc.

A current example
I’m currently in a discussion with Zeroqode about their Flat Tags plugin. I suggested a change in the plugin that would allow me to use it for a particular case, and the response was basically that this is not how the plugin is supposed to work. My intention is not to criticize Zeroqode - the discussion is not finished, they haven’t had the time to respond yet, and they have no obligation to listen to my suggestions. The quality of the plugin in general is top notch, and maybe my suggestion really is not ad addition that makes sense. But I wanted to include it as an example of what I find to be a bit backwards thinking: that the customer should adapt to the features of the plugin, rather than the other way around. I think a change in thinking here would benefit both the customer and the developer.
EDIT: I’ve come to think that this was a bad example, as in this case I requested a very specific change that may not have been in the public interest, and so it makes my point confusing. See my post further down for details on this. The example below is still relevant.

And a counter-example
@keith’s CalendarGrid Pro is an example of the opposite. The plugin is so stuffed with ways to customize the calendar, output its data in different formats, make date and timezone related calculations, etc that it alone has solved a variety of different challenges far away from what was looking for when I first installed the plugin. It’s not great because of one specific feature, but because the immense investment Keith has made into flexible settings. It’a bit more work setting it up than the other datepickers in the store, but I use it because I can make it look and work exactly like I want it to.

What should change?
The point I’m trying to get across, is that a truly flexible plugin should include settings that go far beyond the specific use case you intended. Open up for total flexibility on:

  • Looks (colors, fonts, borders, padding, line spacing, letter spacing, word, spacing, etc)
  • Data handling (saving data, auto-binding, data format to save in)
  • Actions (input is focused, something is clicked, etc)
  • Customization (how the plugin behaves, hiding/showing elements such as buttons, etc)
  • Conditions

I’m not only creating this topic because I have a selfish need for more flexible plugins, but that there are at least ten plugin developers losing money right now on a plugin that I ended up not using just for a slight customization setting that wasn’t there.

One final point
As a plugin developer, it’s understandably easy to think “Our users will tell us what they need, and if it makes sense, we’ll add it.” I can only speak for myself here, but in most cases, I simply don’t… I’m usually in a rush to get things working, and if a plugin doesn’t offer what I need out of the box, I usually uninstall and move on. I rarely discuss it with the developer, so I think there’s a risk that a lot of them are simply not used.

Do people agree with my observations? Disagree? What things am I not seeing from the developers perspective? Open for all viewpoints and an open discussion here.

(sorry for the negative mention @levon and the rest of the team, but as a developer of countless plugins, you’ll naturally end up as a center of attention when discussing this topic :slight_smile: I hope you’ll see it as a constructive dialogue, not criticism.)

14 Likes
2

It’s an interesting discussion. I think there are a few different variables at play:

  • The Plugin Developer skills
  • The library being used to build the plugin
  • The Bubble Plugin Editor
  • The audience
  • The intended use case
  • The ROI of development

I can imagine how any of these variables can impact the end result of an implemented plugin. Having not built one myself, I can only speculate. I wonder how these are weighted in the minds of a solid plugin dev?

7 Likes
3

Good discussion. To contextualize my point of view, I’m an independent plugin developer. What I found out is that users want flexibility but they also want something that just works first, then later maybe if they need they can uncover a set of options or more advanced features. Usually people don’t want to set a lot of options to get something to work, and that goes for any kind of digital product.

Also, there’s the thing, when I’m at the trench, concentrated and building stuff, a question that comes is “how much is enough?”. There’s a time when building public facing products that we simply have to put the keyboard down, ship the software and then see what happens, gather feedback and plan future development if and when it’s worthy (read: profitable somehow) to further develop the product. If we remain polishing it forever under a rock… well, not-good things happens.

In your case, asking for private development may be a good thing. Most of my plugin work is private, for specific apps or for a specific group of apps. And that allows me to build stuff that fits much better into a problem/challenge/situation/context than one of my general products.

So, if that really frustrates you and you have some cash in hand, consider hiring a dedicated private plugin developer, someone who knows Bubble very well to leverage Bubble’s powerful facilities and also knows Javascript, jQuery and Node will probably be who helps you the most.

That person will be able to fork (clone) existing public plugins and adjust them to you if that’s the better approach but probably that person will be creating new stuff just for you. This approach may help you.

In short, about public-facing plugins, there must be always a balance between costs and profits… for a good reason. No one wants to go broke and lie in the sidewalk :laughing:

Happy Bubbling!

8 Likes
4

Stating the obvious but if you want that level of flexibility and customisation why not simply opt for a custom plug-in… That’s what I’ve done in the past

1 Like
5

I would have a tendency to believe that together we are stronger. When you need an addition to a plugin, creating a ‘post’ and asking others to participate financially would be a nice alternative.

6 Likes
6

@JohnMark I can’t join you this time. Because when it comes to localization, people are usually alone.

7

Thanks for the input guys!

I don’t have a problem seeing the perspective of the Dev’s here, especially when it comes to the ROI on development hours. My theory is that a highly flexible plugin allows for more user cases, leading to more paying customers. I admit that I don’t know if this actually translates in real life though, it would be interesting to see number on this, if any can be produced. Perhaps one of the bigger devs like Zeroqode can chip in some thoughts and statistically valid numbers on the current value of adding extra development hours to a plugin. Maybe Bubble can provide some numbers on how many plugins are installed, and then uninstalled shortly after.

I think the tricky part of discussing plugins is the fact that a lot of requests (this one included) is honestly meant as a step towards the “common good” of the Bubble universe, while the plugin devs understandably act according to their own interests (ROI, time spent, etc). That’s not to say I blame the devs, but rather that I question whether the right incentives are in place for a developer to prioritize the extra effort that goes into building a flexible and customizable plugin with a big range of use cases. I’m aware, sitting comfortably on the sideline, that I’m asking for something for free on behalf of the community, that you really have no reason to give me unless it makes monetary sense.

So, definitely not saying I have the answers here, but merely pointing out that I still end up not using most plugins that I test, often for frustratingly trivial reasons.

How would incentives need to change for a developer to rationally spend that extra time? Some ideas:

  • Better reviews give higher commission
  • Number of installations increases commissions
  • Customer Lifetime Value (basically, does a plugin stay installed?) increases commission
  • Bubble rewards plugins for specific qualities, such as customization, design, etc. through commission, awards/recognition, etc

I can only represent “my” side as a non-plugin developer, but I’m completely understanding of the fact that we’ll need this to make sense and bring value to the devs too.

As for private development, that’s what I’ve done in some cases, or found other ways around it. The website is near completion, so it’s not that I need specific plugins to change now. But the way I see it, going private and customizing a plugin to solve a problem that other’s too might have, is not a great way to build a sustainable eco system. I have an approach to Bubble that whatever’s good for the community as whole, is good for me. I think many share this sentiment, and we can see the evidence in how much time people are spending helping each other out in this forum for example, and the many plugins given away for free. I really do think that Bubble’s growth depends on a healthy plugin ecosystem, but I’m not sure the current way it’s structured stimulates that.

4 Likes
8

Yeah, seems like almost all of us see this the same way.

We could definitely get improvements both at the plugin editor and at the plugin marketplace and these alone would greatly increase value given to devs and therefore we’d do better by default.

There are countless threads about these suggesting improvements to Bubble team and also they’ve got loads of suggestions by email too.

However, something that also would be interesting is having more sponsors or bounties on the free open source plugins, there are enough interested devs to fill in this demand and Bubble team has already said that they are willing to provide us with features to better conduct open source collaborative work on free plugins. I just don’t see much demand from the users to conduct things like that.

3 Likes
9

As a plugin developer who has created several plugins with over 50,000 installs, the above list by @andrewgassen is the answer to your question.

Just to elaborate on some of the points.

The library being used to build the plugin
Not sure if you’re aware but almost all the plugins (about 95%) including the ones built by bubble are based of existing javascript library. This means if some feature isn’t available in the library it’s likely going to be hard and a lot work to implement it in the plugin.

The Bubble Plugin Editor
There are some limitations in the bubble editor that makes it hard or impossible to implement some features or keep adding to a feature. For example there is no way of showing/hiding some property based on another property. This means that if you don’t take time and keep adding features that override other ones you will have to create some extensive documentation to explain it or else people are going to struggle to understand how to use it and this will have its own issues.
You specifically mentioned colours, borders, etc. Sometimes you can add some of these styles but as you may be aware you can never exhaust all the styles. This can be problematic for power users who may want to add their own custom css to style things. They may have to resort to overriding your styles and this sometimes lead to some issues.

The ROI of development
This is something that i feel a lot of people don’t focus on enough when talking about plugins. Whether one is creating a free or paid plugin, you want to have features that many people want.
So here is the thing. Often there are several must-have features that people want that you haven’t even had time to implement to think about the nice-to-have features that are not deal breakers.
Even if i’ve finished implementing all the must-have features, there is the question of which one gives me the best ROI : adding some nice-to-have features or creating another new plugin.
If I create a plugin A with say 8 must-have features. And I know I can add some additional 2 nice-to-have features that 2 people want that will take me say 5hrs to do.
But realized that 10 people want a plugin B that I know will take me 10hrs to do. Which one do you think gives me the best ROI and I should invest my time in?

You also mentioned that when you need some feature and it’s not available you don’t request it and just move on. How are the developers supposed to know that people actually want this feature so they should invest time into it. You don’t create things for creating sake or because you “think” someone will use it. You create something because you “know” someone will use it.
Personally all the plugins I’ve created have been in response to complains and issues i read in the forum.

10 Likes
10

Thanks for the perspective @seanhoots

It’s interesting to hear your description of the Bubble plugin editor limitations, which are shrouded in mystery to me. On the libraries, I was aware that a lot of them were made that way, but not that it was as high as your estimation. I realize this puts a lot of limitations on what the plugin author can do.

Most of your points on ROI are pretty much in line with what I would expect, and confirming that adding the nice-to-have features doesn’t necessarily make sense financially, which will of course remain the main driver behind the development of most plugins.

It seems to me that a majority of the points we are discussing are in the end up to Bubble’s strategy on the plugin store and editor:

  • Are they interested and willing to incentivize plugin developers to move the ecosystem in a certain direction, for example by rewarding specific plugin qualities?
  • What are the limitations of the current editor, and will they change it?

Yes, and this is one of the reasons I wanted to bring this discussion up: I’m not saying it’s good thing that I don’t request features or report bugs (it’s obviously not), but I wanted to point out that this is the reality of my everyday work so that we can discuss things like they really are, not what they should be (i.e. I should report every bug I find, but in reality, I rarely do). If this pattern of behavior is just me, I should look at my own attitude, obviously, but in my experience, the behavioral patterns of one often represent the pattern of many. And if that’s true, what can we do about it?

For me, it’s also related to the fact that as a plugin buyer, you simply don’t know much about the company or person you’re buying the plugin from. Do they reply to feature requests, and how fast? Did they make the plugin for their own use, and simply released it as an act of kindness or an extra revenue source, but the don’t take feature requests? If I post a request on the forum and stop looking for alternative solutions while I wait for the reply, I might miss a deadline. I’m not gonna risk that, so I drop the plugin and look elsewhere for a solution. Again, I’m not blaming the devs, just trying to share my perspective as a potential customer.

A more transparent plugin store might help with a lot of things. Details on a plugin page saying things like “This seller usually responds within 48 hours” or “This seller takes feature requests” may bring a lot more confidence into the buying process, and hell, Bubble could even monetize the feature request transaction and incentivize the buyer to agree to letting the author share the new feature publicly by lowering the price. Just thinking out loud at this point.

Lastly though, what I was hoping to focus on in this thread was not specifically needed features that users ask for, but how the plugin ecosystem can be pushed in a direction where a basic set of settings for a plugins are always in place (by incentivizing or rewarding those that do). Does that make sense? For example: should input field plugins always have the auto-bind feature? Should time/date fields always support multiple time zones? Not by forcing the devs, but by making such qualities increase the ROI of the development.

I don’t think it’s realistic or right that plugin devs should be responsible for making community-friendly contributions out of the kindness of their hearts, but it just seems to me that the whole Bubble ecosystem would benefit from plugin developers being rewarded for creating plugins that adhere to some core guidelines, such as the auto-binding rule, and that user feedback can be systematized in a way that makes it easier for developers to receive feedback on their plugins, and for customers to confidently invest in a plugin and trust that the developer sticks around on a rainy day.

2 Likes
11

This is all great but it will still boil down to limitations in the library. If the library that the plugin is based on doesn’t support say timezone no amount of incentive will make the developer add it.

One thing you should note is that in most cases if a library has a feature it’s likely the plugin developer will include it, even if not in the first release a subsequent one if users ask for it.

4 Likes
12

One thing that I think is lacking in the current plugin marketplace, and something that could help developers get better feedback, is helpful reviews. I use reviews all the time when purchasing things on Amazon, etc. but the Bubble plugins don’t have hardly any reviews. I think this is part due to Bubble not focusing on reviews enough in the way the plugin store is designed (I know they have the ability, but it’s just not very useful in it’s current form), and the other part is Bubblers not leaving reviews or star ratings on plugins.

3 Likes
13

Yeah, I realize the libraries tie the hands of the developers, but to me his strengthens the point that creating high-quality Bubble-exclusive plugins that don’t rely on third-party libraries should be in Bubble’s interest to encourage. It may be true that a plugin developer will never add timezones to a plugin who’s library don’t support it, but a mature marketplace should be able to sort that out with the right regulations and incentives. If Bubble rewards date-type plugin developers that support multiple timezones with increased exposure and/or commission, then developers will rush to include that, which benefits the community as a whole. (keep in mind the timezone thing is just an example).

Basically all marketplaces like Apple’s App Store and the Play Store have become successful because they kept the needs of the end-user in focus, and set up regulations, guidelines and incentives to make sure all uploaded apps upheld a certain standard of quality.

The discussions in this thread are broad, and cover a lot of “should have beens” for Bubble, plugin devs and plugin users. I still think the core points remain:

  • I think the plugin ecosystem needs a set of “minimum requirements” or at least best practices that Bubble encourages developers to implement. I’ve personally wasted huge amounts of time testing different plugins, oftentimes paying for it while testing, only to find that it lacks basic features that I’ve come to expect from Bubble. Styles, and all inputs having auto-binding are examples of this. The plugin developers will usually not hear of my frustration as the nature of my business forces me to just move on
  • I think plugin developers have something to gain from thinking about how they can ensure broad flexibility in their existing plugins; if Bubble grows as much as we all want it to, becoming the “go-to plugin” in a given category can become very valuable over time, and I think there’s a black hole of lost revenue of potential customers who try a plugin once, only to move on because some trivial setting was missing
  • There’s a desperate need in my opinion for a lot of structural changes to the plugin store: how trustworthy is a developer? Does he accept feature requests? How long does it take for him to respond? Does this plugin rely on a third-party library? If so, who made that?

I’ve worked on more than one project that handles several million dollars of revenue per month. A faulty plugin can translate directly into a substantial loss. I do my due diligence manually, but in the end, the amount of trust placed in the hands of a sometimes unknown plugin developer is frankly a bit insane for projects on the scale that Bubble encourages us to build. There’s a very limited amount of peer review, not much transparency on library dependencies (unless the developer chooses to reveal it in the description), and you simply have to trust that the developer will stay true to his word and be there when you need him. I know these points have been discussed numerous times, but that doesn’t make them less valid.

3 Likes
14

@petter
Hey Petter
thanks for bringing this topic up. We are a long time offline friends and I know you as a very pragmatic and fair man, so I don’t mind the post at all :slight_smile: - on the contrary I see a lot of value in it.
Having published more than 221 plugins (almost 30% of all Bubble plugins) we do receive a high number of requests from our users who’d like to see some additional features in the plugin or existing features to be enhanced/modified. If we satisfied all those requests we wouldn’t be able to invest any time in building new plugins or seriously improve some of the most popular ones.
Thus, unfortunately at some point we had to decided to be super picky in regards to which requests we would take into work and which not.
You are totally right of course when saying that the more flexible plugins are the higher a chances that the plugin will be used by someone else. But we always look at things like how important the requested feature might be for others. How popular the plugin already is? For example the “flat tags” plugin that you mentioned has been used 15 times within almost a year since it was published. And I’m actually not sure if it includes those who subscribed and then unsubscribed from it or only active ones.
And the kind of change you requested is something that is not very likely to be needed by anyone else. Even there is one more person who will need it within the next year, that would mean only additional $15 of income for us. Now adding that feature will take time from the developer, then the support team member has to test it and inform you, then in case it’s for some reason not exactly how you expected it we’d need to do another round etc. You see the point?
Now having said that, we’ll take another look at flat tags and see if it’s super easy we might end up doing it for you :slight_smile:
At the same time, you brought up a very good idea about the General Guidelines or Requirements for the plugins:

I mean this:

I’ll discuss this with the team, and i guess we could add something like that to our existing guidelines.
Overall, we got more experienced in building plugins, and if at first we tried to build the full UI with functitonality, now we build the plugin so that users can build the UI in Bubble and then use plugin actions for the functionality.
For example insttead of building an audio player with fixed number of design skins, we have not built an audio player which is completely composed of plugin actions and the user can make their own design with standard Bubble elements.
of course some plugins are just that - fancy design or fancy visual effects etc. then it’s different.
But again, thanks for making that checklist. I’ll discuss it with the team.
Peace!
:pray:

8 Likes
15

As a no code user all the plugins are giving more life to the story. Thanks to all the plugin creator and thinks to keep some are free to save the world :slight_smile: cheers for everyone who plan to make new ones.

4 Likes
16

Hi @levon

Thanks for the great reply and insight. About the tags plugin, it actually may have been a mistake on my part to bring that up in this discussion, because, as you say, the feature I requested wasn’t really a “standard” one, it was a very specific one that I happened to need. I thought the dialogue would add some background to the discussion, but it may have had the opposite effect and made my point confusing. To be fair, any change you’d decide to do from my request would be more than I should be able to expect, and changes like that would be completely fair to expect payment for.

The last part of your reply hits exactly what I was thinking though:

Overall, we got more experienced in building plugins, and if at first we tried to build the full UI with functitonality, now we build the plugin so that users can build the UI in Bubble and then use plugin actions for the functionality.
For example insttead of building an audio player with fixed number of design skins, we have not built an audio player which is completely composed of plugin actions and the user can make their own design with standard Bubble elements.

What you said here summed up my thoughts better than I was able to. Plugins that allow you to design your own solutions on top of a set of features are infinitely more flexible than a fixed number of skins (no matter how awesome they look), and after all, you can still set up templates for download/purchase in addition to the plugin, for those who want a completely designed product. The separation of features and themes are a very interesting idea.

About doing the checklist and finding a set of best practices, would you be willing to make that a public discussion? I think a common set of best practices that all plugin developers can use as guidelines would really benefit Bubble as a whole. I’d be happy to contribute what I can from a buyer’s perspective.

Perhaps @eve or someone else from the Bubble team have an interest in following this too, and maybe we can end up with something that becomes part of the plugin development documentation.

Lastly, as @melon said, and I have stated in other threads, my point is not to chime a red alert on the state of the plugin store. On the contrary, I think it has developed in a great direction and several plugins and developers have been indispensable in my daily work. But a good thing can always be made even better :slight_smile:

3 Likes
17

Hey @petter,

Our team is certainly keeping an eye on this thread! :slight_smile:

5 Likes
18

Thanks a lot, Peter, I think this is a very helpful thread!

yes, absolutely! Would you help to set that up?

By the way:

we’ve just launched the version 2.0 of our RTE plugin, which we have rewritten from ground up. Perhaps you’d be interested to give it a try :slight_smile: 📝 ZQ Rich Text Editor 2.0 - New Plugin From Zeroqode

Thanks!

Please support us with a retweet

Levon Terteryan

Founder @ Zeroqode

zeroqode-for-web-160x120

Bubble Templates

Zeroqode Blocks

Bubble Plugins

Bubble Courses

Convert Web to iOS & Android

No-code Development Services

19

Absolutely, I’ll do what I can! Let’s keep this dialogue going.

Cool, I’ll check that out!

Great, glad to hear it Eve! :slight_smile: will keep this thread updated.

21

Very glad you’ve focused on improving that editor, though I’ve received similar responses about the lack of customization that have been in this thread. For instance, I was told the new ZQ RTE editor wouldn’t allow the user to turn off certain formatting features (even though 1.0 supported it).

As always, thanks for the continued plugin development.