Taking the Pulse of the Wappler Community

Coffee Lounge
1

I've been using Wappler for maybe 3 months now. I came to it with prior web development and DevOps experience the first half of my professional career. Most notably perhaps, is I spent the last 30 years working for software companies (various sales and global leadership roles, not engineering). As I now use Wappler to build my own MVP, I find it incredibly useful, but at times also incredibly frustrating. No software is perfect.

Now, reading more community posts lately to avoid hitting bugs myself, it feels as if there's a good amount of community frustration. This can happen in the lifecycle of a software product that has reached maturity on its core concepts, and is trying to expand into new areas, either to further build differentiation, or compete in new market segments.

Instead of a long post, I'm going to now just get to the point, a suggestion to the Wappler team: spend the time after summer holiday working on an overall quality update--no new features. Address the bugs, known by us, and known by you. Pushing the roadmap of new features a little further down the calendar is OK as your paying customers are mostly paying for efficiency gains in no/low code offerings.

Building a company where the success metric is about Lifetime Customer Value, is a much more rewarding outcome than trying to add new features because you are trying to fix a Customer Churn issue. Stability = LCV. Too many features too quickly = customer churn.

I do hope you all enjoy your summer holiday however and come back refreshed and ready to push forward!

7 Likes
2

Agreed. I can add a bunch to the list that I would like to see fixed!

2 Likes
3

Yes, please.

4

Totally agree! You couldn’t have said it better.

5

Actually we have being doing exactly this the last couple of months - fixing issues and making Wappler very stable.

Exactly with the same goal to deliver a very stable version before the summer break and be able to start with the new major beta after.

So the current Wappler version should be really stable already.

3 Likes
6

And yet users have been publicly, and privately telling you that it is not.

I sincerely wonder why we see this so differently? :person_shrugging:

As I've shared before, one possible reason for the discrepancy is the lack of a proper bug tracking tool. A forum category does not allow for triage, and formal tracking of prioritization and resolution. If we had that, we could better quantify the situation.

Perhaps also we are referencing different things, like the editor vs the frameworks. For me, while there may be a few outstanding bugs from the major overhaul to AC2 (thank you for that by the way), I do think IT is largely stable. Same for server connect. The editor however, which is the thing WE live in all day building real-world projects, has many issues that I now just manually code around each and every day. At this point, it has become second nature.

And of course there are the different groups of users that will for sure have differing opinions. New users, call for more docs and videos. Basic users wonder what all the fuss is about because Wappler is like Magic, and advanced users find the majority of the bugs, and know how to get around most of them--and then give detailed reports when they can't. The last group is the team, which at least publicly feels the product is "really stable" so moves to introducing new and valuable features.

This dialog has been going on for years, and it will continue until we (users and team) can agree on the current state. And because the team has made a business decision to rely heavily on we the users to find issues, I do think users are an important part of the conversation.

I personally have been at it for 5 years, I know where the skeletons live, and just work around them. I stay with Wappler because it is still MY best alternative, and because I have learned to accept the current state of affairs. It no longer frustrates me, as that was just getting in my way. So if nothing changes, it won't matter to me at all. But if it does change, I'm happy to be a part of the solution.

14 Likes
7

Great post. One bit is worth repeating as I think this is key to all this:

I'm assuming the team don't actually use Wappler for real-world projects. They just use the part they're currently working on and, once it's finished and working, they don't go back to it.

Making real projects using it would give a much better insight into some of the issues faced daily.

4 Likes
8

But isn't that impossible unless they added a professional services division? "Real projects" need a real client, or a real business with real demands pushing the boundaries.

So I actually don't want the team doing 50 hours of work in the Wappler editor each week like I do. That's what I mean by their decision, their choice, to rely upon users. I'm fine with that choice, and I am happy to participate in that dev process because I benefit greatly from the advancements that have been made over the years, and would not want to give any of that up, just so they can spend time in the editor. I see that as our job. The users that get angry and actually leave, are not comfortable with that fundamental choice of the business.

3 Likes
9

Yep, I'll go along with all of that.

One solution might be to employ someone to be part of the team but they are building a real-world project. Come up with hyperthetical briefs which target specific parts of Wappler so it can be put through its paces and feed to the team so issues can be addressed.

Mind you, as you say, that's kind of what we all do!

So maybe it is a good model after all.

11

I think we, as real world users, have been submitting the Editor bugs for some time, so there should already be enough reports on the issues. Many of them are just ignored. Most likely due to team size and not being able to focus enough time/resources on the different competing demands.

I feel the Wappler team does a good job trying to balance new features vs defect remediation, but it would be nice to have some of the older requests implemented (e.g. TinyMCE) and defects corrected, even if that meant paying more per month for the product. I'm not sure others are willing to pay more though.

2 Likes
12

Everybody is working hard!!!
Team and users...
As already Jon (@sitestreet) and Ken (@mebeingken) pointed out, team and users probably see it from a different perspective.

So, being new in this community, I would dare to say my poor opinion...
What I would have done, is to create a couple of full demo projects that combine a lot of complex functionality, the actions/elements/components etc, that seem to usually create a "buggy" situation.

This way, @George, @Teodor and @patrick would have the opportunity to test for a half an hour and then release a "from first hand heathy" version of this great product.
Then, this project(s) will be tested from each one of the users for further "crash test" (add extra features that do not exist etc)

What kind of demo project would be good and what its features could be?
I think team will be more accurate to find this out, but anybody could point out actions/elements/components that "hurt"

Just thinking outloud here... You can ignore my post if you tking that this is not possible

13

The bugs priority is determined mostly by the number of users experiencing the issue and also the the bumping.

So if you feel like a bug needs more attention just bump it to bring it more under the teams attention and also the users attention. The more users experience the issue the faster we will fix it.

It is indeed a fine line between bug fixing and new features that we try to balance well.

Each user also has a different perspective of “stability” depending on the issues encountered that others might never find.

More demos with Wappler will definitely help also new users to get to know Wappler much easier. So we will be working on those now as well.

Also now a full blown demo projects with ready to go databases are finally a possibility as we recently introduced the database templates. So we can finally deliver a demo project with database schema and demo data as well

1 Like
14

This approach, as stated previously, puts the onus on your customer base to find, report, and bump the bug posts. I've come across several bug posts in my search for help, some being 2+ years old, that have not been fixed. The file manager giving a file path error when trying to download files from a remote deployment for example. That bug was assigned to you according to the post.

My original post was a reflection of the community, and myself, feeling as if there are currently too many encounters with buggy features, and the resulting frustration it causes. It does seem that the community and the Wappler team have different opinions on the state of the software. No one is saying it's not usable, as many of us spend 8 hours a day using it. But we are saying there seems to be some well-known issues that don't get addressed and we're having to find workarounds, which doesn't make for a great user experience.

15

I think I have said this before after version 4/5 release - once the release is stable enough, just do bug fixes. Since then, there have been few releases in between focusing just on bug fixes, but maybe the frequency needs to be increased. No one would complain if there are no new features for the two/three/four months - at least I wont.

As Ken has pointed out, it does seem like Wappler and its users see things differently in terms of what is stable.

There are probably hundreds of open bug topics, some of which the team has never even addressed, some left after marking someone and some left open after few discussions.
Just addressing bugs of the latest version does not mean its a stable app, and there should be no need for begging or bumping to get things fixed.

6 Likes