Just 4 months ago they announced they were suspending development of OneNote Win32 in favor of just the UWP version [1]
Moreover, they have (had?) an entire multi-year roadmap planned around UWP, including the eventual release of a version of windows which was supposed to substantially reduce day-to-day reliance on Win32 for lower powered devices, codenamed Project Polaris [2], in an attempt to compete with Chromebook-like devices.
This is a massive destruction of confidence in the UWP platform. If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?
"If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?"
That's why I avoid any kind of Windows desktop development. They release a new framework every 2-3 years and developers are expected to adopt it. But then they drop support for that framework quickly and release a new incompatible one.
In the Windows environment choice is bad. You only have bad choices and the frameworks that are being used for flagship apps like Office are not available to devs.
I really envy iOS devs where the path to an app is straightforward and your biggest problem is to use ObjectivC or Swift.
Developing UWP apps is challenging though, it's not a straightforward experience and as a result many people hate it.
I don't know if you've ever had to debug a UWP app but compared to almost anything else it's painful. Exceptions don't propagate properly, and finding errors takes a ton of time. Development is likewise painful with elements of random things being required and the packaging and publishing process a nightmare compared to competitors.
UWP was made for phone and Microsoft then ported it to Core OS, but as a format it is not developer friendly. If you look at new Microsoft under Satya - and their goal of being developer friendly, this move makes sense. I wouldn't be surprised to see UWP and the current store deprecated entirely (as they are honestly failures).
The UWP version of Office has never really made sense. Office is a massive project and a moving target from a features perspective. It seems like a monumental task to reimplement it from scratch.
It makes more sense to gradually rewrite portions of it but that doesn't work well with the annual release model. It does however work with the O365 continuous release model they adapted from Windows 10.
Just as they're gradually porting Control Panel and other legacy Win32 apps to the Settings App. I could see them gradually convert Office to modern cross platform frameworks.
>If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?
Endemic at Microsoft. I believe the main reason the Xbox One Kinect - an impressive piece of hardware - failed, is that Microsoft themselves couldn't manage to make one big flagship game for it at launch. If Microsoft themselves are avoiding it, why on earth would third parties invest?
While it seems ironic and uncoordinated at first glance, perhaps UWP is right for OneNote since it has far fewer features than Word or Excel, and less legacy, being a newer app?
The headline is misleading. Microsoft is suspending development of the UWP Office applications, which happen to be touch-friendly. However, the headline implies that the remaining Win32 versions do not have a touch-friendly mode, which is false.
The Win32 versions can be switched between "mouse" and "touch" modes. In touch mode, the pointing targets are all much larger. But as with most user interfaces on modern Windows, even in mouse mode, the Office user interface can be used by touch. Running in mouse mode doesn't remove the helpful pop-up action bar when you've selected text, for example, it just makes the UI elements render more tightly.
For the several years I've used a Surface device with a touch screen, I've never used the UWP versions of the Office applications because they never reached feature parity with the Win32 versions. The UWP versions had a subset of functionality; not the same subset but similar in limitations to the web versions. But that doesn't mean I don't use a touch-friendly application suite—I simply use the Win32 versions in both mouse and touch modes.
I've only seen UWP versions of Microsoft products. Really, it's a way of keeping a foot in both mobile and desktop, when mobile-first has been embraced so widely.
I wonder what the overall adoption rates are for UWP. As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years.
This is exactly what is holding back Win32: there has not been any serious development of the desktop developer story since WPF in 2005 (WPF only received token updates since then, the last major update was in 2010 when they finally added a DataGrid control, lol) - but WPF is not well-suited for many types of software which have to fall-back on “pure” Win32 and the story there is nothing but depressing.
Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers).
Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.
> As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years.
That's the theme behind one of Joel Spolsky's old essays, Fire And Motion:
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."
Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms.
UWP and you’re up shit creek.
Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction.
Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned.
Everything is in a right state despite the marketing to the contrary.
Like everyone else, the biggest difference is that Microsoft keeps the old tech around, while most other companies are willing to loose customers that don't want to move into the new stacks.
On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.
WinForms will out live UWP, WFP and pretty much everything else Microsoft develops in terms of GUI frameworks. It works for the vast majority of programs that businesses need, it's easy to use and so far it's been the best investment in terms of learning a "framework".
If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.
I don't even know how to use UWP. I'm learning Rust and writing some applications using WinAPI is my plan. WinAPI usage seems to be fairly straightforward. But I have no idea how to write UWP application with Rust.
They are suspending the UWP versions. But Office is imho already fairly touch friendly if you turn "touch mode" on, in which all buttons, toolbars and menus become a little bigger. It is not that they don't want touch support (they do, thinking of the Surface family), they just don't want to invest in two parallel version of which one is mature and the other will always be lagging behind. And the customer will probably not see the difference, maybe even get confused.
Ms is my favorite tech company. They, however are their own worst enemy. They produce many awesome but crippled stuff - like honey stained with drops of bird shit.
UWP's appx format is awesome - one click installation, sandbox, clean uninstallation, potential for diff updates. All these have nothing to do with portability.
But they crippled it by making it store only until recently... Too late.
One reason I hate using Edge is because i like chrome and Firefox, it's impossible to install extensions from the browser.
Why can't I use the store through my browser? There's absolutely nothing stopping the store from acting as a downloader and installer in the background.
If the store worked from the browser, usage would pick up.
That is a very specific image that I've never encountered in real life. Is it something that only beekeepers get to witness or is there some bird that homes in on honey pots?
It is also one of my favorite ones, I think the continuous throw away of technology like Singularity, Midori, XNA, Longhorn, UWP,... is the usual outcome of the internal politics between WinDev, DevTools and Marketing divisions.
It was supposed to get better after the reorganization, but apparently it hardly changed.
Since MS is no stranger to regularly building new frameworks, they should build one that is natively supported in Windows, with no compromises relative to other APIs like WPF or Win32, while also supporting macOS, iOS and Android as targets. Some functionality that's not supported in iOS, say, like full multitasking, should degrade gracefully.
Think of it as a hybrid app framework that also is the first-party framework on one OS. No one has done that so far, and it would be interesting to see someone try.
That will give developers a solid incentive to use this API, unlike others like WPF, Silverlight, WinRT, etc. The benefit for MS will be that Windows gets the best possible experience, rather than a least-common denominator one, as with Electron.
Yeah I don't see the need for a fragmentation, as they abandoned Windows RT. IMO, the Win32 Office apps already are very much touch-friendly.
And hey MS, why your OneNote is going a totally different way alone? MS killed Win32 OneNote in Office 2019. I love Win32 OneNote so much as it has more features and more stable.
When I first looked at WinRT app development I thought "how are they going to sell it with these limitations and incompatibilities?" and they did not. UWP was a slightly improved version on WinRT, but it still had some of the same core issues. Luckily, Microsoft has some kind of exit strategy already - I just wonder where that leads.
That all being said: Microsoft should still invest in their desktop stack (especially WPF / .NET for desktop applications in general). Bringing the positive parts from UWP to the established frameworks would be a big win for everyone.
As I understand it UWP is still the official and canonical API. However knowing how many other APIs had such a status it's not saying much.
How does the Xamarin.Forms look between other APIs? It's getting Linux and macOS support. I started to wonder if it will be the next official and canonical API. Or maybe something in the direction of their Electron, as they use it already with their Typescript.
But I don't really know anything about Windows development beyond Win32, so maybe it doesn't make sense at all.
As a 2 in 1 Wundows 10 notebook user (XPS 13) it is obvious that the touch "mode" is completely unfinished. Simple things like not displaying the keyboard when you select a textbox make difficult to choose the tavlet mode except for basic reading.
I think the vision of multi-factor OS is right but the execution doesn't pass a basic UX test.
One of the features I specifically look for in a laptop is "NO TOUCH SCREEN". I really don't understand it. Why would I want touch on a laptop or desktop PC?
Wow, the comments make it seem like this has anything to do with Windows UWP platform. So much misunderstanding here and the OP is even quite a bit misleading.
1) UWP is the branding behind many technologies, but most commonly thought of as the containerization and sandboxed subset of the Win32 API available to the application. This would have been great had it not poorly abstracted a lot of very common I/O APIs. The first version didn't allow normal socket API, you had to use the HTTP or some janky intern's first project streaming socket API.
Another annoyance, none of the file system APIs that had 20 years of software written around worked anymore, instead you had to rewrite on top of a completely different API that was in no way compatible with the previous API set.
Contrast that with Apple's iOS sandbox story, the entire Foundation and Core Foundation library, including all of the expected POSIX (BSD variant) code continued to be available. Developers early in the platform's life could take their previous work and just recompile it for the phone and build a new mobile UI on top of it.
iOS in the very beginning had its fans but also only one or two developers who were eager to convince management they should write software for it. Whereas Microsoft's vision for requiring you to rewrite the majority of your software from the bottom to the top on this container system meant serious up front investment. For a new platform, the chicken and egg problem meant even Microsoft couldn't justify the cost.
2) Over time Microsoft has changed course and re-enabled a lot of the Win32 restrictions they engineered in place to write containerized applications. It's still not 100% there and I think they probably gave up trying to make it work. Instead they decided just to allow Win32 software in its entirety to run on the sandbox through another marketing platform, "Desktop Bridge." This brought a flood of 3rd party apps to the Microsoft Store since it was finally easy to port software over.
It's definitely not the same though, because UI (xaml) is still locked behind the container system. Yet all the work the Windows UI team is investing in is in this new container XAML UI. It's a nice UI surface, because you get a lot for free now, High-DPI and scaling just works and animations that don't look like garbage.
Unfortunately you cannot have both. You cannot have the newest UI framework and continue to have access to the entire platform API in a sandbox. Microsoft enabled a bunch of super hacks to try to allow you to write containerized UI but it's not straightforward and you're better off picking one platform or the other.
..
So thiiiiis is where I see the demise of Mobile Office. Desktop Bridge will allow Win32 Office to continue to work on all tablets and desktops. Even the ARM variant will run them, and Win32 Office already has an ARM port, so it's not likely that will change. They won't get access to the containerized UI, but Office has always been its on custom UI beast. So I doubt they need to suffer the limitations of the containerized API subset, get full access in the Win32 API and unify the teams.
It makes perfect sense to me and if I were the PMs in charge of this, I would have done this a while ago.
[+] [-] 013a|7 years ago|reply
Moreover, they have (had?) an entire multi-year roadmap planned around UWP, including the eventual release of a version of windows which was supposed to substantially reduce day-to-day reliance on Win32 for lower powered devices, codenamed Project Polaris [2], in an attempt to compete with Chromebook-like devices.
This is a massive destruction of confidence in the UWP platform. If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?
[1] https://www.theverge.com/2018/4/18/17252312/microsoft-office...
[2] https://www.windowscentral.com/understanding-windows-core-os...
[+] [-] maxxxxx|7 years ago|reply
That's why I avoid any kind of Windows desktop development. They release a new framework every 2-3 years and developers are expected to adopt it. But then they drop support for that framework quickly and release a new incompatible one.
In the Windows environment choice is bad. You only have bad choices and the frameworks that are being used for flagship apps like Office are not available to devs.
I really envy iOS devs where the path to an app is straightforward and your biggest problem is to use ObjectivC or Swift.
[+] [-] intern4tional|7 years ago|reply
I don't know if you've ever had to debug a UWP app but compared to almost anything else it's painful. Exceptions don't propagate properly, and finding errors takes a ton of time. Development is likewise painful with elements of random things being required and the packaging and publishing process a nightmare compared to competitors.
UWP was made for phone and Microsoft then ported it to Core OS, but as a format it is not developer friendly. If you look at new Microsoft under Satya - and their goal of being developer friendly, this move makes sense. I wouldn't be surprised to see UWP and the current store deprecated entirely (as they are honestly failures).
[+] [-] cptskippy|7 years ago|reply
It makes more sense to gradually rewrite portions of it but that doesn't work well with the annual release model. It does however work with the O365 continuous release model they adapted from Windows 10.
Just as they're gradually porting Control Panel and other legacy Win32 apps to the Settings App. I could see them gradually convert Office to modern cross platform frameworks.
[+] [-] ClassyJacket|7 years ago|reply
Endemic at Microsoft. I believe the main reason the Xbox One Kinect - an impressive piece of hardware - failed, is that Microsoft themselves couldn't manage to make one big flagship game for it at launch. If Microsoft themselves are avoiding it, why on earth would third parties invest?
[+] [-] kartickv|7 years ago|reply
[+] [-] tomc1985|7 years ago|reply
[+] [-] chris_wot|7 years ago|reply
[+] [-] bhauer|7 years ago|reply
The Win32 versions can be switched between "mouse" and "touch" modes. In touch mode, the pointing targets are all much larger. But as with most user interfaces on modern Windows, even in mouse mode, the Office user interface can be used by touch. Running in mouse mode doesn't remove the helpful pop-up action bar when you've selected text, for example, it just makes the UI elements render more tightly.
For the several years I've used a Surface device with a touch screen, I've never used the UWP versions of the Office applications because they never reached feature parity with the Win32 versions. The UWP versions had a subset of functionality; not the same subset but similar in limitations to the web versions. But that doesn't mean I don't use a touch-friendly application suite—I simply use the Win32 versions in both mouse and touch modes.
[+] [-] pjmlp|7 years ago|reply
[+] [-] kartickv|7 years ago|reply
Do I have to go around telling each app that supports touch mode to go to touch mode, or is there a way I can configure it centrally?
[+] [-] stephengillie|7 years ago|reply
[+] [-] dang|7 years ago|reply
[+] [-] hfdgiutdryg|7 years ago|reply
[+] [-] DaiPlusPlus|7 years ago|reply
Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers).
Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.
[+] [-] SyneRyder|7 years ago|reply
That's the theme behind one of Joel Spolsky's old essays, Fire And Motion:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."
[+] [-] setquk|7 years ago|reply
Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms.
UWP and you’re up shit creek.
Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction.
Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned.
Everything is in a right state despite the marketing to the contrary.
[+] [-] pjmlp|7 years ago|reply
On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.
[+] [-] mrweasel|7 years ago|reply
If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.
[+] [-] threeseed|7 years ago|reply
Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
[+] [-] vbezhenar|7 years ago|reply
[+] [-] sebazzz|7 years ago|reply
[+] [-] vezycash|7 years ago|reply
UWP's appx format is awesome - one click installation, sandbox, clean uninstallation, potential for diff updates. All these have nothing to do with portability.
But they crippled it by making it store only until recently... Too late.
One reason I hate using Edge is because i like chrome and Firefox, it's impossible to install extensions from the browser.
Why can't I use the store through my browser? There's absolutely nothing stopping the store from acting as a downloader and installer in the background.
If the store worked from the browser, usage would pick up.
[+] [-] harryf|7 years ago|reply
That is a very specific image that I've never encountered in real life. Is it something that only beekeepers get to witness or is there some bird that homes in on honey pots?
[+] [-] pjmlp|7 years ago|reply
It was supposed to get better after the reorganization, but apparently it hardly changed.
[+] [-] kartickv|7 years ago|reply
Think of it as a hybrid app framework that also is the first-party framework on one OS. No one has done that so far, and it would be interesting to see someone try.
That will give developers a solid incentive to use this API, unlike others like WPF, Silverlight, WinRT, etc. The benefit for MS will be that Windows gets the best possible experience, rather than a least-common denominator one, as with Electron.
[+] [-] kbumsik|7 years ago|reply
And hey MS, why your OneNote is going a totally different way alone? MS killed Win32 OneNote in Office 2019. I love Win32 OneNote so much as it has more features and more stable.
[+] [-] snaky|7 years ago|reply
[+] [-] FlorianRappl|7 years ago|reply
That all being said: Microsoft should still invest in their desktop stack (especially WPF / .NET for desktop applications in general). Bringing the positive parts from UWP to the established frameworks would be a big win for everyone.
[+] [-] rpeden|7 years ago|reply
I'm looking forward to using UWP components in WPF apps, though I imagine that'll only work on Windows 10.
[+] [-] hawski|7 years ago|reply
How does the Xamarin.Forms look between other APIs? It's getting Linux and macOS support. I started to wonder if it will be the next official and canonical API. Or maybe something in the direction of their Electron, as they use it already with their Typescript.
But I don't really know anything about Windows development beyond Win32, so maybe it doesn't make sense at all.
[+] [-] wslh|7 years ago|reply
I think the vision of multi-factor OS is right but the execution doesn't pass a basic UX test.
[+] [-] pawelmurias|7 years ago|reply
[+] [-] mrweasel|7 years ago|reply
[+] [-] kgwxd|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] kyberias|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
[+] [-] walterbell|7 years ago|reply
[+] [-] jarjoura|7 years ago|reply
1) UWP is the branding behind many technologies, but most commonly thought of as the containerization and sandboxed subset of the Win32 API available to the application. This would have been great had it not poorly abstracted a lot of very common I/O APIs. The first version didn't allow normal socket API, you had to use the HTTP or some janky intern's first project streaming socket API.
Another annoyance, none of the file system APIs that had 20 years of software written around worked anymore, instead you had to rewrite on top of a completely different API that was in no way compatible with the previous API set.
Contrast that with Apple's iOS sandbox story, the entire Foundation and Core Foundation library, including all of the expected POSIX (BSD variant) code continued to be available. Developers early in the platform's life could take their previous work and just recompile it for the phone and build a new mobile UI on top of it.
iOS in the very beginning had its fans but also only one or two developers who were eager to convince management they should write software for it. Whereas Microsoft's vision for requiring you to rewrite the majority of your software from the bottom to the top on this container system meant serious up front investment. For a new platform, the chicken and egg problem meant even Microsoft couldn't justify the cost.
2) Over time Microsoft has changed course and re-enabled a lot of the Win32 restrictions they engineered in place to write containerized applications. It's still not 100% there and I think they probably gave up trying to make it work. Instead they decided just to allow Win32 software in its entirety to run on the sandbox through another marketing platform, "Desktop Bridge." This brought a flood of 3rd party apps to the Microsoft Store since it was finally easy to port software over.
It's definitely not the same though, because UI (xaml) is still locked behind the container system. Yet all the work the Windows UI team is investing in is in this new container XAML UI. It's a nice UI surface, because you get a lot for free now, High-DPI and scaling just works and animations that don't look like garbage.
Unfortunately you cannot have both. You cannot have the newest UI framework and continue to have access to the entire platform API in a sandbox. Microsoft enabled a bunch of super hacks to try to allow you to write containerized UI but it's not straightforward and you're better off picking one platform or the other.
..
So thiiiiis is where I see the demise of Mobile Office. Desktop Bridge will allow Win32 Office to continue to work on all tablets and desktops. Even the ARM variant will run them, and Win32 Office already has an ARM port, so it's not likely that will change. They won't get access to the containerized UI, but Office has always been its on custom UI beast. So I doubt they need to suffer the limitations of the containerized API subset, get full access in the Win32 API and unify the teams.
It makes perfect sense to me and if I were the PMs in charge of this, I would have done this a while ago.