Redmond Review

Making Windows 10 Continuum Mode Work for Developers

Continuum mode takes developers to the next evolutionary step, but Microsoft has to offer developers a more universal approach to developing Windows 10 apps for the various devices and form factors.

On Sept. 30, Microsoft introduced Windows 10 to the world. It confirmed what many of us had expected: The Start menu is back, this time with smart tiles, and modern apps can run windowed. The Windows desktop, rather than being a deprecated legacy UI that's only begrudgingly supported (as it was in Windows 8), is instead the center of gravity of stationary and laptop PCs running Windows 10. In fact, a new virtual desktops feature that enhances the conventional Windows UI, rather than just perpetuating it, has been added in Windows 10, as well.

But beyond the Start menu, windowed apps and virtual desktops, Microsoft provided a video-based demo of something called "Continuum mode," in which convertible/2-in-1 devices alert Windows when they've switched between their undocked, tablet states and their keyboard and mouse/touchpad modes. Windows responds by asking if it, too, should switch modes, and then automatically employs a desktop-oriented UI or full-screen modern one, as appropriate.

Continuum mode is not in the new Technical Preview release of Windows 10. That's too bad, as I'd like to get my hands on it, literally and figuratively. But I'm excited, nonetheless. Because back in February 2011, seven months before even the earliest version of Windows 8 was revealed publicly, I wrote a thought piece for this column where I suggested Microsoft should change Windows to work in much the same way that Continuum mode does.

Not surprisingly, I see Continuum mode as a positive development for users. But what about developers? Running a modern app in a window doesn't make it a true desktop app, so developers who want to cover desktop and touch users still have a lot of extra work, wrangling separate APIs (Win32 and WinRT) for the two types of apps. While .NET and XAML thankfully mitigate differences between the two environments, things are still rather disjointed, to say the least.

The Universe Is Expanding
With Windows 8.1, Microsoft gave us "Universal" apps to enable a single code base between tablet and phone apps. But until desktop apps can be similarly targeted, calling these apps "Universal" is rather misleading. Microsoft needs to extend Win32 to produce modern apps, or extend WinRT to produce apps that are keyboard-and-mouse-appropriate. Maybe this new type of app could be called "Ultra Universal."

Ultra Universal apps in their desktop modes needn't use old-school battleship gray windows, but they would need to be optimized for mouse and keyboard, in terms of size of the controls, and the distance between them. Hot keys and default keys (like Enter and Esc) should work, and so should tabbing between controls, especially in line of business/forms over data apps.

Office 2013 provides an example of this behavior, with its ability to toggle between mouse and touch modes. But while Office 2013 shows how Win32 could implement Ultra Universal apps, the input mode morphing would need to be much deeper. To implement that deeper personality shifting of apps, WinRT would be the more likely API of choice for Ultra Universal apps, as long as it could appropriate the types of controls and behaviors that Win32 apps have now.

Laterally Mobile
Talking about this kind of sliding scale application experience isn't just an "inside baseball" discussion. It cuts to something of crucial importance to developers: portability of code, transferability of skills and access to an installed base. It's important for Microsoft, too, because a great way to build market share and ecosystem momentum in tablets would be to bring desktop app users and desktop app developers over to the modern platform. But that's a pipe dream right now, because developers don't share in the spoils.

How can Microsoft make the story better? Give developers choice, and make that choice more seamless. Let developers code an app for the desktop, and extend it to tablet mode later. Similarly, let "app" developers target touch devices first, and add desktop capabilities later. Right now, app developers don't get access to mainstream Windows users. Those users -- if they're using Windows 8.x at all -- are booting straight to the desktop, bypassing the Start screen and therefore bypassing Windows Store apps. While Modern apps can run on conventional PCs, in reality, they very rarely do.

If app developers could build desktop-friendly apps with only incremental effort, then doing so might be compelling to them. And if that happened, maybe the Windows tablet market share would get significant enough that desktop developers (including corporate developers) would find interest in touch mode.

If both of those pistons were firing, then Microsoft and its developers could have the virtuous cycle on which Redmond has been banking. Microsoft could have a game plan that was a matter of common sense, rather than a matter of faith. And Windows developers could be motivated by real opportunity, rather than the nebulous promise of better things to come.

About the Author

Andrew Brust is Research Director for Big Data and Analytics at Gigaom Research. Andrew is co-author of "Programming Microsoft SQL Server 2012" (Microsoft Press); an advisor to NYTECH, the New York Technology Council; co-moderator of Big On Data - New York's Data Intelligence Meetup; serves as Microsoft Regional Director and MVP; and is conference co-chair of Visual Studio Live!

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube