The 8 components of the future desktop

A few years ago I wrote an article that explained the difference between "The Desktop" (Big D) and a "desktop" (Little D). This article is an update to that as I now have a more nuanced view of what the future desktop will look like.

A few years ago I wrote an article that explained the difference between "The Desktop" (Big D) and a "desktop" (Little D). This article is an update to that as I now have a more nuanced view of what the future desktop will look like.

To quickly review, I suggested that historically speaking, the "Desktop" has been a single monolithic brick that we call Microsoft Windows. Even though we've gotten good at managing, building, slicing, and delivering that brick, at the end of the day, it's still Windows. I suggested that the future "desktop" will not be a single monolithic brick, but instead a dynamically-created instantiation of user settings, apps, and data constructed in an appropriate way for whatever device the user happened to be using.

The example of why this is important is captured in the following image (which is by now familiar to readers of this site):


Even if you believe that tablets will rule the future, this is clearly not what the desktop of the future will look like.

So in order to understand the desktop of the future, we have to understand what a desktop actually is. Traditionally, of course, a desktop was this monolithic brick:

Windows desktop

But if you break this desktop up into its core parts, what is it really? (And I'm not talking about layering in this case, since layering is a concept that only applies to Windows desktops. After all, once you reassemble the layers, you still end up with a Windows desktop.)

The 8 components that really make up the desktop

If we dig into what a desktop actually is or does, we can see that there are eight components that come together to create the picture above. Looking at them one-by-one:

1. The device's hardware interface

At the most basic level, the desktop provides the interface that connects applications, data, and user interface to the process, memory, peripherals, and storage. So we can say that acting as the device's hardware interface is one role of the desktop.

2. The user interface

The desktop is also the user interface, including graphics, buttons, windows, menus. This also includes the system for users to interact with it, whether it's keyboard, mouse, touch, acceleration, or orientation.

3. The application runtime

The desktop provides a runtime environment that applications can leverage to do what they do. For example, Windows EXEs can run because the Windows desktop has the kernel, APIs, and everything else that EXE needs to do something useful.

4. An app launcher

The desktop provides a way for users to view and launch available applications. In Windows, this is via the Start Menu or via shortcuts on the desktop.

5. A provisioning target

The desktop is a target we use to deliver applications to users. In Windows, when we want a user to have an application, we deliver a shortcut to their desktop, or we install or stream that application to their desktop.

6. Provider of application integration

The desktop allows different applications to interact with each other. At the most basic level, this is cutting and pasting between apps. But it could also be things like OLE integration and drag-and-drop.

7. A security container

A user logs into a desktop, and from there everything he or she does uses the credentials and tokens of the original logon. So in Windows, the users logs in, and then everything they access—files, programs, network resources—are accessed in their context.

8. A configuration container

The desktop holds the overall configuration of a user's environment. This includes things like spelling dictionaries, regional settings, fonts, and other preferences.

What does this desktop look like?

As mentioned previously, for the past twenty years or so, all eight of these components of the desktop were combined together into Microsoft Windows—it was all or nothing. We couldn't deliver just some of these components without delivering others (which is how we end up with that funny image of the Windows desktop on mobile devices).

But if you think about our definition of the desktop being made up of those eight different components, you can imagine that those same eight components can combine into a form other than the Microsoft Windows desktop. For example, each of these "desktops" has those same eight components in one form or another:

All these are desktops

Breaking up the monolithic brick

Of course each of the above "alternate" desktops are each still monolithic bricks in their own right (even though they're different than Windows-based bricks). But does it have to be that way? Based on the technologies that we have today, can we start to break up those eight desktop components? And if so, can we deliver a more appropriate desktop to different types of client devices?

In order to do that, we have to look at the client devices and the applications and start to think about which of the eight components we should deliver from where. After all, if a client device already has an app launcher (#4), then us "painting over" the phone's app launcher with our remote Windows desktop app launcher is a huge #fail. (To launch an app with the iPhone's app launcher, you just swipe to the page and touch the icon. But launching an app with a Windows desktop app launcher delivered to an iPhone means you have to pan down to the start menu, zoom way in, push Start, pan up the menu, push Programs, pan over to the app you want, push it, zoom out to the app).

The same could be said for other components of the desktop, like the app integration (#6), the user interface (#2), and the device's hardware interface (#1).

So if we want to deliver a good desktop experience to a device, rather than forcing our remote desktop and all eight of its components onto a client device, we want to use components 1, 2, 4, and 6 from the local device and deliver the rest remotely.

And we can break it down even further. One could argue that the security container (#7), provisioning target (#5), and configuration container (#8) are all user-specific settings that don't need to be tied to a device at all. For security and provisioning, I really just care about which users have access to which apps. It doesn't matter so much that a user has access from one specific device or another. The same is true for user configuration. A user's mail server is the same regardless of whether they're using a laptop, phone, or iPad. And the user preferences like spelling, regional settings, and timezones are also the same no matter what device the user is using.

That just leaves Component #3—the app runtime—as the only thing that we can't really control via the "desktop." And this makes sense, because when it comes to what runtime an app needs, it is what it is. In other words, if we have a Windows app that we need to deliver to our users, then we have no choice but for it to run on a Windows OS. But if we want to deliver that Windows app to an iPad, rather than delivering all eight desktop components remotely (and covering up the eight local components of the iPad), we can deliver just the app (perhaps with XenApp, RemoteApp, or Framehawk) and let the other components of the iOS desktop (app integration, app launcher, UI, etc.) shine through.

Desktop parts

The point of this story is to get you to think about the desktop as something more than a single monolithic Microsoft Windows-based brick. While the components of today's desktop are the same as that old brick, we have the technology to pick-and-choose which components we get from where. And doing so will deliver a better user experience than just falling back on our old way of painting over everything with our remote desktop.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Brilliant post Brian, I love conversations that take a close look at what a desktop really is and then break it up into its components.

This is a first step towards really understanding how we can fix some of the inherent weaknesses of the traditional desktop OS and start thinking about improving upon it.

There is a huge security conversation that also surrounds this post I think, most of the malware and threats that affect us directly target some of the key components you mention above and its not until we begin the alter these components that we can really become effective at fighting security threats.

A good example of this is Bromium, they do something completely different within a desktop OS in order to secure it and it is this kind of thinking that your post provokes Brian.

Good work that man, more please.



I think that a lot of this is overly simplified. Session management i.e. the ability for apps to interact with each other requires an O/S. I think if people had a deeper appreciation for what an O/S actually does and the services in offers to app developers they'd realize that the future desktop will require us to do many of things the one today does....

I don't disagree that new form factors won't give rise to new single purpose self contained apps, but IMO it's a huge mistake to assume that will replace the current desktop. It won't unless our lives are single function apps only.

What I suspect we'll end up as history as taught us many times is more $h1t to deal with. That means that the future is going to require a rethink a of the management stack that needs to deal with all this crap. We're starting to see this with MDM/MAM type solutions, but they are in addition to no a replacement for any time soon! And yes I agree remotes to iPads etc is junk, wrong use case. However let's not assume they won't have a place moving forward to solve the right use cases along side laptops, PCs and new form factors.


Good post. I also agree it would be nice to have the other iOS components or apps shine through instead of painting over ... The reality is Apple puts a lot of constraints in the equation , now and going forward. Providing seamless app integration will be key.

For another point of view looking at users activities driving the desktop of the future