Having spent the last ten days on Wappler and having spent lots of hours going through resources available, the key issue I am facing is simply how the IDE is organised and signposted. Confusing naming and signposting to say the least. Is there appetite for sorting out the nav/UI/UX issues? I know you are trying to build on Dreamweaver. We don’t have to. Think Different!
1 Like
Hi Ken,
Welcome to Wappler and it’s great community.
Getting started with Wappler might be a bit overstated first because of the many features and different frameworks that we have integrated.
Those are logically grouped in panels depending on their functionality.
So all page, front end related frameworks like App Connect are on the rights side while site global frameworks and functionality like back-end server connect, database manager and other site global functions are on the left.
Once you get it - it will make perfect sense.
It isn’t really a Dreamweaver organization but Wappler’s own logical organization.
To get started I would suggest to follow the great Getting started with Wappler course from Ken Truesdale:
1 Like
I think the “Think Different” part is exactly why it seems so confusing to start with.
Wappler is a very different solution to Dreamweaver, the only actual correlation between the 2 applications is that Wapplers’ functionality will get extended to their DMXZone product so they can make extensions for Dreamweaver to improve it, the rest of the application works pretty different to Dreamweaver.
I promise, once you get used to it though, it is a very smooth flow, and the split between server side vs client side is well represented.
There are quite a few docs now on usage as well as a number of video resources available, however for the most up to date and comprehensive, the link provided by George above will be the best solution.
If there is anything in particular confusing though, please feel free to ask and the community who will always try assist. Half of Wapplers strength is this community, honestly.
1 Like
Hi @George and @psweb, thank you for welcoming me to the community and for the comments. I hope you don’t take this as a criticism - it is meant to be constructive. Current iteration of Wappler still caters for developers, not so much for designer end of the spectrum. There are forum posts that highlight this. I didn’t post anything for many days whilst I tried to learn, just so I was not making a quick judgement.
I fully understand the point about integrating the different frameworks. I have gone through Truesdale and English resources - very useful - and I can see the UI has evolved over the last 2 years. Sever actions on the left makes sense to seasoned developers, but designers would expect pages on the left and linked frameworks and server related stuff as properties - say as tabs on the design panel. Similar to many of the design resources out there.
Thank you for integrating Docker and for the database manager - eases the pain significantly. I will keep trying 
1 Like
Well we are always open for new ideas and improvements!
So you can always post a feature request with good explanation about the case.
Hi George, thank you for listening.
Confusing terminology and signposts: for instance, I don’t know why we need “Globals”, when some of the other things not nested under this are also global things! Unless you are trying to adhere to some legacy terminologies that noobs like me don’t get.
A great IDE UI would be a marriage between Dropsource, Adalo, Xcode and Sketch.
1 Like
Hello,
You can check the docs explaining all of these things:
Thanks Teodor. This is not a post about ‘how to’. Of course I can find answers to all these from resources out there - I am not worried about that. I am just wondering if the UX using the IDE could be better. That’s all.
1 Like
Indeed there is a lot of legacy going on around. There is a learning curve for Wappler’s UI/UX but after some months you really don’t care anymore as you are just focused on producing code like a maniac
Wappler is a very small focused team and they don’t have the resources/budget to perform UX experiments. So they rely a lot on their experience and community feedback to tailor a tool for us. And that inevitably promotes legacy decisions.
That means that while the UI/UX might be difficult for beginners you can be certain that it will make sense after a few weeks/months. But only in our heads.
Also we don’t use the word noob here. We prefer the term pleb. There is also a learning curve for this community’s lore.
@Teodor should I open a FR so that the Wappler Pro License group is renamed to Wappler Pleb?
4 Likes
@JonL - I haven’t heard the term pleb for a very long time. Not since my UK days.
@kenlaji - the learning curve with Wappler is steep. I came over from another platform called Bubble, which, with the funding and team they have has a lower and shorter learning curve and quicker ‘time-to-first-value’ to get an app up and running quickly. But that’s about all that’s good about Bubble in my opinion - and you’ll quickly outgrow it. Once you get to grips with Wappler, the UX/UI is forgotten about and productivity ensues and you’ll never look back.
The community put up with (and likely still does) many questions from me as I struggled through that learning curve myself, but I whole heartedly say to you it’s worth it.
1 Like
Why not just suggest better names for them that make more sense for you?
As far as I’m concerned they are all named exactly what they are?
Hi Brad, thanks for dialling in. Point of the example screenshot above was to consider organising those items better, not renaming them differently. For instance, I would consider APIs are ‘global’ to the app. So keeping it separate from Globals is confusing. Ditto for schedules and webhooks.
The team building Wappler are doing a great job, and guys like you help the cause enormously. I am coming from a point of view of recognising there are different ways people learn and interact with what is on screen. What makes perfect sense to some may not for others.
2 Likes
Fellows and countrymen, Pleb it is from henceforth 
2 Likes
I get what you are saying, in essence everything is actually global as you can reuse the same server action in multiple pages, however the term global in this case is more like templates i suppose.
A few versions back you would have to set your database connection in every server action, and if you needed to add a mail step you would have to setup the mail server options in each action. They then came up with the globals area where you could store steps you were going to use over and over again within your server actions or your schedules or your webhooks.
I suppose think of them as quick access to steps you use over and over again, maybe there would be a better name for that other than globals, but it makes sense to us right away because we were all using the previous system before the Globals introduction. It could be confusing naming when coming in clean at this point.
Modern IDEs should abstract you from the platform details, allowing you to focus your time and energy on what makes your app unique.
Not entirely my words, but profoundly pertinent nevertheless…