Touch friendly desktop apps

[anon(5969054)]

Why doesn't Microsoft encourage developers of the old style desktop applications to make a different UI that is touch friendly and adaptive and allow them in the Windows store? Those are billions of apps. Just not touch friendly.
With a relative small amount of work a developer could make it touch friendly.
There are billions of potential desktop apps out there. Then, simplify the installation process and it will be the same experience as other apps for people. Yes they wont run on tablets and phones, but in a few years they will when we have good Intel mobile processors. Why would Microsoft use something else then? Why they throw away 20 years of ecosystem? All they need is touch optimization.

Or am I overseeing something?

 

[Kevin Rush]

Should be possible. Years and years ago, AutoCAD, a PC program, was able to be used with a mouse or a digitizer. First with a digitizer and DOS then later with a digitizer and/or mouse with Windows OS. The digitizer was a separate device from the monitor screens back then. Moving the stylus on the solid opaque digitizer tablet, moved the curser on the monitor screen. Sound familiar? Similar?

 

[anon(5969054)]

But why is nothing done with this?

 

[TheLumaniac]

Why doesn't Microsoft encourage developers of the old style desktop applications to make a different UI that is touch friendly and adaptive and allow them in the Windows store? Those are billions of apps. Just not touch friendly.
With a relative small amount of work a developer could make it touch friendly.
There are billions of potential desktop apps out there. Then, simplify the installation process and it will be the same experience as other apps for people. Yes they wont run on tablets and phones, but in a few years they will when we have good Intel mobile processors. Why would Microsoft use something else then? Why they throw away 20 years of ecosystem? All they need is touch optimization.

Or am I overseeing something?

Yes, it would nice to see that. Making your program from scratch would be really time consuming, but providing a touch-mode (a different UI, suitable for touch input) wouldn't be that hard.
Although, I'd rather have Windows Apps: Better UI, easier to update, easier to give feedback, etc.

 

[Mike Gibson]

There are a couple of issues with your idea:

1. Desktop programs are generally more complex than an "app". They have many configuration dialogs and settings. For touch support, you need controls that are *much* larger than those in a typical Desktop program. That means less information on a screen or some sort of scrolling mechanism.

2. Desktop programs are typically "information dense". They have lots of information on the screen at one time. Look at the ribbons in Office and other Desktop programs. You also see pop up tip windows over UI elements, which obviously won't work with touch since there is no "hover" detection for a fingertip.

3. The mouse is a precision pointing device. I can click on a specific pixel in my Win32 programs if I want. A fingertip is much larger, so you have to do nearest detection to figure out what the user is trying to select if you have multiple small items on the screen.

4. The final nail is that Desktop programs are typically for productivity, which means items #1-3 above are critical to their usefulness.

Note that touch works fine in Desktop programs since at least Win7 (on a touchscreen or a trackpad). Without changing any code my Win32 programs get useful input from touch. I don't handle the touch messages in my window procs, so the messages go on to User32 and get translated into mouse messages which my programs handle. You can pinch to zoom which get translated into mousewheel messages, tap to select which gets translated into mouse button messages, double-tap for action, etc. (I forgot which touch gesture equates to right-click). It's not as good as full touch support but it works.

What I'm doing in my most tablet-friendly Win32 program is to add a "tablet" mode so that it will work better on Intel-based Windows tablets. That will take the main window fullscreen and enable taps on critical UI items that bring up widely spaced dialog items. All configuration dialogs will remain Desktop-oriented with dense controls. The idea is that users can do all the complex configuration at home on a decent monitor with mouse/keyboard and then, when in the field in real-time, they can switch to tablet mode.

MSFT cut their own throats by making the WinRT framework incompatible with Win7. There's no way I could spend the dev time to convert my Win32 programs to the WinRT framework because there were no users/no demand. All they had to do was solve the problems in the existing Win32 API. The good things about WinRT: curated Store, easy install/uninstall, scalable UI, Direct3D, better security. The overwhelming cons: crippled core WinRT API, overly restrictive file/directory access, significant fragmentation between WinRT80 and WinPRT80, obsession with Async, poor performance, inevitable bugs for a 1.0 API, no Win7 compatibility.

None of the good things I listed were impossible to implement on Win7. All they needed was to define a secure subset of Win32, a scalable UI API/framework, and a well-defined program binary system for easy install/uninstall. That could have been provided in a Windows Update or Platform Update for Win7. They could have said "works on Win7, works better on Win8".