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.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

No trackbacks yet.