Yes, this is WinForms. Klaus Loeffelman shows the .NET 11 preview: msft.it/6012aoirs
Oct 18, 2026 · 1:00 PM UTC
21
23
195
19,040
@VisualStudio I’m old enough to remember when you could click anywhere in the text of radio buttons and check boxes.
We don’t have to live with extremely minor changes talked about as though they are worth a 2 year release cycle…
We don’t have to live with extremely minor changes talked about as though they are worth a 2 year release cycle…
0
0
6
469
@VisualStudio So you guys made .net 10 have a default padding of 0, just so you can pretend that you did something in .net 11.
smh
smh
0
0
1
222
@VisualStudio Winforms are great, but we invested long years on WPF, I think Microsoft needs to make a decision, which one we can use for real projects?
0
0
0
47
@VisualStudio It looks great! I still do a lot of WinForms and it is my default choice for Desktop. We are looking forward to exploiting the new features to enhance the applications we have and we hope to see WinForms continue to evolve!
0
0
0
16
@VisualStudio Thanks, but not set option back color for calendar box darkmode, pls fix this
0
0
0
4
@VisualStudio Now it’s even uglier. Why does everything Microsoft touches turn ugly?
0
0
1
102
@VisualStudio is this still relevant? will anyone use winforms in AI era, this is token hungry framework for desktop design
1
0
0
389
@VisualStudio "a customer form".
Brother, no one does desktop-app customer-facing forms anymore. Who is this demo made for?
Brother, no one does desktop-app customer-facing forms anymore. Who is this demo made for?
1
0
0
285
@VisualStudio never seen a company call their software's previous version ugly. I can't imagine Apple or Google saying "look at this shit that we did before. And look at it now."
1
0
0
41
@VisualStudio WinForms is still evolving, and it’s great to see .NET getting continued improvements. Always interesting to see what’s coming next for developers.
0
0
2
258
@VisualStudio disgustingly bad!!!
- Why no margin bottom in Title
- Why my eyes have to burn to look those date pickers
- Why gaps not consistent inside contact details inputs
- Why discount box's value not have same padding left
- Switch boxes are to short and wide
- Whites are too bright forolor contrast is too much
- Field wrappers do not have same paddings do not match
- Each field/section should have different/bigger padding to differentiate things are separate
@msdev how you able to end up that? sorry but have to say; S*HT.
BTW, you do not need to know anything or be genius or pay $200k. I'm not joking, to test that idea, I just asked DS4.1 via deepseek harness to point me UI/UX issues in this; it worked ~20m
----
P0 — Blocking / trust-destroying
1. No visible save path. The viewport ends in empty dark space at y≈580–602. The only commit affordance is an unlabeled 20px floppy icon in the top-left toolbar (item 6). With this many editable fields and no Save/Cancel bar, no dirty-state indicator, and no navigation guard, the most likely user outcome is silently losing edits. Consequential fields (credit limit, discount %, status) live on the same form as the notes box — that's an error-prevention failure, not just a style issue.
2. Wrong field order in Address. Line 1 = "Suite 420", Line 2 = "North Building", Street = "1234 Market Street". US/UK postal convention is street → unit, so users will type the street into Line 1. This is a label-semantics bug that guarantees dirty data on every new record.
3. "City / ZIP / State:" is one label over three boxes, and it's US-hardcoded. City gets 276px, ZIP gets 57px, state gets 34px. The ZIP is visibly clipped ("98101-…") with no room for ZIP+4. Country is a dropdown including presumably non-US options, but there's no path to enter a non-US address (no postal-code/region fields that adapt). Also inconsistent: Country is a select, State is a 2-char free-text box.
P1 — Contradictory / duplicated controls
4. "Status: Active" exists twice with two different affordances (item 4): a switch in Customer identity, and a dropdown in Account and preferences. Same concept, two owners — users can't tell which is authoritative, and a switch has no confirmation for a state change that likely gates account access.
4b. Preferred contact vs Permissions can contradict. Preferred = Email is selectable while "Allow email" is off. Nothing prevents the invalid combination, and there's no inline warning.
6. Two dropdown idioms plus a third. Custom dark selects (chevron), native OS date fields (white, calendar icon), and numeric spinners (single-char triangle pair) all coexist. Each one signals a different platform/toolkit.
10. Numeric fields have no unit or formatting. Credit limit reads "7,500.00" with no currency; Default discount reads "5.0" while only the label carries "%". The spinner arrows (item 10) are also the smallest targets on the screen.
P1 — Accessibility (measured)
Off-toggle contrast: track #4E4E4E on panel #111 = 2.27:1, against the 3:1 non-text minimum. The green on-state is 4.84:1, so the state is legible — but the control boundary for "off" is nearly invisible, which is exactly the state people need to verify.
Toolbar icons: Save is 18.9:1, pencil 12.2:1, but three icons sit at 2.2–2.5:1 — indistinguishable from disabled. Also ~17px glyphs with no labels, below the 24×24 target guidance; no text alternative visible.
Birth-date calendar glyph: darkest pixel 1.8:1 on white (item 2, left) — effectively invisible. The Customer-since one is 8.2:1, so the same widget is styled two different ways.
Toggle state is color+position only — no "On/Off" text. Recommend explicit state text or a checkbox+label pattern.
Native white date fields break dark theme and are 20–21px tall vs 30–31px siblings, so the row rhythm breaks and field-height hits the click target (though desktop-pointer mitigates that).
P2 — Layout and consistency (measured)
Three different right edges: contact inputs end at x=991, account selects at x=928, notes panel at x=993. The page never resolves a single right margin.
Account card inset is lopsided: 20px left padding vs 67px right. Card spans 506→995; content stops at 928.
Heading rhythm is inconsistent: "Customer notes" cap height is ~30px vs ~15px for the other four headings, and it's wrapped in the brightest frame on the page (7.1:1) — visual weight lands on the least important section.
Section headers don't share a component: Address is a solid green bar; the other three are plain text. Green is then overloaded three ways — section identity, "on" toggles, and "Active" status.
Header text doesn't align to body: Address header starts x=23; body labels start x=17–20.
Label→field gaps vary 13–81px (Birth date 13, City 13, Email 81, Mobile 68), so scanning down a column is stop-start.
Empty "Middle" renders as a bright-bordered empty box, reading as a validation error even though it's optional. Every field shares one weight, so nothing communicates required vs optional.
System-derived fields are editable: "Customer No. C-10427" and "Customer since 7/30/2026" are normal inputs. IDs and derived timestamps should be read-only text, not editable fields.
No record context: no title ("Edit customer — Alex Morgan"), no breadcrumb, no back link. Combined with the absent save bar, a user has no idea what they're editing or how to leave safely.
- Why no margin bottom in Title
- Why my eyes have to burn to look those date pickers
- Why gaps not consistent inside contact details inputs
- Why discount box's value not have same padding left
- Switch boxes are to short and wide
- Whites are too bright forolor contrast is too much
- Field wrappers do not have same paddings do not match
- Each field/section should have different/bigger padding to differentiate things are separate
@msdev how you able to end up that? sorry but have to say; S*HT.
BTW, you do not need to know anything or be genius or pay $200k. I'm not joking, to test that idea, I just asked DS4.1 via deepseek harness to point me UI/UX issues in this; it worked ~20m
----
P0 — Blocking / trust-destroying
1. No visible save path. The viewport ends in empty dark space at y≈580–602. The only commit affordance is an unlabeled 20px floppy icon in the top-left toolbar (item 6). With this many editable fields and no Save/Cancel bar, no dirty-state indicator, and no navigation guard, the most likely user outcome is silently losing edits. Consequential fields (credit limit, discount %, status) live on the same form as the notes box — that's an error-prevention failure, not just a style issue.
2. Wrong field order in Address. Line 1 = "Suite 420", Line 2 = "North Building", Street = "1234 Market Street". US/UK postal convention is street → unit, so users will type the street into Line 1. This is a label-semantics bug that guarantees dirty data on every new record.
3. "City / ZIP / State:" is one label over three boxes, and it's US-hardcoded. City gets 276px, ZIP gets 57px, state gets 34px. The ZIP is visibly clipped ("98101-…") with no room for ZIP+4. Country is a dropdown including presumably non-US options, but there's no path to enter a non-US address (no postal-code/region fields that adapt). Also inconsistent: Country is a select, State is a 2-char free-text box.
P1 — Contradictory / duplicated controls
4. "Status: Active" exists twice with two different affordances (item 4): a switch in Customer identity, and a dropdown in Account and preferences. Same concept, two owners — users can't tell which is authoritative, and a switch has no confirmation for a state change that likely gates account access.
4b. Preferred contact vs Permissions can contradict. Preferred = Email is selectable while "Allow email" is off. Nothing prevents the invalid combination, and there's no inline warning.
6. Two dropdown idioms plus a third. Custom dark selects (chevron), native OS date fields (white, calendar icon), and numeric spinners (single-char triangle pair) all coexist. Each one signals a different platform/toolkit.
10. Numeric fields have no unit or formatting. Credit limit reads "7,500.00" with no currency; Default discount reads "5.0" while only the label carries "%". The spinner arrows (item 10) are also the smallest targets on the screen.
P1 — Accessibility (measured)
Off-toggle contrast: track #4E4E4E on panel #111 = 2.27:1, against the 3:1 non-text minimum. The green on-state is 4.84:1, so the state is legible — but the control boundary for "off" is nearly invisible, which is exactly the state people need to verify.
Toolbar icons: Save is 18.9:1, pencil 12.2:1, but three icons sit at 2.2–2.5:1 — indistinguishable from disabled. Also ~17px glyphs with no labels, below the 24×24 target guidance; no text alternative visible.
Birth-date calendar glyph: darkest pixel 1.8:1 on white (item 2, left) — effectively invisible. The Customer-since one is 8.2:1, so the same widget is styled two different ways.
Toggle state is color+position only — no "On/Off" text. Recommend explicit state text or a checkbox+label pattern.
Native white date fields break dark theme and are 20–21px tall vs 30–31px siblings, so the row rhythm breaks and field-height hits the click target (though desktop-pointer mitigates that).
P2 — Layout and consistency (measured)
Three different right edges: contact inputs end at x=991, account selects at x=928, notes panel at x=993. The page never resolves a single right margin.
Account card inset is lopsided: 20px left padding vs 67px right. Card spans 506→995; content stops at 928.
Heading rhythm is inconsistent: "Customer notes" cap height is ~30px vs ~15px for the other four headings, and it's wrapped in the brightest frame on the page (7.1:1) — visual weight lands on the least important section.
Section headers don't share a component: Address is a solid green bar; the other three are plain text. Green is then overloaded three ways — section identity, "on" toggles, and "Active" status.
Header text doesn't align to body: Address header starts x=23; body labels start x=17–20.
Label→field gaps vary 13–81px (Birth date 13, City 13, Email 81, Mobile 68), so scanning down a column is stop-start.
Empty "Middle" renders as a bright-bordered empty box, reading as a validation error even though it's optional. Every field shares one weight, so nothing communicates required vs optional.
System-derived fields are editable: "Customer No. C-10427" and "Customer since 7/30/2026" are normal inputs. IDs and derived timestamps should be read-only text, not editable fields.
No record context: no title ("Edit customer — Alex Morgan"), no breadcrumb, no back link. Combined with the absent save bar, a user has no idea what they're editing or how to leave safely.
2
0
1
438
@VisualStudio WinForms? Microsoft is pure retro nostalgia straight out of my childhood. Why not go full antique and pair it with VB6 alongside an Internet Explorer 6 compatibility layer?
0
0
0
23
@VisualStudio kann grok bot solche programme schreiben @grok ?
1
0
0
121
@VisualStudio A migration walkthrough with an existing, control-heavy app would be valuable here: what updates automatically, and what still needs manual styling? Including custom controls and high-contrast mode would make it especially practical.
0
0
0
32
