Dockable or "Break Away" panels

So, first of all, @George and his team has done an amazing job making the interface as simple and easy to use as possible, and it works great on single monitors. It works even if you have some widescreen monitors, like @psweb with his big 42" I believe. However, with multiple monitors I think there could be a little improvement. Most all web development programs allow you to move panels around so you can customize your workflow. Visual Studio, Visual Studio Code, Pinegrow, and yes, Dreamweaver.

I am lucky enough to have 3 2550x1440 monitors in my home office, and 3 2550x1600 monitors at work. Wappler really only works well with one monitor. I can “stretch” it to span two monitors, but then I have to play with where the split is. Here is a screen shot:

I have the split screen carefully put where my two monitors touch. But if you have to expand the Server connect panel or the App Connect panel, it gets off again.

Can we please have detachable, dockable, breakaway panels so that we can move these around where we want them? This would be my ideal layout:

Here you can see your file window, your server connect window, DOM tree, App Connect all without having to tab around. I think this is also going to be more important as you are adding new features, which are happening weekly. The routing feature coming up looks like it will take a whole tab to itself.

This feature request has been brought up before, but I thought I would do a little mock up to show what it would look like.

Thanks,
Chris

We have a lot of complicated action steps and it would really help A LOT if we could place the tools-windows on one screen and the design/code window into another.

1 Like

+1 on this
Spending too much time resizing and clicking buttons before getting to work…

Ideal scenario would be to enable undocking of the panels.
So that we can set positions and sizes for each.
And then quickly switch focus from one to another “alt + tab” style.

A “cloning” feature would be also really useful for code window so that we can edit code quickly without scrolling from one part of the code to another. :wink:

It would be great for multiple screen use to have both the Left (Server Action Side) and Right (App Structure side Panel’s be detachable

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 :slight_smile:
I just merged the topics, as they are the same.

Bummer :frowning_face:

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.

  1. Export table to excel, csv, pdf like datatables.js (AC Component)
  2. Infinite Scroll (loading data fom server connect) Similar to Lazy Load (AC Component)
  3. nodeJS Server (Server Model)
  4. A Snippets 'Library Chest' (UI)
  5. Client-side image resizing before upload - Megapixels (Mb) rather than Image Resolution (pixels) (AC Component)
  6. Allow custom Flow components (AC Component)
  7. Payment system integration, Stripe, PayPal (API template)
  8. Push Notifications (SC Component)
  9. Template Engine Support For Wappler (AC Component)
  10. PWA support (Framework)
  11. Draggable / Sortable Elements (AC Component)
  12. Editable Table/Grid (AC Component)
  13. Dockable or "Break Away" panels (UI)
  14. Webpack support (Framework)
  15. Upload Files to API via Server Connect (SC Improvement)
  16. Multi-Select Input Solution (AC Component)
  17. Bootstrap Classes Auto-Suggest (UI)
  18. Query builder feature request (UI)
  19. Make Custom Blocks (UI)
  20. 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 :slight_smile: . Specially in regards to the dockable and “break-away” panels.

  1. A Snippets 'Library Chest' (UI)
  2. Dockable or "Break Away" panels (UI)
  3. Bootstrap Classes Auto-Suggest (UI)
  4. Query builder feature request (UI)
  5. 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 :wink:

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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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.