3 ms·

This is a sad day because if the Windows team at Microsoft can't get the Office team to build snazzy native apps then that can only mean there is no hope remain

This is a sad day because if the Windows team at Microsoft can't get the Office team to build snazzy native apps then that can only mean there is no hope remaining for native apps in Windows. This underlying reason/trigger for this is the Windows team's failure to differentiate native apps in an attractive way. The flat look has been a disaster from a usability point of view, but it also has been a disaster from a differentiation point of view. If native Outlook app looks no different or better than the Web version then there is no longer any reason to maintain the native app. For native apps to succeed over Web — and Steve Jobs has shown this can be done — it must have a differentiated look & feel, and users must find the look & feel attractive. The Flat look and feel meets neither of these criteria. Microsoft pioneered the Flat look and feel, and it has since been copied by Apple, which "proved" the wisdom of Microsoft's move. But it has been downhill for Windows native apps since then.

ripley12 6y ago
Aesthetic differentiation is an interesting consideration, but even aside from that the native UI framework options are currently not practical for applications like Office. Like, their options are: - Wait for WinUI 3, hope it’s good+stable enough eventually - XAML Islands which I hear is super buggy and janky - WinUI 2.x which constrains them to an AppContainer. Not gonna happen for an app as big+legacy as Office - WPF which is on life support
- pjmlp 6y ago
  Unfortunately you forgot a dot there, "Wait for WinUI 3.x", with x probably being quite big. https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
  - ripley12 6y ago
    Ugh, true. I'm pretty annoyed by how many features are missing from 3.0, I won't be able to use it in my hobby app because I depend on MediaPlayerElement for audio.
pjmlp 6y ago
The Windows team have themselves to blame for the way this has been handled since Windows 8. Here are some bullet points, that even I as WinRT believer have to acknowledge, please hold with me starting rant mode: - Windows 8 broke compatibility with XNA/Silverlight model - WinRT even though it is definilty a better COM, required 3 implementations on Windows 8.0 (phone, tablet and desktop) - Windows 8.1 reduced that to 2 (phone/table and desktop) with UAP, and naturally a rewrite was required - Windows 10, merged all models, renamed UAP into UWP, and naturally a rewrite was required - Windows team not happy with .NET taking up of the Windows eco-system, botched Longhorn, doubled down on COM eventually leading up to WinRT/UAP/UWP, whatever you want to call it. - Naturally they couldn't just reuse .NET runtime with added support for AOT, so Windows 8.x adopted AOT compilatio model from Singularity, followed up by .NET Native on Windows 10. In both cases, also incompatible with regular .NET. - Similarly, C++/CX which was introduced for WinRT, the first time that Microsoft finally had a C++ RAD experience somehow comparable to C++ Builder, was killed by the Windows team pushing C++/WinRT with complete and total disregard for developer tooling, making those of us that depend on mixed code bases (.NET/C++) to feel we are back into the Visual C++ 6.0 days, manually editing IDL files in notepad and doing ATL like template magic. From their point of view, screw us, and we should wait until ISO C++23 for the Visual Studio team to be able to replicate in C++/WinRT the kind of tooling we were able to join in C++/CX. - Project Reunion just got their 0.1 milestone one (yep not a typo) - WinUI 3.0, although deeemed as the future native UI, won't be feature parity with UWP, only later the year - .NET 5 isn't supported in .NET Native, and the roadmap between CoreRT, .NET 6 and .NET Native isn't fully clear /rant mode off While this kind of reboots might be daily stuff on Apple and Google's platforms, it didn't land that well among the typical enterprise customers from Microsoft, and most likely not other Microsoft teams that are upper of the SDK food chain. However, why stay on Microsoft stack then? Because I could write equally long rants for the other eco-systems I develop for, and Microsoft while being this schizophrenic still provides the best developer experience and smallest rant list from my point of view.

ripley12 6y ago

Aesthetic differentiation is an interesting consideration, but even aside from that the native UI framework options are currently not practical for applications like Office. Like, their options are: - Wait for WinUI 3, hope it’s good+stable enough eventually - XAML Islands which I hear is super buggy and janky - WinUI 2.x which constrains them to an AppContainer. Not gonna happen for an app as big+legacy as Office - WPF which is on life support

pjmlp 6y ago
Unfortunately you forgot a dot there, "Wait for WinUI 3.x", with x probably being quite big. https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
- ripley12 6y ago
  Ugh, true. I'm pretty annoyed by how many features are missing from 3.0, I won't be able to use it in my hobby app because I depend on MediaPlayerElement for audio.

pjmlp 6y ago

The Windows team have themselves to blame for the way this has been handled since Windows 8. Here are some bullet points, that even I as WinRT believer have to acknowledge, please hold with me starting rant mode: - Windows 8 broke compatibility with XNA/Silverlight model - WinRT even though it is definilty a better COM, required 3 implementations on Windows 8.0 (phone, tablet and desktop) - Windows 8.1 reduced that to 2 (phone/table and desktop) with UAP, and naturally a rewrite was required - Windows 10, merged all models, renamed UAP into UWP, and naturally a rewrite was required - Windows team not happy with .NET taking up of the Windows eco-system, botched Longhorn, doubled down on COM eventually leading up to WinRT/UAP/UWP, whatever you want to call it. - Naturally they couldn't just reuse .NET runtime with added support for AOT, so Windows 8.x adopted AOT compilatio model from Singularity, followed up by .NET Native on Windows 10. In both cases, also incompatible with regular .NET. - Similarly, C++/CX which was introduced for WinRT, the first time that Microsoft finally had a C++ RAD experience somehow comparable to C++ Builder, was killed by the Windows team pushing C++/WinRT with complete and total disregard for developer tooling, making those of us that depend on mixed code bases (.NET/C++) to feel we are back into the Visual C++ 6.0 days, manually editing IDL files in notepad and doing ATL like template magic. From their point of view, screw us, and we should wait until ISO C++23 for the Visual Studio team to be able to replicate in C++/WinRT the kind of tooling we were able to join in C++/CX. - Project Reunion just got their 0.1 milestone one (yep not a typo) - WinUI 3.0, although deeemed as the future native UI, won't be feature parity with UWP, only later the year - .NET 5 isn't supported in .NET Native, and the roadmap between CoreRT, .NET 6 and .NET Native isn't fully clear /rant mode off While this kind of reboots might be daily stuff on Apple and Google's platforms, it didn't land that well among the typical enterprise customers from Microsoft, and most likely not other Microsoft teams that are upper of the SDK food chain. However, why stay on Microsoft stack then? Because I could write equally long rants for the other eco-systems I develop for, and Microsoft while being this schizophrenic still provides the best developer experience and smallest rant list from my point of view.