I started my journey of portal development tools specifically with Bubble.
And it’s true. The documentation is sensational. It allows you to move forward quickly, even if you are just starting out with the tool.
Bubble lost out due to vendor-lock, outdated UI, poor versatility, and lack of easy cost estimation.
These are elements that Wappler solves really well. And that’s why I ultimately (after playing with Bubble, Noodl, Plasmatic, Bildr, Weweb) chose Wappler.
This is a helpful thread but certainly not something that has been raised many times over the years.
To give a very quick example (off the top of my head)…
Data Validation in Server Connect. This is a great feature and one I use a lot. But I keep having to go back to a previous use of it to remind myself exactly how it should be set up.
We just get this box:
It would make life soooooo much easier if there was just a hint icon which opened a tooltip giving a couple of examples, much like the tooltip for the date formatter where we’re given all the options for days, months, etc.
There are fields which require the input but it’s not clear whether it should be the id or the name so you end up using trial and error. Just saying ‘id’ or ‘name’ would help a lot.
I strongly wonder why, with Response (Server Actions), there are no predefined response types 
Why similarly with the _SERVER parameter.
Little things like that get the job done. And they are in the wappler at almost every step 
See
See
I think, Ben, this illustrates my point.
Many features/components are standard Web or bootstrap components which are already well documented but some seem to want these documented again in docs.
See this
I’m not sure why you guys are being so dismissive of other’s suggestions. The goal of low-code/no-code is to make development easier. All of Bootstrap is well documented yet Wappler makes it easy for you to create a Bootstrap table or add other Bootstrap elements. Similarly, Wappler could create a modal that allows a user to select (with a description) each of the server and response types.
Keith, I am not dismissive of other’s suggestions, I am very respectful of those suggestions. I think that the problem stems from the different types of users that Wappler attracts.
In my case, I created my own flat file-based database back in the late '70s, using Benton Harbour Basic on an 8-bit HealthKit H8, with 4kB of RAM
After a subsequent Zenith H89 machine (which I still possess), I delved into 16-bit computers and went all the way through the different Intel processors until now, a machine that is a fraction of the size of my original H8, an Intel 12th gen 64-bit NUC.
What I am trying to say is, that my view of Wappler differs vastly from those that were not even born when I started computer programming. I view Wappler as a tool that does most of the coding for me, thus reducing development time. I hardly ever visit the Wappler documentation, only when it is Wappler specific. As such, I have found the documentation more than sufficient.
I am sure that the coding knowledge base of the Wappler Team surpasses mine. I am also sure that the Team is blinded by this knowledge base when they create the documentation. That is why I have suggested input from Wappler users to suggest specifics when they see where the documentation fails. I think that this would be a win-win for all concerned.
@kfawcett’s suggestion allowing a user to select an HTTP response, should really be posted in Feature Request. I’ll be the first to back this.
Oh, I wish it was that prose, but it isn’t.
Of course, I can on the server-side insert any response code in the Response’s object. But the front end only respects a few predefined ones. I have no idea if ERROR is 500 or the whole 5xx group.
As a result, we have an inconsistency in approach.
Yes, I know where to find information on $_SERVER attributes, I was creating a sizable project many, many years ago in PHP (the worst time of my life).
However, typing them in manually, without the option to select from a list (preferably with a description), results in:
Such examples can be multiplied.
For me, the need for ‘hints’ is paramount. The hints could be a short description of what’s expected and, even better, one or two examples. This will further speed up dev time considerably. All the time saved can easily be lost due to having to spend time using trial and error.
You can inspect the status returned from any server action by checking the status returned.
I.e. serverconnect1.status == 500
I guess the 1000 dollar question is "how much extra would people be prepared to pay annually to have this level if docs?
Hmm, I’m not sure that’s the question at all. That level of information should be a given with professional development software so I would expect it to be there already.
Yes but how often do we hear…
I have come from Bubble, it has amazing docs but is just way to expensive.
So I came over to wappler as it appears better but the docs suck. Why can’t wappler have the same quality of docs?
Wappler is basically a three man team, if people want better docs then does development stop or do they hire in more staff and put the prices up?
In an ideal world we all want everything but that’s a difficult call.
I got excited when they added two people to the team (Remi and someone else whose name I can’t recall) and their remit was the documentation. But I believe they’re no longer part of the team so it’s back to the three core people.
There must be enough in the bank to employ just one more person to specifically look at the documentation. And if all the posts about this are true, the number of additional paying users will more than cover that cost anyway.
I’m not asking for lengthy and thorough documentation on absolutely everything (although that would be a dream), I’m just looking for tooltips on every field so it’s really clear what is expected to be put in there.
They took on extra staff members to cope with this type of demand for more comprehensive docs.
I’m with @sitestreet on this one, even having ‘hints’ in the UI would be a massive help. For an example, the FormatDate formatter has one which I use all the time, I’m constantly forgetting which formatting to use in a few of my date fields. Just being able to hover over it to find an aide-memoire is a big boost - adding this to all components of the UI would be a huge time saver.
This could be a good compromise for the team, providing a very useful productivity boost whilst also negating the need for uber-comprehensive documentation.
Yes, I did some work with romy, dre67 never seemed to get involved.
Romy was a good designer but not at all technical and for me, she was not really a good fit for the team. Not sure why she left.
Romy, yes, that was her name. I was close!
I believe the software already has the facility in place for tooltips as they appear in lots of places. It just needs a bit of time spent adding them to the rest of the places. I know it will involve time to do it but it will be massively worth it. If it was just addressed bit by bit each week - maybe one of the team spends an hour a week adding some tips - then it will soon plug all the gaps and make it sooooo much better for us users.
Or add a mechanism for Ambassadors to add help texts?
Yep, I’d be happy to fill in some gaps and I’m sure others would be, too.
