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

  • Hands On: New VS Code Insiders Build Creates Web Page from Image in Seconds

    New Vision support with GitHub Copilot in the latest Visual Studio Code Insiders build takes a user-supplied mockup image and creates a web page from it in seconds, handling all the HTML and CSS.

  • Naive Bayes Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the naive Bayes regression technique, where the goal is to predict a single numeric value. Compared to other machine learning regression techniques, naive Bayes regression is usually less accurate, but is simple, easy to implement and customize, works on both large and small datasets, is highly interpretable, and doesn't require tuning any hyperparameters.

  • VS Code Copilot Previews New GPT-4o AI Code Completion Model

    The 4o upgrade includes additional training on more than 275,000 high-quality public repositories in over 30 popular programming languages, said Microsoft-owned GitHub, which created the original "AI pair programmer" years ago.

  • Microsoft's Rust Embrace Continues with Azure SDK Beta

    "Rust's strong type system and ownership model help prevent common programming errors such as null pointer dereferencing and buffer overflows, leading to more secure and stable code."

  • Xcode IDE from Microsoft Archrival Apple Gets Copilot AI

    Just after expanding the reach of its Copilot AI coding assistant to the open-source Eclipse IDE, Microsoft showcased how it's going even further, providing details about a preview version for the Xcode IDE from archrival Apple.

Subscribe on YouTube

Upcoming Training Events