I think this is the same as this request.
I merged the two topics, as they are the same requests.
So does this mean we may see this feature in Wappler soon???
1 Like
No 
I just merged the topics, as they are the same.
I personally think this request(Dockable and “break away” panels) should start getting some priority.
If you check the feature request category ordered by votes we have the top 20 not implement, and not duplicated requests. I’ve also added a note about what type of requests they are to the best of my knowledge.
- Export table to excel, csv, pdf like datatables.js (AC Component)
- Infinite Scroll (loading data fom server connect) Similar to Lazy Load (AC Component)
- nodeJS Server (Server Model)
- A Snippets 'Library Chest' (UI)
- Client-side image resizing before upload - Megapixels (Mb) rather than Image Resolution (pixels) (AC Component)
- Allow custom Flow components (AC Component)
- Payment system integration, Stripe, PayPal (API template)
- Push Notifications (SC Component)
- Template Engine Support For Wappler (AC Component)
- PWA support (Framework)
- Draggable / Sortable Elements (AC Component)
- Editable Table/Grid (AC Component)
- Dockable or "Break Away" panels (UI)
- Webpack support (Framework)
- Upload Files to API via Server Connect (SC Improvement)
- Multi-Select Input Solution (AC Component)
- Bootstrap Classes Auto-Suggest (UI)
- Query builder feature request (UI)
- Make Custom Blocks (UI)
- App connect component to access Server Sessions (AC improvement)
Except for UI features the rest of the requests can be worked around with more or less effort. The calendar was one of the most voted requests until just recently but you could actually implement it without the UI. It was just a matter of effort and time.
But again UI features are completely out of our reach due to the very nature of the product.
So maybe we could have some UI love for the next months . Specially in regards to the dockable and “break-away” panels.
- A Snippets 'Library Chest' (UI)
- Dockable or "Break Away" panels (UI)
- Bootstrap Classes Auto-Suggest (UI)
- Query builder feature request (UI)
- Make Custom Blocks (UI)
Edited to make it clearer that I was referring specially to this topic.
4 Likes
I totally agree, but personally would prefer it to come just after 2 important non UI additions:
- Amazon S3
- Google Authentication
1 Like
Important for you 
I couldn’t care less about them. But not because they are important for you, but because I can implement them if needed. I don’t need Wappler to do that for me. Although of course it’s nice that Wappler can ease the work.
But I can’t implement “break away” panels, docking and moving to a new window. It’s pretty much impossible for me technically, but most important on licensing terms.
But the ones you said. They can be built by yourself. They are just APIs. So important for your project of course. Important for Wappler to integrate…depends, but not urgent.
Improving UI is actually core to the success of the product. Because…it’s pretty much the product
1 Like
Indeed, as I wrote!
The Query Builder feature request (abilty to copy queries) was partly implemented a while ago, using the Debug option, in the Query Properties panel. However a better option, if available, is to use the query log. This is great for debugging and lets you copy the actual queries generated. This is probably an option if you’re developing locally. You can view the log in a text editor, or within Wappler using the terminal (I gave an example a while ago).
Regarding the feature requests lists, it would be useful to have more information from the Wappler team - eg the current status of requests. In many cases, I imagine we have little idea whether a feature would be easy to implement or very difficult, or might have side-effects or implications the requesters wouldn’t be aware of. The number of votes isn’t necessarily indicative of the likelihood of a request being implemented. Some requests have been implemented before there was time for many people to vote (even on the same day in at least one case).
The Feature Request list is very unwieldy. There are 533 requests at the moment. I don’t think it’s possible to search by status, although ‘implemented’ appears next to some. Some requests are made implicitly within other posts. It could be a lot more useful.
3 Likes
Glad to see there is some demand growing for this feature! Thanks guys! We all have feature requests that are important to us, but this is a major one for me and I think will be beneficial to a lot of users.
1 Like
Agreed…and same for bug reports. Even a quick triage – Not a bug, Confirmed, Need an example, Won’t fix, etc.
As a reporter of bugs, I don’t want to pester the team, but also need to know if I should be architecting around the problem.
6 Likes
So I’ve been digging and playing Sherlock a bit and now I understand the complexity and the amount of work that needs to be invested by the team to give us this.
We all know(or should know or know now) that Wappler UI is built with nwjs which ships with Chromium to provide a graphical interface. So basically Wappler UI is a very complex website that can call node.js modules to extend its functionality and it’s all wrapped inside a desktop browser(chromium). That’s why we can run it in all major OS and they don’t have to worry(too much) about what OS we are running.
That was a great design decision.
Now what I didn’t know(but now I do) is what library they were using to create the layout. Also a good solution but constrained by the single window implementation they have done. I was going to propose to have a functionality to move tab content to a window and viceversa. They would still be enclosed in the single window but it would allow further flexibility.
After checking the docs of the library being used I can see that it can’t be done out-of-the-box so they would actually have to fork the library(if not done already) and implement it themselves. And maybe the core functionality of the library wouldn’t allow it.
So moving back to the dockable panels and moving windows around. It can be done from a technical pov but it’s hell of a lot of work because the windows you see inside Wappler are actually popups constrained by the same window that constrains your websites.
Imagine a modal in your website. You already know it’s not going to move from the tab your are in. You can’t move a modal from your website to your second screen without detaching the whole tab.
That tab is Wappler right now. To be able to do what we want they would have to move from a single window implementation to a multiple window implementation(the multiple instances we talked about in another topic) and change Wappler’s whole UI architecture.
Anyway, trying to shed some light on this topic from an independent position. Wappler team, feel free to chip in and correct me if I’m wrong.
Actually it is not a technical limitation that hold us on - we use indeed NWjs so you can have as many popups as you want but we just don’t want
We feel that Wappler should behave as a single app and not be breaked up by thousands of popups and floating panels. This is just a very bad UX.
With the years of experience that we have on similar UI’s in Dreamweaver, we learned that it is not a good idea to give to users too much freedom in completely reposition and redesign their workspace. When they do so - panels get lots or are found in places no body is expecting.
So the support guys were 90% of the time occupied with questions like where can I find this and that panel - of it is hidden, of sorry I placed it somewhere else…
So we simplified things in Wappler for the greater good. Now we can say - look at the left side or right side and we now what is there
4 Likes
Coming back to the topic of improving usability of the UI. Now that we know it’s a design decision and one I truly understand and won’t even challenge.
The recurrent theme I see is that users want a way to access quickly a component without losing focus on the actual work. One example would be flows, database data editor(already opened a FR), etc
Given that you have the option to decide if the content is going to be rendered in a pop up or a tab why not offer both options? Via contextual menu and key combination(i.e. cmd+click)
I know currently you only use tabs to render file contents. But how cool would it be to be able to render in tabs flows, database data editors and other components where it makes sense.
It would give us an option to have certain components at just one click distance and allow us to tab quickly between them. It would improve productivity and learning Wappler.
It wouldn’t compromise the integral layout and your ability to provide instructions. The dom panel would still be a tab of the right sidebar. And we get improved usability.
1 Like
I think I asked about the option to reorganise panels and the UI layout generally, long ago - perhaps when Wappler was in beta. You explained then that you were against this approach - and I think you were right.
However, there are cases where the ability to resize popups would make the relevant features much more useable. The flow window is an obvious example. It’s been made slightly wider, which helps a little, but it would be very awkward to use for a flow with many steps. There is the option to use full screen - but this is also very awkward to use. If the window/popup could be made resizeable, it would be perfect. I’ve wondered if there is a technical reason why this can’t be implemented. I can’t see that it would have any disadvantages. The same applies to query builder for example.
George, I respectfully disagree with you. I don’t think it is bad UX to have multiple windows. There are different ways to achieve this from a UI standpoint and can be done correctly ( just look at Visual Studio where you have panels that can only go in certain places). Visual Studio is probably the defacto standard for IDEs. You want to say that is bad UI/UX? Yes, Dreamweaver could get ugly but you know what I could put my ftp window and DMX extensions on one monitor and have my code/design window all on another monitor and I could make my workflow the way I wanted. It’s great to have multiple monitors and I could not work if I just had a 13" laptop screen. Yes, you can go overboard with too many windows but you can also limit efficiency by not having the ability to see all your content.
In earlier versions of Wappler I understand why you would want one application window, keeping everything contained and like you said, not have to go looking for everything. Wappler was presented as a simple to use application. It still is and you and your team have done an awesome job; it’s a game changer. However, you can’t just keep adding new features and keep that same mindset. I mean come on, you have windows now that when popup they cover other content, you can’t expand them to see all your content or move them around, and you have horizontal scrollbars sometimes and other times you have to cursor over through your text to see your overflow. That is good UX?? If I could simply expand that window, I could see all of my content without having to find it or scroll. For us that have multiple windows, we can arrange things where we want them so that we can customize our workflow.
Sometimes I don’t get it. You have an awesome community here and the Wappler team is great with helping us and you are open to suggestions. But for a lot of us to request something that we feel would make us work more efficiently and then you tell us You just don’t want to?
I have a company that develops warehouse management software. As an owner and project manager/developer, my role is to envision the software and develop it with my team. Our customers use our software everyday as their job. We don’t. When they suggest something, we listen and most of the time implement it because like I said, they use the software everyday and we don’t. They are the ones paying for it and I try to give them what they want and keep them happy because my livelihood depends on it. Yes, I sometimes say "no, that is a bad idea because… " and list out the reason. They depend on us to be the expert but when it is something that will increase their productivity and make our product better, then we try to give it to them. I hope you can understand our point of view. There are some very talented developers here and understand good/bad UI, but when a lot of us are suggesting a better UI, maybe we are on to something…
Wappler is awesome, and the team is awesome and keep up the awesome work that you guys do. Thursdays are the highlight of my week.
What about Google Authentication is not working, mine works ok.
Please correct me if I’m wrong but that only applies to the editor. Not to the rest of the layout, right?
I’m pretty sure it’s the entire application. You can do it to any window with a header. You click on it and pull it away, then you can move it close to another window and it gives you the choice to pin it to the right, left, above or below the window you are close to, or you can move it away and it will become it’s own floating window that other windows can then be attached to. I like the fact that you can dock them only in certain places so it keeps the UI clean. Of course you can still go crazy if you want to but you can also keep it clean. Here is something I copied from the online help:
Arrange and dock windows
A document window or tool window can be docked , so that it has a position and size within the IDE window frame, or floating as a separate window independent of the IDE. Tool windows can be docked anywhere inside the IDE frame; some tool windows can be docked as tabbed windows in the editor frame. Document windows can be docked within the editor frame, and they can be pinned to their current position in the tab order. You can dock multiple windows to float together in a raft over or outside of the IDE. Tool windows can also be hidden or minimized.
You can arrange windows in the following ways:
- Pin document windows to the left of the tab well.
- Tab-dock windows to the editing frame.
- Dock tool windows to the edge of a frame in the IDE.
- Float document or tool windows over or outside the IDE.
- Hide tool windows along the edge of the IDE.
- Display windows on different monitors.
- Reset window placement to the default layout or to a saved custom layout.
Arrange tool and document windows by dragging, using commands on the Window menu, or by right-clicking the title bar of the window to be arranged.
The following illustration shows the guide diamond for document windows, which can only be docked within the editing frame:
Tool windows can be fastened to one side of a frame in the IDE or within the editing frame. A guide diamond appears when you drag a tool window to another location to help you to easily redock the window.
The following illustration shows Solution Explorer being docked in a new location that’s demarcated by the blue shaded area:
Specifying a second monitor
If you have a second monitor and your operating system supports it, you can choose which monitor displays a window. You can even group multiple windows together in rafts on other monitors.