Designer or No Designer? What say you?
-
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
Quote:
Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable.
There is a lot of regression taking place all over Microsoft's products (think also for most of the other IT companies). It comes from these same people. They are all self centered in addition to what you have observed, and as a result have no clue how people are actually using their software. Email is a prime example. The usability is degrading due to Fort Knox security requirement they impose on everything regardless if the user needs it. Cannot travel anywhere away from my office to trigger a whole series concerned emails and requirements to keep using my email. Try traveling outside of the country then it gets even worse reaching a point where I just not use email because it is too much of a hassle.
-
Pretty much won't touch Xamarin XAML because of the lack of a designer. Won't touch WPF because it lacks a usable designer. While I'm stuck with HTML, tools that let you do side-by-side HTML with preview mitigate the pain. And yes, very important. I remember when I came out with MyXaml and almost everyone (some rather nastily) said they'd never use a UI generator where you had to edit the "markup" by hand. And guess where we are now? And guess what camp I'm in when it comes lack of designers. :laugh: That said, if I can avoid having to even touch HTML, the happier I am. I don't mind writing HTML generators (usually client-side on the fly) that create the HTML from some metadata format. But that's me.
Latest Articles:
16 Days: A TypeScript application from concept to implementationMarc Clifton wrote:
Won't touch WPF because it lacks a usable designer
For what it's worth Marc, it's not that hard. I've been doing WPF UI's for over ten years now. WPF 'design' in XAML lends itself well to a top-down, organization first then detail approach.
Software Zen:
delete this; -
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
Interesting discussion. The reason it interests me is that for the last 20 years I have been developing GUI tools for a niche market (Powerbasic) and one of the things I built which it lacked was a Visual Designer. Visual Designers are not easy to build. I spent 20 years writing my own GUI framework (WIN32) with a Visual Designer engine built into it and when I looked for information about how to write a drag and drop engine specific to programming Visual Designers, there simply wasn't any. There are no native high level API's in the Windows WIN32 for this. Many indie programming languages have come into existence over the years, some hobby languages, others professional level, but the one thing they often lack is a decent Form designer. The reason is that it is not easy to build one.
-
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
Long time WinForms coder here, and before that, C++/MFC for many years. I dont use the designer in web apps much, except to add a control in general and then I go to the code. In WinForms, the designer is a huge time saver IMO, even though sometimes it gets confused and I have to drop into the generated code and fix things. In VC++, and I go back to version 1.52 (and before that, yes, I'm old), the designer was much less useful, but it still did a lot of work for you. Use bare XML to do a form layout? No, I'd rather not.
-
The WinForms designer is not without faults (derive a control from an abstract UserControl base and start swearing for example) but by heck it makes life easier! That's one of the things that - still - makes WPF feel "unfinished" and somewhat amateur to me. If you can do it for C# code, why the heck not do it for more organised and structured XML? I was looking forward to Blazor but you do need a good designer to give you a WYSWYG "starter" or you waste too much effort before you can start to work on the actual "working stuff".
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
That's one of the things that - still - makes WPF feel "unfinished" and somewhat amateur to me. If you can do it for C# code, why the heck not do it for more organised and structured XML?
Have you looked at the crappy XML based designer for SSRS. Access was far more powerful and easy to use. This is probably why MS hasn't built a decent designer for XML based UIs.
-
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
I completely agree with your assessments regarding the Windows Forms Designer. However, I have been developing with WPF(XAML) for quite a while now so I have seen the changes in the WPF Forms Designer over the years. And it is still as bad as it always has been since very little of it makes any sense from a visual perspective. Using the WPF Designer appears to work the same as the old Java forms designers, which I found to be completely useless. As a result, I simply use the XAML Markup Editor that is tied to a WPF window or Page...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
In general, drag and drop, point and click is easier to use and approach. But.... with something like WPF, coordinates can be specified in terms of relative or absolute, and the organization of your containers and how they're setup is relevant too. It doesn't lend itself to a drag and drop approach. You can drag a window and drop it somewhere, and there are several ways the designer could format the code and it can't guess what you actually want. Only you know that. I've only used it a little bit, but I found the xaml editor more helpful. It reminded me of webforms, speaking of which, I never use the designer for web forms. I'm terrible with making pretty web forms, so I just create the elements I need, get it functional and pass it off to our web designer guy who does CSS against everything. He too, hates the designer because it gives you no idea at all what your page is going to actually look like. With Win32 API the designer makes sense, all coordinates are absolute so there is only 1 answer when it comes time to using the code. But even here, I put everything in table or flow layout panels and use those to control the layout logic. I never let anything just sit in a parent container, many of our applications are language translated and having things sit in absolute coordinates is a recipe for disaster. And given that designers are easier if you're lazy, I would think millenials would be all about making them a top priority. I doubt the lack of a designer is because of millenials.
-
Interesting discussion. The reason it interests me is that for the last 20 years I have been developing GUI tools for a niche market (Powerbasic) and one of the things I built which it lacked was a Visual Designer. Visual Designers are not easy to build. I spent 20 years writing my own GUI framework (WIN32) with a Visual Designer engine built into it and when I looked for information about how to write a drag and drop engine specific to programming Visual Designers, there simply wasn't any. There are no native high level API's in the Windows WIN32 for this. Many indie programming languages have come into existence over the years, some hobby languages, others professional level, but the one thing they often lack is a decent Form designer. The reason is that it is not easy to build one.
If it were easy, everyone could do it. :) The fact that the MS VB team did it in the late 1980s, and re-writing the VB IDE in assembler no less, shows that the right folks on the right team with the right leadership and vision can do that which is "not easy". Why has MS failed to hire that caliber of developers, testers, and leadership for UI tooling in Visual Studio?
-
In general, drag and drop, point and click is easier to use and approach. But.... with something like WPF, coordinates can be specified in terms of relative or absolute, and the organization of your containers and how they're setup is relevant too. It doesn't lend itself to a drag and drop approach. You can drag a window and drop it somewhere, and there are several ways the designer could format the code and it can't guess what you actually want. Only you know that. I've only used it a little bit, but I found the xaml editor more helpful. It reminded me of webforms, speaking of which, I never use the designer for web forms. I'm terrible with making pretty web forms, so I just create the elements I need, get it functional and pass it off to our web designer guy who does CSS against everything. He too, hates the designer because it gives you no idea at all what your page is going to actually look like. With Win32 API the designer makes sense, all coordinates are absolute so there is only 1 answer when it comes time to using the code. But even here, I put everything in table or flow layout panels and use those to control the layout logic. I never let anything just sit in a parent container, many of our applications are language translated and having things sit in absolute coordinates is a recipe for disaster. And given that designers are easier if you're lazy, I would think millenials would be all about making them a top priority. I doubt the lack of a designer is because of millenials.
You do know that Windows Forms has been doing relative or absolute for quite a while? Including docking options for UI components.
-
You do know that Windows Forms has been doing relative or absolute for quite a while? Including docking options for UI components.
A little history about WIN32 and scalable coordinates. in the Windows 3.1 days, the WIN API used dialog units which were scalable. Dialogs units with old Windows worked well, since they scaled to the system font and a dialog unit came out exactly 2 pixels in most instances on most displays. When WIN32 came along, so did many larger displays and dialog units didn't always scale properly and didn't come out exactly to pixels, but a percentage of a pixels. This would cause forms designed using the Windows Dialog Designer (aka. very old school designer dating back to Windows 3.1 and coding in pure C) to shift a pixel or two and things often didn't line up properly on some systems. As a long time WIN32 programmer I saw the pros and cons to dialog units. So when I started writing my own GUI framework based on the WIN32, I choose a different route. Dialog units are actually based on a character unit. Dialog Base Units as they are called are the average width and height of the system font. The system font in Windows 3.1 days was a fixed width and came out to 8 x 16 pixels. A dialog unit was defined as (dialog base unit width / 4) and (dialog base unit height / 8). So 8 / 4 = 2 pixels width and 16 / 8 = 2 pixels height. So dialog units came out exactly as 2 x 2 pixels. But later on with WIN32 windows could scale the system fonts and on different displays the dialog base unit did not come out exactly 8 x 16 pixels. Now you had a problem when scaling. I liked how Dialog units worked, but they were flawed when scaled. So I decided a different route. Why not define a dialog base unit in a similar way by getting the average the current system font (even variable width) to define an internal character unit size. But instead of defining coordinates using whole numbers like dialog units do, why not defined character units using floating point. This would provide pin-point accuracy. You could define a coordinate using decimals, like 1.75 horizontal character unit and 2.5 vertical character units. No matter how the end users system defined the font scaling, you would pixel accurate positioning. I actually did this in a GUI framework and surprise, it works amazingly well. By building a Visual Designer using character based units which are floating point, you can get very accurate scaling for any system. Just have the GUI framework convert internally the character units to what ever units you desire and at any scaling. Now add to this your own auto-resize engine (for when forms are resized at run time by the u
-
You do know that Windows Forms has been doing relative or absolute for quite a while? Including docking options for UI components.
Yes I know the Dock and Anchor options, but I can't do something like say the width of my text box is 80%.
-
Yes I know the Dock and Anchor options, but I can't do something like say the width of my text box is 80%.
Sure you can. You can add code in an event, or size it for 80% of the design window, and let it auto size after that. I’ve done that in my WinForms apps. Just think through what tools are in your toolbox and use them.
-
Marc Clifton wrote:
Won't touch WPF because it lacks a usable designer
For what it's worth Marc, it's not that hard. I've been doing WPF UI's for over ten years now. WPF 'design' in XAML lends itself well to a top-down, organization first then detail approach.
Software Zen:
delete this;of the three UI's supported by dotnet; my level of productivity is quickest with Winforms, followed by UWP, and lastly is WPF. WPF for me is just not as "discoverable" as the other two formats, even when using Blend.
-
of the three UI's supported by dotnet; my level of productivity is quickest with Winforms, followed by UWP, and lastly is WPF. WPF for me is just not as "discoverable" as the other two formats, even when using Blend.
Matt McGuire wrote:
Blend
I've never been able to use Blend. It only has a "dark" user interface (even the so-called light theme is gray over darker gray) and is unusable to my middle-aged vision.
Software Zen:
delete this; -
My opinion is right for me, but it may not be right for you. But your opinion would be useful. The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer. Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio. Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable. That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
For HTML, I never used any designer GUIs. My XAMLs are usually hand-coded, too, but I like to use the designer as a preview tool. I also have some cases of Windows Forms dialogs, where for some reason the visual designer doesn't work, and I must say, this decreases my productivity by at least 50 %.
