Contracts, Where Windows 8 Gets It Right

I've mentioned before that Windows 8 Metro is going to be a very disruptive UI switch for most Windows users to make and is likely going to cause some headaches for Microsoft due to customer backlash. The timing is off, though Microsoft is making an effort to get the word out early and work to make the interface as knowable as possible well in advance. Only time will tell if they succeed well enough to avoid the complaints. That said, I should make something clear... I don't oppose or even really dislike the Metro concept. The most visible change in Metro, and the one that I think is most likely to draw the ire of those who complain, is that of essentially devoting the entire screen to a single application at a time, a concept most mobile device users are already very familiar with. It's only on the desktop where this paradigm becomes less common. In any event, one interesting concept in Windows 8 that I like in particular is the concept of "contracts".

In Windows 8, an application can expose features through a contract. The contract details what the offered feature needs to work and what it will produce. Think of it like the input/output paradigm in Apple's Automator but able to be tapped into by any application on the system, not just through a single central authority like Automator. More importantly, these features can be tapped into seamlessly, the user never having to leave the current application but still being able to tap into the full functionality present on their device. In the Metro interface, where only one application has the screen at a time, this will be a boon to developers and users alike, working to increase the usefulness in situations where one app owning the screen at a time is necessary.

Move Over Bacon, There's Something Better ( in Windows 8 )

Sharing features between apps is of course something that's been around for awhile. Even the earliest operating systems allowed applications to talk to one another by opening connections between apps and sending data cross. Over time, protocols were established to be able to send higher level data across instead of having to reconstruct data manually on the receiving end. By the early 90's, Microsoft released their OLE (Object Linking and Embedding) technology, allowing the sharing of complex features between various applications. This required considerable effort to do well, though. OLE is not the only such technology though. There are many to choose from. But it seems as though the focus here is more on how it will affect the end user and less on how to integrate apps. It may seem like one and the same, but the focus drives the implementation. Here, Microsoft got the focus right.

Absent on the list of IPC protocols is OpenDoc. OpenDoc was a consortium created in the 90's after OLE became popular and gave Microsoft a big advantage with Office. It tried to unite a number of vendors to create a standard that would rival OLE's capabilities and allow them to offer a comparable feature set without having to bend to Microsoft's will. Microsoft began using their OS dominance to full advantage by requiring certain compliance criteria for OS verification of an app that resulted in practically requiring use of OLE as opposed to OpenDoc. After awhile, OpenDoc went away. Why mention a dead protocol? Because Apple was a major driver behind OpenDoc and didn't seem to learn much from it.

We see some of what Apple came away with in Services on OS X, Apple events, and a few other supported features. Automator touches on this concept of feature sharing though it's really just a workflow tool. We don't see any sort of attempt by Apple to nail down a standard method of allowing one app to provide full featured functionality to another app to be called out at will. As I said, Services touch on this concept, but not to the extent that OLE or Windows 8 Contracts provides. And that's the shocker. Heck, iOS lacks even these more basic elements, allowing only the registration of a URL type and the ability to send a simple string to that URL as the only means of sending a message to another app. And that ends up causing a full context switch, pushing the user out of whatever app they were in, and doesn't provide any means of dynamically finding feature availability. Apple should have learned more here. I imagine they're listening though.

On the desktop, I don't see this as as huge a deal as it will be in mobile. As far as I know, no mobile devices currently have this level of integration between apps and if it ends up working nearly as well as the hands on demos indicate, it's going to be a nice feather in Microsoft's cap.


Windows 8 Metro Interface, The Wrong New Thing

Microsoft has been revealing more and more features about Windows 8, including the new Metro interface shown above. That is what the standard desktop interface is going to look like in Windows 8. You'll be able to click a 'Desktop' link to interact with older legacy applications (i.e. anything developed for Windows 7 or earlier) but clicking on the 'Start' menu is going to land you back in this tiled world. Microsoft is trying to add a breath of fresh air to their interface but I think they've simply introduced the wrong new thing.

Direction of Change

Introducing change to your UI is never a decision made lightly. Companies enter legal fights over 'look and feel' to make sure they have a unique design, something easily recognizable to anyone sitting down to use their product. Microsoft no doubt is hoping to make their UI memorable but I'm sure is nervous about how it will be received. In fact, they were so nervous about the upcoming changes to Windows Explorer in Windows 8 that they posted a blog entry about it. In it, they didn't just go into detail about the changes, they discussed the entire history of the interface, the commands most often used, and then ended with an attempt to convince us why we needed the new ribbon UI on a file and folder browser. Microsoft is anxiously trying to get the word out now before the product's release, likely to avoid any user backlash over getting used to the new way of doing things.

Part of their problem, though, is that they are introducing change in a way that most folks don't appreciate. Windows 8's Metro interface is essentially the Windows Phone 7 UI writ large. The problem is Windows Phone 7 hasn't been in use long enough nor by enough people for the interface to feel more at home to more people. In fact, Microsoft just recently announced plans to increase sales personnel to push additional sales. And now, before the public has really had a chance to become used to this new tiled way of doing things, they are attempting to push it into the new Windows 8 deployment.

At first blush, it would seem to be an attempt to steal a page from Apple's playbook. Recall Steve Jobs' "Back to the Mac" theme, where they discussed introducing iOS UI elements into OS X Lion? And in fact Launchpad is pretty much an iOS home screen with all of your apps and no groups. The difference is in the timing. Apple let the iOS experience percolate on iPhone, iPod Touch and then iPad before deciding to bring any elements back into the desktop. And even then, they didn't make a radical departure. Perhaps bigger changes are coming. In fact, I'm certain of it. But Apple made the right move by easing folks into the iOS way of doing things first before introducing similar changes to an interface OS X users are very familiar with. In any event, the Windows 8 Metro interface is going to receive some pretty critical pushback from their userbase.