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.

[biwa]

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.

As a long-time WinForms user (victim?) I wholeheartedly agree with this. I don't really want to touch absolute positioning ever again.

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).

It's especially painful if you need to add a row or column in front of existing ones. A visual designer could be really useful here, handling/changing all the existing grid and row numbers.

[thevortexcloud]

As a long-time WinForms user (victim?)

Winforms is not too bad as long as you:

1. Use the layout system properly (nobody ever does this, because the designer does not go out its way to show it's even a thing)
2. Don't need high DPI support
3. Can use Visual Studio for the designer
4. Properly separate UI concerns from non UI concerns (nobody does this either)

Winforms is still very popular because of how simple it is. But it's really only simple if you have access to a designer. This is why when people come to frameworks like Avalonia with no designer, they suddenly don't know what to do. Making a GUI without a designer is a weird concept for a lot of people. EG #14207, #10134 where people expect Avalonia to work with a designer.

It's especially painful if you need to add a row or column in front of existing ones.

Exactly, the auto grid/a better grid control would fix all of that. You don't need to worry about cell positions, it just does it for you and flows into the next cell as needed. Having to manually fix all the cell coordinates feels very tedious.

A visual designer could be really useful here,

To add to what I said previously: While a designer would be helpful for existing grids, the fact a designer is preferable for this to me means the control API needs to be rethought. Otherwise if this sort of thing becomes the norm, it just slowly ends up in the winforms situation where it's difficult to do anything without the 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.

[LeoYang06]

Ease and speed are crucial. I mean achieving code usability comparable to AI-generated code, with as little manual post-editing as possible.
Many years ago, I envisioned a scenario where AI could generate code. At the time, it seemed impossible, but now it has become a reality and is performing well. Therefore, being able to generate code that better fits the current scenario based on the logical tree position of drag-and-drop controls and DataContext, etc., will also be a future trend, adding more intelligence to the tools.

[robloo]

Another aspect to consider here is what Microsoft Blend did. It has some features not available anywhere else like a powerful animation editor. So focusing on areas like that would give Avalonia Reframe an advantage.

A current day example of this is Neosis Studio (an early clone of WPF XAML):

https://www.noesisengine.com/studio/

As an aside another interesting avenue here is the application of Avalonia in major game engines. In those cases the teams are usually large enough to justify a stand-alone designer that isn't used by the dev team (which may very well rather use XAML directly). I know some on the team have done Gadot integration in the past as well.

[LeoYang06]

In addition to VS Blend, animation editors can also refer to lottielab for animation editing, especially the WYSIWYG experience of custom easing animation functions. Animation design and coding take much more time and are not easy to preview compared to regular controls. If a feature similar to lottielab can be implemented, it will surely be a major highlight.

[thevortexcloud]

I know I mentioned it before, but this sort of stuff would probably fit better in a global theme designer rather than a drag and drop control layout designer (as in 99% of cases, you would never do an animation there). Obviously having both in a single tool would be great as well though.

[guldud]

It is unlikely I'll ever be using drag'n'drop. I'd rather be using a mix of HotReload and AI.
AI could be useful to, for example, abstract project/solution XAML patterns into ressources/themes/styles/etc, tip you when your own common patterns can be used, generate XAML from PNGs, and so on.

[dbriard]

To be honnest, I'll rather need improved drag'n drop support in controls. For example, from control to another control, better visual overlay, live rearrange, etc.

[xanthome]

I strongly believe humans are not meant to generate XML files for a UI to appear on screen by typing.

I did BCGSoft/MFC, then Winforms, then WPF came along and zero tooling from Microsoft made me never ever touch it.

Because Avalonia is the only real option for cross platform GUIs I had to start doing XAML editing and I have hated every second of it.

[stevemonaco]

You can say the same about literally every schema. You're typing characters on a screen, not digging ditches. WPF is definitely not zero tooling, even though it still lacks some big things.

Get an autoformatter (built-in or XamlStyler), create some Live Templates (if on RIder) for common tags (style selectors, setters, etc), use built-in code snippets for Avalonia properties, and you'll be good. If you are incredibly picky about local context affecting formatting decisions in ways that can't be codified, you're in for pain. If you're trying to do everything in the VM or XAML, then you're also in for pain. Code-behind exists.

[danielanywhere]

For anyone who was not born to issue XAML code as a second language, like graphics artists, for example, there is definitely a need to bypass much of the direct involvement in code that takes place in a modern declarative GUI form environment.

Even for people who do type XAML for a living, there exist distinct disadvantages with relying upon any hierarchical markup language for general, everyday use. The only real disadvantage we need to mention along these lines is that content rarely ever remains static in design, and especially when it comes to graphics artists, they are going to want to move things around, possibly many times, before settling on even the first iteration. Hierarchical markup language makes that kind of movement very slow, tedious, and nearly impossible to accomplish at times, especially in the case where the tree is comprised of levels of uneven depths; a trait that is nearly always the case.

My name is Daniel Patterson, and I am the author of SvgTools at danielanywhere/SvgTools. Within that application, I have devised a comprehensive tool that allows a graphical artist with no technical knowledge at all to rapidly and successfully design forms in normal SVGs that compile directly in Avalonia UI.

It's important to note that the action (ImpliedDesignToAvaloniaXaml) currently only supports the toolset of Inkscape and Avalonia UI, but will be expanded to provide a much greater selection as the feature matures.

The process in question is called Implied Form Design, which as you might imagine, got that name from the fact that you are only required to indicate what you want to achieve in order to arrive at a fully functional, compilable form for your desktop application. The basic design process is literally limited to drawing a shape, then setting its Label (control type) and ID (code identification) values. Even the labeling process can easily be assigned to a non-designer role, who non-destructively prepares the SVG before conversion.

Unlike the methods used by Figma, Canva, and other visual editing platforms who have attempted this objective before, no encapsulation is required by the designer, since the enclosure of an object is derived from its Z-order and its 2d position on the form. This lack of requirement on the designer greatly helps to alleviate any burdens that arise from requiring an artist to define areas before they decide what is going to be in those areas. Additionally, grouping of any kind is unnecessary for a successful compilation, which allows the designer to group sets of objects in ways that make visual sense to them, as opposed to how those groups might be compiled functionally. You can find more complete descriptions of these deviations from past attempts in the associated user's manual.

After designing the form, you save it as an SVG, run the SvgTools conversion, and copy the resulting .AXAML file to your project directory, where you can immediately program directly against it in the associated code-behind file.

Much more information about Implied Form Design, including a complete user manual and comprehensive control reference is available from the front page of my repository at danielanywhere/SvgTools. A significant amount of basic testing has already been completed on a cross-platform basis, but since this is a new feature, I do expect that there will be bugs and overlooked details from time to time. If and when you find those, please create Issues. I will address them in a timely manner.

Sincerely,
Daniel Patterson, MCSD