Hacker News Reader

UWP is unfortunately not a modern version of WPF. It is an adapted form of the Windows 8 'WinRT' platform. It originates from Silverlight of all things. This is part of the problem, its almost impossible to create WPF-like 'power user' experiences with UWP - as its design philosophy is 'mobile first' and 'touch first'.

Enterprises who would think of building apps with functionality that can be delivered with a UWP app are more likely to just build a web app - its cheaper and requires less maintenance.

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.

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

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

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

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

---

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

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

> I can't see why you wouldn't develop your enterprise software using it... because it's no different from any other stack

From a .Net perspective, the article authors, it's the debugging challenges that are the major salient difference between WPF and UWP. Considering the demands those frameworks place on developers who are making 'innovative' GUIs there are numerous things that can go terribly wrong at run-time. A lack of relevant debugging tools and a hop between technologies could be a showstopper for some.

COM + .Net competence, like competence with the Win32 API, is somewhat generational. Younger .Net developers are not versed in these things, and those who are command significantly higher salaries and are increasingly less likely to be doing front-end work over time.

If you're dealing with Enterprise customers, or development in the Enterprise, there are real costs associated with moving your baseline developer requirements into specialist territories.

The platform UWP needs to run on is Windows 7. Without that support it’s not an option for my company.

A lot of enterprises have only recently moved to Windows 7 (like my employer). A framework that is incompatible with Windows 7 is just a non starter.

I think you'll find that your employer will move to a newer OS more quickly. Windows 7 is already in extended support, and that ends in 2020. Microsoft is doing their best to reduce the need to support legacy products, so a custom support agreement for Windows 7 is going to be extremely expensive.

Perhaps, though given how long it took between the begining and end of the win7 roll out I am not convinced. But in any case any IT team starting a project for a few more years will not touch UWP since at least some of the users will be under Win7.

I've spoken with several companies that just finished transitioning to Windows 7 in the last year or so.

For them, official support from MS is not a major factor in their decisions.

Whether it should be or not is another matter, but in talking with them, availability of patches really doesn't move the needle as much as you'd expect.

Then they have very little understanding of information security, I would say.

Connecting a computer running an unsupported OS to the Internet is straight up negligence. You are basically asking to get hacked.

Why though? Does your company mandate 10 year old cars too?

Cars are physical objects that degrade with use/time.

An operating system will run as good as it did 10 years ago (just not as good as those released 10 years later)

This isn't strictly true, as exploits are found the experience can definitely degrade.

The reason is simple, Windows 7 has over 40% market share. It's hard to ignore that.

Xamarin has a WPF renderer in some state that is somewhat UWP interoperable.

Maintaining a UWP head and WPF head with .NET Standard libraries shared between them is a reasonable option in some circumstances.

But better still, maybe encourage your employers not to death race upgrades versus exploits all the way to the bitter end in April 2020 like they did with XP's extended support period.

>But better still, maybe encourage your employers not to death race upgrades versus exploits all the way to the bitter end in April 2020 like they did with XP's extended support period.

Ikr, but we can't expect all our customer to upgrade just because our product is in UMP. When we looked at one of our products user base, we could see that over 50% used Windows 7. That ruled out UMP for the subsequent project.