I always get a kick out of reading about Longhorn-era technology that never saw the light of day, only to be implemented years later. Days ago, a couple of then-Microsoft designers working on what was Windows Codename “Longhorn” at the time were granted a patent they filed all the way back in 2005. On closer inspection, their idea is reminiscent of the Aero Snap feature in Windows 7 today, but arguably more powerful.
If you’ve been living under Mount Rushmore for the last 6 months and haven’t yet tried or seen Windows 7, then Aero Snap is a windows management feature that allows you to use mouse gestures to manipulate the size of windows. Whilst maximizing a window was something that was already trivially easy to do, docking two windows side-by-side was not. With Aero Snap, you would simply drag one to the left, and another to the right. Voila.
The Longhorn designers too thought of this windows management problem and came up with a slightly different solution, which I’m going to nickname “Aero Link”.
The first thing that’s different about “Aero Link” is the way it is triggered. Instead of dragging two arbitrary windows to the sides of the displays, it is suggested that one window be dragged to the titlebar of another, with a visual indicator indicating an action occurring. Alternatively it is also suggested that the same trigger can be performed in the taskbar dragging an application’s button onto another application’s button.
The end result of course is as one would expect, two windows side-by-side sharing the entire screen. It might not look any different, but this is where “Aero Link” starts to shine. Because the user has created a symbolic relationship between two windows, the windows would operate in synergy.
It is suggested for example, scrolling one document in the application on the left, would also scroll the document in the application on the right. Furthermore, an API would attempt to neutralize any differences between the applications such as font-size and font-family in a document application so the “child” application would match the “parent” application. Minimizing one application would also minimize the other.
Another cool aspect of this particular implementation is that by resizing one window, in reality it would be like shifting the balance between the two applications, thus easily controlling the split between the applications.
Finally, it was even suggested to create a new windows paradigm to encapsulate the relationship between two application windows by a new parent container as suggested in the diagram on the left, or by removing one set of windows controls as indicated on the right.