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


  • Purple Blue Nebula Graphic

    How to Compute Disorder for Machine Learning Decision Trees Using C#

    Using a decision tree classifier from a machine learning library is often awkward because it usually must be customized and library decision trees have many complex supporting functions, says resident data scientist Dr. James McCaffrey, so when he needs a decision tree classifier, he always creates one from scratch. Here's how.

  • Blazor's Future: gRPC Is Key

    Blazor guru Steve Sanderson detailed what Microsoft is thinking about the future of the revolutionary project that enables .NET-based web development using C# instead of JavaScript, explaining how gRPC is key, along with a new way of testing and a scheme for installable desktop apps.

  • Don't Do It All Yourself: Exploiting gRPC Well Known Types in .NET Core

    If you're creating business services that send dates and decimal data then you may be concerned that gRPC services don't support the relevant data types. Don't Panic! There are solutions. Here's how to use them.

  • Sign

    Microsoft Points Blazor to Native Mobile Apps

    Blazor, the red-hot Microsoft project that lets .NET developers use C# for web development instead of JavaScript, is now being pointed toward the mobile realm, targeting native iOS and Android apps.

  • Circl

    Implementing State in .NET Core gRPC Messages with oneof

    In the real world, you've been dealing with the State pattern every time you designed a set of database tables. The Protocol Buffers specification lets you do the same thing when you define the messages you send and receive from your gRPC Web Service.

.NET Insight

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.

Upcoming Events