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:
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:
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.
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.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.