Always wanted to do a recap from the perspective of how Wappler updates affect our dev shop (slashash.co) and the features we use. This is based on George’s year-in-review points.
Improved UI for server actions. The cleaner steps, with improved comments towards the end of the year, make our long and complex server actions a bit easier to work with.
Meta data and picker improvements. This has been building upon gradually over the years, and this year too there were improvements around how schema is saved and presented on both client and server side pickers. Made the UI more usable.
Project assets and extension update flow. This was sort of a surprise because I wasn’t sure how this would be implemented on Wappler’s end. But with a few iterations, it works quite well in current state. Only drawback is repeat update prompts due to linefeed mismatch in Windows.
Tagify. Only started using this in the past couple of months, but the UX has been good. There are few issues (probably haven’t reported), but a really good select2 alternate definitely and it is Wappler native.
Native windows and dialogs. This is something which did not make much of a difference in terms that the dialogs still don’t have full keyboard support and the UX is unusable when navigating using keyboard.
New Wappler brand identity. Even though the community feedback was a mixed-bag, have gotten used to the new design, colours and subtle animations. Overall, not bad.
Breaking changes. A slight change in the way steps are executed caused a huge rework of code on our end. And the latest one relating to DB time zone handling, which was thankfully well handled, had us worried. We don’t mind breaking changes, just a clear and timely communication around it should be implemented.
ENV support. This has been really great for overall project development. Our use cases for environment based project settings were easily handled with improved support. There are still UIs which are missing this, but hopefully they will be improved in future.
Stripe and others. We finally had a chance to integrate Wappler’s built-in Stripe component. Although it requires reading Stripe’s docs, it works quite well. Wappler’s doc can be improved, for eg: distinguish between using checkout form and Stripe checkout. We also used client side S3 upload, Tagify and Bootbox. We built more extensions and updated older ones too.
App Connect improvements. This was the biggest improvement for us. A couple of years ago, Patrick had improved app connect with huge visible improvements. And this year again, there was a good speed boost with the update.
Roadmap: Hadn’t posted my personal views on the roadmap since I could only relate to a few App Connect and Server Connect improvements that would be useful to us. Rest of it, not so much.
I rather prefer Jonas’s list to be the roadmap for 2023 (short term) which he shared after the release of version 5.
An alternate roadmap: Take the year off from new features, clean up old posts and bug reports in community, release only bug fixes. Change focus to build a new documentation system that can keep up with Wappler’s weekly releases. With that, also restart documentation from scratch. Archive all current content. There are numerous input fields and events and attributes and other things that are not explained. A document explicitly explaining every single input field and button with every possible variation^ should be built. This could also lead to cleanup of extra options. Not sure if this would work out financially for Wappler though.
A big thanks to all the community members and the Wappler team for helping us out over the year. Its the backbone of Wappler.
As of end of 2022, Wappler remains king of low-code tools offering great flexibility, power and time & cost saving. Thank you for all the improvements in 2022. Hope 2023 is just as stable and cool.
(^Variations within a component or when used with other components, not its real-life use cases)
No new features, only bug fixes. It would make everyone’s lives easier - including the Wappler team and ultimately make your whole team more productive.
In the short term, definitely… if that time is invested in doc building.
But in the long run, weekly release is Wappler’s USP and should not be stopped.
If they focus on bug fixing for the foreseeable future, create decent documentation (written by real users eating their own dog food) and deploy weekly, it’s going to be a game-changer.
True story: I actually planned to raise the same suggestion about “alternative roadmap” where the priority is bugfixes, stability, UI improvements, old feature requests, documentation, project examples etc.
And I think you spell it here perfectly. (not sure about archiving all current content though )
I mean, I like new improvements that Wapplers got in 2022 and I like the features that are already planned. But it all can wait.
I would be happy if the course and priorities will change.
For example, the last improvement for comments increased my comfort and productivity a lot.
But it only happened after I bumped a FR and mentioned that a year passed since I’ve created it.
And still this update feels a bit rushed, because there is room for quick and effective comments improvements and also we got new visual bugs now.
I think those little but useful things must be the priority, not peripheral.
That’s true.
And I think the thing we are talking about here is the exact way for Wappler to become more profitable.
Does absence of any of the features from Roadmap keep interested lowcoders/nocoders from starting to work in Wappler? No.
But I know for sure what’s stopping me from spreading the word about the Wappler amongst the nocode community. Lack of documentation, official guides (including about obvious things), professional videos and instructions, project examples. Many bugs, many “workarounds” in the actual working process. Lack of official full-time support.
Unfortunately, Wappler still has a high entry level, as it was one and half years ago when I started. But it is an absolutely solvable problem. But it seems like Wappler does not even try to be user friendly for ones who just started or just interested in it.
In my opinion, that’s what should be addressed if we are talking about profit.
I agree with this 100%. There are so many little bugs that we just learn to live with, that would be nice if those could get fixed. Another area that could be improved is the little help icons next to some of the choices. You could have more examples or a more detailed help description. Because when they say “low code” they don’t mean “zero code”.
But I do really agree that wappler is becoming very powerful.
Right, here’s an idea for everyone’s perusal regarding support documentation:
As a company, we’ve done our own support docs in-house before and realise what a ball ache it is to produce and maintain, as we have limited in-house resources to do this they were always sub-par - enough to provide basic use for our users but generally quite inadequate. I see this happening with a lot (not all!) of Wappler documentation, I also see this as a recurring theme reported by users in this forum.
So… why don’t Wappler team devs think about creating a simple template to allow selected volunteer forum users to write their own documentation on an individually assigned topic?
The templating would ensure a common standard was met regarding the look and feel of it. This topic would be the individuals’ responsibility to update and improve over time - as an incentive, a discount could be offered on their Wappler licence fee. This would ensure a constantly refreshed/updated support repository, with a high standard as it was written by someone who actually uses the feature they are responsible for and their discount provides a solid continuing incentive.
To me, this looks like a total win-win for everyone:
End users benefit from cutting edge, up to date help docs
Wappler dev team get to deploy their highly honed skills to developing rather than relatively mundane document creation
Wappler as a product becomes even more super efficient which will assist in onboarding and new sales
It’s a great idea on paper. But it’s extremely difficult to implement as a license discount based on voluntary labour is impossible to quantify and control.
There are other options that net on third party( content(documentation, tutorials, videos, blog posts, etc) like an affiliate program that are probably better suited.
I would consider starting my own language based community based on Wappler content if the UI was translatable and an affiliate program was in place.
Actually our whole docs is already as forum topics here Docs so any additions and edits there get deployed as docs. Many people already contribute there. Help docs TOC are managed by editing the about topic in the docs category.
Maybe we should make that more clear and organize it indeed by by assigning managers per docs category
I agree - well done example projects would really be a game changer for new users to Wappler.
Love this idea - I’m often confused by the current Docs setup and as a new user was often frustrated by not being able to find the information
When I have a question, it feels like I have to search and compare search results in the forum, the Docs link on wappler.io homepage, and Google search restricted to wappler.io just to figure out what help exists.
Centralized organization and de-duplication would be a huge blessing
)
