
Microsoft suspends development of touch-friendly UWP Office apps for Windows - extarial
https://arstechnica.com/gadgets/2018/09/microsoft-suspends-development-of-touch-friendly-office-apps-for-windows/
======
013a
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?

[1] [https://www.theverge.com/2018/4/18/17252312/microsoft-
office...](https://www.theverge.com/2018/4/18/17252312/microsoft-
office-2019-onenote-windows-10-app)

[2] [https://www.windowscentral.com/understanding-windows-core-
os...](https://www.windowscentral.com/understanding-windows-core-os-and-
polaris)

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

~~~
Const-me
> 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.

Doesn't matter, as a developer you're free to pick whichever you like. You can
run VB6 apps on Windows 10. A software I've made on my first job with MFC for
NT4.0 still runs on Win10. WPF is awesome, I still pick it now in 2018 when I
need compatibility with older Windows.

~~~
tonyedgecombe
You can but it would be better for developers if you could rely on a framework
being developed rather than frozen in time. I'm pretty sure there are no
classes supporting touch in MFC.

~~~
Const-me
> I'm pretty sure there are no classes supporting touch in MFC.

[https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-
clas...](https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-
class?view=vs-2017#registertouchwindow)

~~~
tonyedgecombe
Thanks, I was clearly wrong on that point.

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

~~~
pjmlp
Just as additional information, Win32 touch APIs were introduced in Windows 7,
and are part of the Hilo C++ sample application.

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

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

~~~
pjc50
> The story is so bad Microsoft’s own flagship software has to build their own
> UI frameworks

I think this might be the other way round: if they're not eating their own
dogfood, it's much easier for the UI framework to come adrift from actual use
cases.

It's really telling that in Windows 8/10 they "modernised" _some_ , but not
all, of the control panel UI. It's basically random as to whether a setting
you need will be in a Metro-flavoured window or a Win32-flavoured one.

To me, the trouble with everything after WinForms is that it lacks a really
compelling reason to upgrade. It's not easier to develop for and it's not
nicer to use, and on many desktop systems the font rendering is much uglier in
the new system. It does perform better at high DPI, but (catch-22) few people
use high DPI windows systems because it's not well supported by even the OS
let alone the applications.

~~~
maxxxxx
"It's really telling that in Windows 8/10 they "modernised" some, but not all,
of the control panel UI. It's basically random as to whether a setting you
need will be in a Metro-flavoured window or a Win32-flavoured one."

That's really infuriating. Makes me wonder what all these devs they have are
doing the whole day.

"To me, the trouble with everything after WinForms is that it lacks a really
compelling reason to upgrade. It's not easier to develop for and it's not
nicer to use, and on many desktop systems the font rendering is much uglier in
the new system. It does perform better at high DPI, but (catch-22) few people
use high DPI windows systems because it's not well supported by even the OS
let alone the applications. "

WPF had great potential and I think they could have made it a wonderful
environment if they had kept improving it. Clean up XAML syntax (maybe
something like they with ASP.NET and Razor) , simplify data binding syntax and
debugging, make MVVM first class citizen and it would be great. Instead they
(almost) stopped development of WPF and cranked out a series of half baked
successors like WinRT, Silverlight and UWP.

~~~
dep_b
WPF was really nice from what I remember of it. MVVM was super easily
integrated with XAML.

~~~
tonyedgecombe
MVVM is great if you want to unit test all your UI code but who wants to do
that.

For me the whole thing was cumbersome and nowhere near as productive as
WinForms. Not only that but problems it purported to solve like high-dpi
support still had issues.

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

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

~~~
harryf
> like honey stained with drops of bird shit.

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?

~~~
DCoder
FWIW, here in Eastern Europe we have a similar saying that _" A spoonful of
tar ruins a whole cask of honey"_ .

~~~
andyonthewings
We also have something similar in Chinese (Cantonese only?) - one bit of mouse
shit ruins the whole pot of congee (一粒老鼠屎，壞了一鍋粥).

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

~~~
snaky
That's top2 issue on uservoice
[https://onenote.uservoice.com/forums/327186-onenote-for-
wind...](https://onenote.uservoice.com/forums/327186-onenote-for-
windows/filters/top)

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

~~~
rpeden
It's nice that they're at least bringing WinForms and WPF to .NET Core.

I'm looking forward to using UWP components in WPF apps, though I imagine
that'll only work on Windows 10.

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

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

------
pawelmurias
Touch centered desktop uis need to die

~~~
mrweasel
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?

~~~
cesarb
Story time. At a previous company, we had an annoying crash bug - it crashed
on some of the client's computers, but never on any of ours. Finally the
client lent us the personal laptop of one of their workers, which reliably
reproduced the crash, and we debugged it while sitting on one of the client's
meeting rooms and found the cause. It was a crash deep in the obsolete
framework we were using, which manifested when receiving a particular kind of
accessibility message, which came from one of the components for Microsoft's
touch screen system.

The reason we could never reproduce the crash before was that, being techies,
none of us had any modern laptop, personal or not, with a touch screen. The
client, being less technical, had some of their workers with touch screen
laptops and the then-recent touch-focused version of Windows (which we also
tended to avoid).

~~~
discreditable
This reminds me of an ongoing issue with our org's website. The devs are using
an ancient jquery for an image gallery widget. The gallery doesn't respond to
mouse clicks on any of our PCs because that jquery version sees touch support
and expects you to use only that. All of our devices have touch screens.

------
kgwxd
Touch input is perfect for consuming, horrible for creating.

------
kyberias
The first Excel was packaged with Windows because install-base of Windows
wasn't large enough. Maybe they should integrate UWP in Office?

~~~
pjmlp
Most UWP improvements coming up in FluentUI were originally developed by the
Office team, as shown on Build 2018, so this decision is kind of weird.

------
walterbell
What will happen to Win32 when Windows 7 stops being security supported in 15
months?

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

