Help Shape the Future of Drag-and-Drop UI Design in .NET

[MikeCodesDotNET]

We’ve heard from many of you, on Reddit, GitHub, Discord, and elsewhere, that drag-and-drop UI design in the .NET ecosystem leaves a lot to be desired. Whether it’s tools that feel half-finished, or workflows that slow you down rather than speed you up, there’s a clear sense that this space needs attention.

As part of Accelerate, we’re building a new design experience, named Reframe. Our goal is to create something that feels powerful yet intuitive, especially for developers building complex apps.

But we don’t want to make assumptions. We want to understand the real-world problems you’re facing, what you’ve tried, what’s worked (or hasn’t), and what your ideal tool would look like.

👉 Take the survey

Your feedback will help shape priorities, features, and the philosophy behind what we’re building.

[CastleSoft]

How about Rider support and the Visual Studio Extension?

[thevortexcloud]

I personally never saw the advantage of a drag and drop designer for a mark up language. Almost every single one I have used has been terrible (I am also including HTML designers in this). They produce incorrect results, overly complicated code, weird code that would never be written by hand (EG hardcoded margins everywhere like the WPF designer) and feels slower in most cases (fiddling with trying to drop an element into the exact right place is very painful compared to just cutting and pasting it). In a lot of cases it also teaches people bad practices: Either because because they assume the designer is doing things properly (instead it's generally doing what is easiest for the designer to do) or because the designer showed them an option that technically solved their problem, even if it was not the best option they could have done.

In the context of XAML though a designer is a weirder thing to do, since all the controls are lookless. Meaning what might work look fine for the designer in one theme wont work at all in another.

There are a number of changes that could be done to mitigate some of that, but it would likely require changes to the core of Avalonia. EG #16962 would help a lot with people accidentally hardcoding fixed widths/heights on everything (which I am guessing the designer will accidentally encourage in one way or another).

My experience is also most people who want a designer are coming from platforms where a designer is normal (such as winforms) and just don't want to learn how to do things differently.

So my ideal tool would:

1. Not get in my way, and actually make me more productive
2. Actually write code the way I want it written
3. Let people write better apps without them having to memorise everything about Avalonia
4. Have useful, rebindable keyboard shortcuts
5. Would actively discourage people from doing bad things (such as using margins/fixed sizes), and then explain why they should not do it
6. Not do weird things like magically add a bunch of code seemingly from nowhere (a lot of HTML designers did this by adding CSS that I did not explicitly specify)
7. Allow everything to be done in ~2-3 clicks or less. Anything more than that will likely be slower than typing.
8. Give useful information when it crashes (the Win Forms designer for example is basically impossible to debug if it properly crashes)
9. Not hide the code it generates
10. Be supported on Linux

That said there could also be some useful things it could do as well, such as automatically generating control resources/styles.

[robloo]

I think Microsoft made a fundamental error with the WPF designer. They made it work for people coming from WinForms.

That means their goal was to drag and drop and upon drop the control would stay the same size and position-- just like WinForms. That's why you get really, really bad Margins and things littered in the XAML.

XAML is NOT meant for absolute positioning UI's, it's meant for relative positioning.

What does this mean in practice? When I drop a Border on a Window basically the ONLY thing the drag and drop system does is determine the parent you are dropping into. So the Border would immediately expand to the full window and be its child. Then if you drop a Grid in the Border it will expand. If you drop buttons on that Grid within the Border within the Window the buttons will all just be top/left aligned. You will need to go to the property editor to first add Grid columns and then set rows/columns for your already added buttons. (Or drag and drop them to the new rows and columns at that point).

The true power in the designer comes from immediate visual feedback, snapping, guidelines (especially with Grids), control highlighting (like DevTools so you can see the parent you drop into) etc.

Edit: Context menus and overlay controls directly on the design surface to add things like Grid columns or adjust font properties would also be useful. Think of something like Inkscape where you can click on an object and adjust the most widely used properties in place.

If the drag-and-drop was ONLY used to set visual tree location and nothing else I think it would be very useful and generate clean XAML. Users will then have to learn themselves how to adjust properties like Margin/Padding/Alignment in a traditional side pane or property flyout of the selected object.

This is a fundamental difference from WinForms ideas but I think is the only correct approach.

Bonus points: Have AI integration that suggests simplified/better XAML as you go.

[thevortexcloud]

That's why you get really, really bad Margins and things littered in the XAML.

I agree. But Microsoft is not alone in this. I have used HTML designers that do similar things, and they were just as bad.

XAML is NOT meant for absolute positioning UI's, it's meant for relative positioning.

Indeed. Which is why I am so worried about the designer exposing things like widths and margins so easily. People who don't know better will use them because "the designer said I could". The designer needs to be clear that people should not use them without good reason (possibly even hide them under an advanced menu?). Or, as I said previously, Avalonia needs to add things like relative units to allow for easier relative sizing and positioning.

Edit: Context menus and overlay controls directly on the design surface to add things like Grid columns or adjust font properties would also be useful. Think of something like Inkscape where you can click on an object and adjust the most widely used properties in place.

Yeah, a decent grid editor would be very useful. Grids are just in general painful to deal with right now. But that's more to do with the design of the grid control. EG reviving the AutoGrid control would help a lot with that (and probably also make the designer simpler).

https://github.com/AvaloniaUI/AvaloniaAutoGrid

If the drag-and-drop was ONLY used to set visual tree location and nothing else I think it would be very useful and generate clean XAML. Users will then have to learn themselves how to adjust properties like Margin/Padding/Alignment in a traditional side pane or property flyout of the selected object.

This is a fundamental difference from WinForms ideas but I think is the only correct approach.

I agree that this is probably the only reasonable approach. But I suspect people a lot of people will never be happy with that after using things like the Win Forms designer.

[robloo]

Another topic here I'll just point out quickly but not elaborate on. It can open up a can of worms I want to avoid. Hopefully it's an internal discussion though.

DevTools, Reframe and Hot Reload are all complimentary technologies with a lot of shared ideas (and likely backend code). Evolving these into one product makes sense.

[MikeCodesDotNET]

I'm trying really hard to not the let team build an IDE. We do not want to build an IDE 🙈🙈🙈🙈

[thevortexcloud]

I'd use an IDE. There are really only two options for C# (and 1 for Linux). The old Monodevelop code is also still just sitting there after Microsoft killed it.

[LaurentInSeattle]

Definitely not the tool I would need.

I would much prefer a utility that could transcode Figma designs into XAML.
Touble is that Figma cannot export anything in a consistent and predictable format.

[thevortexcloud]

Now that I have thought about this more, I think a theme designer would be significantly more useful thing. But I have yet to think through the exact mechanics of how it would work yet. But making application wide themes is currently a slow and esoteric process.

[StefanKoell]

Ok, here are my 2c: in general, using XAML to build UI with the tooling at hand (Rider Integration, Intellisense, etc.) works very well. I too have my reservations about a drag'n'drop designer experience. I'm not sure it can work. I did a lot of WinForms and I abandoned the designer years ago and did my own layouting - mostly because the designer couldn't handle DPI aware designs. So, XAML or some fluent API to build layouts with intellisense works fine for me and I don't really "need" a designer but I'm also not opposed by the thought there could be a good drag'n'drop experience. Just because I haven't seen one yet, doesn't mean it's not possible. Unfortunately all attempts to tackle the problem were unsuccessful - so I have little to no hope that this will change.

So in short: if you have an interesting idea/concept on how to built it, maybe it's worth a try. If the end result is similar to what we already know (and also not that successful), I suggest you invest time and resources somewhere else. Hot Reload, for example, is something far more important, I guess. Especially when you look at other frameworks where this is already working very well and a huge productivity boos.

[thevortexcloud]

I'm not sure it can work.

To add to this and what I previously stated: I have still yet to use one for a markup language where I did not give up on it within ~5-10 minutes and just go back to doing things by hand because it was faster and easier. I am sure it could be possible to make one where I did not feel the need to do this, but it would require a lot of research into UI/UX.

For non markup based GUIs though, I have happily used designers without much fuss. Generally because non markup GUIs tend to be a nightmare to work with without a designer

I suggest you invest time and resources somewhere else.

I agree with this too, unless you have some really good ideas for it. But without a design document it's rather hard to judge.

[CastelloBrancoTecnologia]

Look ad borland delphi/cbuilder 6, at 1990 years.

If avalonia can mimic borland RAD way of develop notting will be bether than avalonia.

[LeoYang06]

I think drag-and-drop UI is more attractive to people who don't understand XAML/AXAML well, which can lower the entry threshold and attract more newcomers to use Avalonia. For experienced users, they prefer to write AXAML directly because it's more flexible.

Of course, if the code generated by dragging and dropping matches AI-generated code and almost doesn't need modification, then it will be quite appealing to everyone.

[thevortexcloud]

matches AI-generated code

I should hope not. The goal is to make things easier and faster, not require people who don't know what they are doing to double check everything constantly.