[WorldMaker]

The WinRT XAML control stack originates more from directly from "Avalon", WPF's precursor, than Silverlight. Windows Phone 7 was Silverlight-based as an interim stepping stone, and the .NET Core platform is closer in origin to Silverlight than the classic desktop .NET Framework (though not exactly either), which are sources of confusion there, but WinRT/UWP doesn't originate from Silverlight (it just inherits some insight/lessons from it).

I've seen some great power user experiences with UWP, even ones that are happy being "mobile first" and "touch first". "Touch first" is still great for mousing (especially as screen DPIs keep rising and more setups involve monitors in multiple DPI resolutions), even if you think it leads to lower information density (there are tricks to that).

At least in Enterprise environments I've worked "mobile first" is incredibly useful because people are happy being able to work from the device they already carry around at all times. It's to my sadness there isn't more Windows mobile devices as Cordova and/or Xamarin continue to eat up more and more of my development time I could be spending more directly on the applications themselves.

[Const-me]

> "Touch first" is still great for mousing (especially as screen DPIs keep rising and more setups involve monitors in multiple DPI resolutions)

WPF is based on vector graphics just like XAML, and high DPI is available for a long time. Per-monitor DPI support is also available for more than a year, they did that in .NET 4.6.2 released in 2016.

[WorldMaker]

Yes, I know how similar WPF is to UWP in DPI support. What "touch first" as a philosophy adds on top of raw DPI support is the concepts of: strong margins, strong minimum sizes, readability when partially obscured. Those things benefit mouse users too, they drop the number accidental clicks, and speed in which a mouse user can click a specific target (faster to find it, faster to mouse over to it, less accuracy required to click it means more speed to go ahead and click it). All of that is UX knowledge that's been passed around for decades before "touch first" (Fitt's Law), but "touch first" helps cement the concepts. If you can touch it, you can click it quickly.

The classic 16px-by-16px/32px-by-32px "toolbar icon" of the Win32 era is now far smaller than most FPS's "headshot" hit boxes on current monitors/DPI settings. Enterprise users shouldn't need to score headshots every time they try to accomplish a task.

Edit to add: …And yes, you could do all of that in WPF too, there are some great "touch first" WPF apps I've encountered over the years. The difference between WPF/UWP here is mostly default stylesheets. But the argument here being replied to is that "touch first" doesn't matter, which I think is incorrect, "touch first" is huge, and does matter, even for (maybe especially for) "Enterprise".

[Const-me]

> strong margins, strong minimum sizes, readability when partially obscured

I’ve programmed both for years but never heard about these differences. Do you have a link?

> The difference between WPF/UWP here is mostly default stylesheets

Right, but in my experience when I don’t care about UI design, I can use anything, even win forms. When I care, and have a professionally made UI design on input, default styles & templates are not that relevant for both platforms. I need to create my own ones anyway to implement what the UI designer wants.

[WorldMaker]

https://en.wikipedia.org/wiki/Fitts%27s_law

https://en.wikipedia.org/wiki/Hick%27s_law

https://en.wikipedia.org/wiki/Steering_law

https://en.wikipedia.org/wiki/Crossing-based_interface

---

https://blog.thepapermillstore.com/design-principles-white-s...

---

https://fluent.microsoft.com/

Especially:

https://docs.microsoft.com/en-us/windows/uwp/design/input/mo...

https://docs.microsoft.com/en-us/windows/uwp/design/input/to...

https://docs.microsoft.com/en-us/windows/uwp/design/input/to...

---

> When I care, and have a professionally made UI design on input, default styles & templates are not that relevant for both platforms. I need to create my own ones anyway to implement what the UI designer wants.

A good UI designer may not realize that they desire some of the same ideals as the platform defaults, especially with something like the Fluent Design System. It may not be your job to second guess a UI designer you are working with, but there are times where it makes sense to encourage a UI designer to know/understand the defaults of the platform, and especially the reasons for the defaults of the platform. I've been especially glad since the Fluent branding attempt that Microsoft has been doing a much better job documenting it and the reasoning behind it, as you can see in the links above.

> Right, but in my experience when I don’t care about UI design, I can use anything, even win forms.

In my mind, that is when defaults matter most, when you don't care. If you can get a lot of niceties for free, with no extra work on your part because they are the default, on a platform like UWP, then why not take advantage of that?

The software world and especially the enterprise software world is full of programs built by programmers that could care less about UI design and it shows, and it makes users miserable, even when those users are our future selves sometimes. So many papercuts that could have been avoided by choosing a platform with better defaults to begin with. (Friends don't let friends choose WinForms in 2018.)

[Const-me]

Thanks for the links. I didn’t realize UWP has all that by default. When I developed for WinRT/UWP it was for touchscreen-only platforms. But for WPF I do implement what’s written there, however yes have to do that manually both in C# and xaml/styles/templates.

> there are times where it makes sense to encourage a UI designer to know/understand the defaults of the platform

Did that sometimes but it was mostly about less obvious stuff, like controls behavior or animations. I was lucky to work with professionals who didn’t try to bring foreign-looking stuff to Windows.

> Friends don't let friends choose WinForms in 2018

For enterprise software I probably wouldn’t. But for e.g. internal tool for a couple of users and with very simple UI (such as a single dialog application with a couple of edit boxes) WinForms still works OK. It’s simpler to use, integrates with older lower-level technologies better (Win32 API, ActiveX, windows shell, terminal services a.k.a remote desktop), and often consumes less resources (Win32 API is decades old and hence designed for ancient PCs).