Corteza and the documentation have come a long way since the early days but there are always things we could improve.
Use this topic to provide feedback, opinion, and suggestion for improvements regarding our documentation.
This is a free for all; anything from the structure to the contents; anything goes, just keep it constructive.
Thank you in advance for all of your valuable feedback!
The biggest thing for me is that there are useful functions in the app, but it should be reflected in the documentation right after being added in releases - there’s no point in adding functionality if even the more advanced users can’t use it because they don’t know about it. As an example, Corteza has been somewhat compatible with MSSQL and some other SQL engines for a while now, but there still is not any documentation on how to create config for these databases.
There are also a lot of “todos” in the documentation itself.
Thanks for the feedback.
If anything else pops up, do let us know 
I’m newer to programming full web applications. The thing that I am finding the most difficult to navigate is when to use which type of function and what each of them do. Also, workflows feel really convoluted. I would love a few demos that walk through different examples and talks about where each piece of data is coming from and how it’s moving through the workflow.
So you’d suggest improvements to the docs or workflows?
I suggest better documentation on using workflow low-code blocks (how to use each of the function types, how the data is connected (from modules to other modules or to internal fields) through each workflow step, and how to write effective references in building expressions.
I think the walkthroughs would be helpful to make it more beginner friendly.
Makes sense, thank you
From what I’ve seen on other platforms, I think the documentation needs:
Hi team,
Firstly, thank you to the Corteza team for all of your efforts. I’m so pleased that a truly unlimited (and frankly, quite polished) low-code platform exists, especially after trialling so many other open-source, self-hostable offerings with artificial limits. I’m looking forward to getting to know the Corteza ecosystem better.
As a new user, I’ve primarily been concerning myself with getting my new installation right. My biggest current gripe with the documentation is that the .env and docker-compose.yaml snippets are scattered across several pages, all quite different, some lacking seemingly essential things like setting up a persistent data volume for the server service.
I appreciate that the docs try to offer different solutions for different scenarios—offline vs. online, MySQL vs. PostgreSQL, etc. However, it seems that in all cases, the server’s /data directory should be persisted across teardowns—or I’m possibly wrong, in which case the docs don’t currently seem to make this obvious.
I don’t know what the best solution would be for this problem. Maybe one single mega .env file and one single mega docker-compose.yaml with ample comments indicating which sections to keep or remove depending on the situation, and then perhaps all other areas of the docs can link to that one location?
I would link some documentation pages in corteza itself. For example a little i that takes you to the documentation pages for more complex functions, like workflows.
Also simpler Workflow exampes would be nice. The documentation says, to look at the CRM examples, but for me it was a bit daunting because I didn’t have any experience with workflows before that.
How about adding a comment section to the documentation, so people can ask question and propose changes to the given documentation page?
I am brand new, and have not done anything other than spin up the local docker container and logged in. I am a full stack web developer.
Good documentation always assumes the reader knows nothing. If you provide code for a file, provide the full path to that file, and if the filename matters, say so.
Anytime you reference another component/module/named thing of the program/app, make it a link or reference (think tooltip) to what that thing is. Don’t expect the reader to know what the GRPD or VWB is.
Someone else also mentioned organizing documents from beginner to advanced. I 100% agree with this. A getting started that walks you through spinning up a local instance and as minimal as you can tutorial to “create something” that will introduce and name the basic functions of the program/app. The classic “hello world”.
(also, there may be 5 different ways to spin up a local copy of Corteza, for the “getting started” pick one. Have an “alternative bla bla bla” section or article to provide the other ways in a separate place, don’t confuse new users with unnecessary options. Once they are up and running, or have problems they will seek out the options)
The advanced section of the documentation can be as simple as full API documentation. Look at Stripe’s API docs as a good example 